From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:60503) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5E6O-0003eu-Qx for qemu-devel@nongnu.org; Wed, 17 Jun 2015 10:14:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z5E6K-00055z-1g for qemu-devel@nongnu.org; Wed, 17 Jun 2015 10:14:04 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40839) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z5E6J-000555-Qw for qemu-devel@nongnu.org; Wed, 17 Jun 2015 10:13:59 -0400 Message-ID: <558180A0.8040708@redhat.com> Date: Wed, 17 Jun 2015 16:13:52 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1434117956-4929-1-git-send-email-dslutz@verizon.com> <20150617160826-mutt-send-email-mst@redhat.com> In-Reply-To: <20150617160826-mutt-send-email-mst@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v7 0/9] Add limited support of VMware's hyper-call rpc List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" , Don Slutz Cc: qemu-devel@nongnu.org, Markus Armbruster , Luiz Capitulino , Anthony Liguori , =?windows-1252?Q?Andreas_F=E4rber?= , Richard Henderson On 17/06/2015 16:11, Michael S. Tsirkin wrote: > On Fri, Jun 12, 2015 at 10:05:47AM -0400, Don Slutz wrote: >> Changes v6 to v7: >> Rebase to master >> >> Fixed a bug caused by commit c3c1bb99d1c11978d9ce94d1bdcf0705378c1459 now patch #1 > >> Added patch #2 to switch to using trace in vm,port.c. >> >> Delay call on g_strndup till after key length check. >> >> Switched e-mail address in MAINTAINERS. >> >> Eric Blake >> Why not assert(find) instead of leaving it to the comment? >> Switch to assert. >> Is it worth marking arg const here and in the VMPortRpcFind struct >> Switch to const. >> I'd rather abort() if someone compiled with -NDEBUG >> Done. >> Still mismatches on ---- line length (several sites). >> Done >> >> >> Changes v5 to v6: >> >> Rebase to master >> >> Eric Blake >> Returning a non-dictionary is not extensible. >> Added new type VmportGuestInfoValue. >> s/VmportGuestInfo/VmportGuestInfoKey/ >> s/type/struct/ >> Issues with examples >> Fixed. >> >> >> Changes v4 to v5: >> >> Paolo Bonzini >> What is VMPORT_SHORT about? >> Dropped this. >> Why not use a bool in CPUX86State? >> Took his sugestion and moved to a bool in X86CPU. >> >> Changes v3 to v4: >> >> Paolo Bonzini on "vmort_rpc: Add QMP access to vmport_rpc" >> Does this compile on non-x86 targets? >> Nope. Fixed. >> >> Changes v2 to v3: >> >> s/2.3/2.4 >> >> Changes v1 to v2: >> >> Added live migration code. >> Adjust data structures for migration. >> Switch to GHashTable. >> >> Eric Blake >> s/spawened/spawned/ >> Done >> s/traceing/tracing/ >> Done >> Change "error_set(errp, ERROR_CLASS_GENERIC_ERROR, " to >> "error_setg(errp, " >> Done >> Why two commands (inject-vmport-reboot, inject-vmport-halt)? >> Switched to inject-vmport-action. >> format=base64 "bug" statements. >> Dropped. >> >> Much more on format=base64: >> >> If there is a bug it is in GLIB. However the Glib reference manual >> refers to RFC 1421 and RFC 2045 and MIME encoding. Based on all >> that (which seems to match: >> >> http://en.wikipedia.org/wiki/Base64 >> >> ) MIME states that all characters outside the (base64) alphabet are >> to be ignored. Testing shows that g_base64_decode() does this. >> >> The confusion is that most non-MIME uses reject a base64 string that >> contain characters outside the alphabet. I was just following the >> other uses of base64 in this file. >> >> DataFormat refers to RFC 3548, which has the info: >> >> " >> Implementations MUST reject the encoding if it contains >> characters outside the base alphabet when interpreting base >> encoded data, unless the specification referring to this document >> explicitly states otherwise. Such specifications may, as MIME >> does, instead state that characters outside the base encoding >> alphabet should simply be ignored when interpreting data ("be >> liberal in what you accept"). >> " >> >> So with GLIB going the MIME way, I do not think this is a QEMU bug >> (you could consider this a GLIB bug, but the document I found says >> that GLIB goes the MIME way and so does not reject anything). > > To me it looks like this will break cross-version migration as you are > adding a bunch of devices unconditionally. Will it not? Yes, that's what was done for parallel and pcspk as well. There's no infrastructure to avoid it. Paolo