From: "Michael S. Tsirkin" <mst@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Markus Armbruster" <armbru@redhat.com>,
qemu-devel@nongnu.org, "Don Slutz" <dslutz@verizon.com>,
"Luiz Capitulino" <lcapitulino@redhat.com>,
"Anthony Liguori" <aliguori@amazon.com>,
"Andreas Färber" <afaerber@suse.de>,
"Richard Henderson" <rth@twiddle.net>
Subject: Re: [Qemu-devel] [PATCH v7 0/9] Add limited support of VMware's hyper-call rpc
Date: Wed, 17 Jun 2015 16:18:47 +0200 [thread overview]
Message-ID: <20150617161716-mutt-send-email-mst@redhat.com> (raw)
In-Reply-To: <558180A0.8040708@redhat.com>
On Wed, Jun 17, 2015 at 04:13:52PM +0200, Paolo Bonzini wrote:
>
>
> 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
How do you mean? We have multiple ways to keep devices
compatible with old versions.
Set a new property to skip the extra stuff.
Since we enable this thing by default (why do we?)
this seems like a big deal ...
--
MST
next prev parent reply other threads:[~2015-06-17 14:19 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-12 14:05 [Qemu-devel] [PATCH v7 0/9] Add limited support of VMware's hyper-call rpc Don Slutz
2015-06-12 14:05 ` [Qemu-devel] [BUGFIX][PATCH v7 1/9] vmport: The io memory region needs to be at least a size of 4 Don Slutz
2015-06-12 22:38 ` Eric Blake
2015-06-15 13:53 ` Don Slutz
2015-06-15 15:09 ` Eric Blake
2015-06-15 16:15 ` Don Slutz
2015-06-12 14:05 ` [Qemu-devel] [PATCH v7 2/9] vmport: Switch to trace Don Slutz
2015-06-12 14:05 ` [Qemu-devel] [BUGFIX][PATCH v7 3/9] vmport: Fix vmport_cmd_ram_size Don Slutz
2015-06-12 14:05 ` [Qemu-devel] [PATCH v7 4/9] vmport_rpc: Add the object vmport_rpc Don Slutz
2015-06-12 14:05 ` [Qemu-devel] [PATCH v7 5/9] vmport_rpc: Add limited support of VMware's hyper-call rpc Don Slutz
2015-06-12 14:05 ` [Qemu-devel] [PATCH v7 6/9] vmport_rpc: Add QMP access to vmport_rpc object Don Slutz
2015-06-15 15:53 ` Eric Blake
2015-06-17 16:42 ` Don Slutz
2015-06-12 14:05 ` [Qemu-devel] [PATCH v7 7/9] vmport_rpc: Add migration Don Slutz
2015-06-12 14:05 ` [Qemu-devel] [PATCH v7 8/9] vmport: Add VMware all ring hack Don Slutz
2015-06-12 14:05 ` [Qemu-devel] [PATCH v7 9/9] MAINTAINERS: add VMware port Don Slutz
2015-06-17 13:44 ` [Qemu-devel] [PATCH v7 0/9] Add limited support of VMware's hyper-call rpc Paolo Bonzini
2015-06-17 22:26 ` Don Slutz
2015-06-18 7:58 ` Michael S. Tsirkin
2015-06-18 8:33 ` Paolo Bonzini
2015-06-18 9:40 ` Michael S. Tsirkin
2015-06-18 8:33 ` Paolo Bonzini
2015-06-17 14:11 ` Michael S. Tsirkin
2015-06-17 14:13 ` Paolo Bonzini
2015-06-17 14:18 ` Michael S. Tsirkin [this message]
2015-06-17 14:27 ` Paolo Bonzini
2015-06-17 14:29 ` Michael S. Tsirkin
2015-06-17 16:17 ` Paolo Bonzini
2015-06-17 16:29 ` Michael S. Tsirkin
2015-06-17 16:48 ` Paolo Bonzini
2015-06-17 18:43 ` Michael S. Tsirkin
2015-06-17 19:15 ` Paolo Bonzini
2015-06-17 19:22 ` Michael S. Tsirkin
2015-06-17 19:24 ` Paolo Bonzini
2015-06-17 19:29 ` Michael S. Tsirkin
2015-06-17 17:03 ` Don Slutz
2015-06-17 17:14 ` Paolo Bonzini
2015-06-17 17:25 ` Paolo Bonzini
2015-06-17 17:34 ` Don Slutz
2015-06-17 18:58 ` Michael S. Tsirkin
2015-06-18 18:40 ` Don Slutz
2015-06-17 18:45 ` Michael S. Tsirkin
2015-06-17 18:45 ` Michael S. Tsirkin
2015-06-18 7:03 ` Gerd Hoffmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150617161716-mutt-send-email-mst@redhat.com \
--to=mst@redhat.com \
--cc=afaerber@suse.de \
--cc=aliguori@amazon.com \
--cc=armbru@redhat.com \
--cc=dslutz@verizon.com \
--cc=lcapitulino@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.