From: Christian Borntraeger <borntraeger@de.ibm.com>
To: "Michael S. Tsirkin" <mst@redhat.com>,
Cornelia Huck <cornelia.huck@de.ibm.com>
Cc: qemu-devel@nongnu.org, jjherne@linux.vnet.ibm.com
Subject: Re: [Qemu-devel] [PATCH RFC 1/1] virtio: migrate config_vector
Date: Wed, 13 May 2015 20:57:00 +0200 [thread overview]
Message-ID: <55539E7C.90004@de.ibm.com> (raw)
In-Reply-To: <20150513180005-mutt-send-email-mst@redhat.com>
Am 13.05.2015 um 18:14 schrieb Michael S. Tsirkin:
>> - AFAICS, there's no easy way to add transport-specific subsections -
>> and simply adding config_vector in ccw would break compatibility
>
> subsections break compatibility too. The only way around that is to set
> a flag to skip migrating config_vector for old machine types.
My main concern is about undetected compatibility issues. A subsection will
tell the user that something went wrong. What happens if we just add a new
qemu_put_byte in the stream. Will the savevm core always detect that we have
too many or not enough bytes? If yes, adding new stuff in the stream will
always be detected in some way as error we can go with just adding
qemu_put_be16/qemu_get_be16 in virtio_ccw_save_config/virtio_ccw_load_config.
Old/new QEMUs will then not be compatible - but thats probably ok as long as it
errors out.
My understanding was that we do not have a guarentee that this will be
detected all the time and having random junk in some variables is a debugging
nightmare. Is that correct?
Christian
next prev parent reply other threads:[~2015-05-13 18:57 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-13 14:42 [Qemu-devel] [PATCH RFC 0/1] virtio: fix config_vector migration issues Cornelia Huck
2015-05-13 14:42 ` [Qemu-devel] [PATCH RFC 1/1] virtio: migrate config_vector Cornelia Huck
2015-05-13 14:58 ` Michael S. Tsirkin
2015-05-13 15:03 ` Cornelia Huck
2015-05-13 16:14 ` Michael S. Tsirkin
2015-05-13 18:57 ` Christian Borntraeger [this message]
2015-05-13 21:47 ` Michael S. Tsirkin
2015-05-14 9:22 ` Christian Borntraeger
2015-05-14 9:36 ` Michael S. Tsirkin
2015-05-14 10:02 ` Paolo Bonzini
2015-05-14 10:30 ` Christian Borntraeger
2015-05-14 17:00 ` Dr. David Alan Gilbert
2015-05-15 7:08 ` Christian Borntraeger
2015-05-15 7:13 ` Michael S. Tsirkin
2015-05-18 11:26 ` Cornelia Huck
2015-05-18 15:29 ` Cornelia Huck
2015-06-03 11:59 ` Christian Borntraeger
2015-06-03 12:23 ` Michael S. Tsirkin
2015-05-14 8:24 ` Paolo Bonzini
2015-05-14 9:56 ` Michael S. Tsirkin
2015-05-14 10:04 ` Paolo Bonzini
2015-05-14 10:07 ` Michael S. Tsirkin
2015-05-14 10:09 ` Paolo Bonzini
2015-05-14 10:38 ` Christian Borntraeger
2015-05-14 8:22 ` Paolo Bonzini
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=55539E7C.90004@de.ibm.com \
--to=borntraeger@de.ibm.com \
--cc=cornelia.huck@de.ibm.com \
--cc=jjherne@linux.vnet.ibm.com \
--cc=mst@redhat.com \
--cc=qemu-devel@nongnu.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).