From: Jamie Lokier <jamie@shareable.org>
To: Anthony Liguori <aliguori@us.ibm.com>
Cc: Mark McLoughlin <markmc@redhat.com>, Dor Laor <dlaor@redhat.com>,
qemu-devel@nongnu.org, ajax@redhat.com,
Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [PATCH] Change virtio-console to PCI_CLASS_SERIAL_OTHER
Date: Sun, 31 May 2009 19:48:20 +0100 [thread overview]
Message-ID: <20090531184820.GA31278@shareable.org> (raw)
In-Reply-To: <4A1E8F5D.1090408@us.ibm.com>
Anthony Liguori wrote:
> The problem is that the device model a guest sees is an ABI. If we
> change the ABI between versions, the guest make break. What I'm
> proposing is that while we can change the default guest ABI between
> versions, we must provide a way to recreate older forms of the guest ABI.
>
> A good example of guests breaking is Windows activation failing. It has
> happened more than once that changes in QEMU cause Windows guests to
> force reactivation. In more extreme instances, a guest may break that
> used to work before.
I agree.
As far as I'm concerned, a major use of virtualisation is to be able
to run old guests on newer hosts without having to keep changing the
guest OS, including reinstalling its drivers etc.
Because of this guest ABI compatibility is perhaps more important than
it would be for othe rapplications.
Windows activation is particularly ugly, but maybe we can special case
that by making known relevant serial numbers, asset tags
etc. configurable in the device model?
You can avoid problems by sticking with a fixed QEMU/KVM version of
course, but then you don't get the benefits of development like
performance improvements and bug fixes. And in the long run, it
doesn't work because older QEMU/KVMs don't work properly (or at all)
on later host systems.
If newer Qemu's can't do that, we'll eventually be in the curious
position of having to use nested virtualisation - to run an older Qemu
on an older nested 'host'. Sounds annoying :-)
As soon as the device model config file is used, I expect all this
will get easier to manage than it is now. The main thing then will be
to ensure there are options to recreate old guest modes for particular
devices. There's probably just a few such options, so not much of a
maintenance burden.
-- Jamie
next prev parent reply other threads:[~2009-05-31 18:48 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-22 17:14 [Qemu-devel] [PATCH] Change virtio-console to PCI_CLASS_SERIAL_OTHER Mark McLoughlin
2009-05-24 9:11 ` Avi Kivity
2009-05-27 14:21 ` Anthony Liguori
2009-05-27 17:42 ` Mark McLoughlin
2009-05-27 22:37 ` Anthony Liguori
2009-05-28 9:33 ` Mark McLoughlin
2009-05-28 9:44 ` Anthony Liguori
2009-05-28 12:53 ` Paul Brook
2009-05-28 12:56 ` Anthony Liguori
2009-05-28 13:22 ` Paul Brook
2009-05-28 13:29 ` Anthony Liguori
2009-05-28 21:45 ` Dor Laor
2009-05-29 9:43 ` Mark McLoughlin
2009-05-29 9:50 ` Anthony Liguori
2009-05-31 14:32 ` Avi Kivity
2009-05-29 9:55 ` Anthony Liguori
2009-05-29 10:09 ` Mark McLoughlin
2009-05-31 14:47 ` Dor Laor
2009-06-02 8:49 ` Mark McLoughlin
2009-06-02 13:08 ` Dor Laor
2009-06-02 13:39 ` Mark McLoughlin
2009-05-31 14:35 ` Dor Laor
2009-06-02 8:49 ` Mark McLoughlin
2009-05-28 13:04 ` Daniel P. Berrange
2009-05-28 13:19 ` Anthony Liguori
2009-05-31 18:48 ` Jamie Lokier [this message]
2009-05-28 13:20 ` Paul Brook
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=20090531184820.GA31278@shareable.org \
--to=jamie@shareable.org \
--cc=ajax@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=dlaor@redhat.com \
--cc=markmc@redhat.com \
--cc=paul@codesourcery.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).