From: Wei Huang <wei@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Andrew Jones <drjones@redhat.com>, qemu-arm <qemu-arm@nongnu.org>,
QEMU Developers <qemu-devel@nongnu.org>,
Andrea Bolognani <abologna@redhat.com>
Subject: Re: [Qemu-devel] [PATCH RFC 0/2] Versioning ARM virt machine types
Date: Tue, 23 Feb 2016 12:34:49 -0600 [thread overview]
Message-ID: <56CCA649.8090906@redhat.com> (raw)
In-Reply-To: <CAFEAcA8vyVL6jyMTGCap9Bu=eyqR2OUN5LzH5Sjo965Fn4PmHA@mail.gmail.com>
On 02/22/2016 04:14 PM, Peter Maydell wrote:
> On 22 February 2016 at 21:06, Wei Huang <wei@redhat.com> wrote:
>> We start to see more features been added to ARM virtual machine models.
>> For the purpose of backward compatibility (e.g. migration), it is time
>> to consider versioning machine types for ARM VMs. As a beginning step, this
>> patchset defines an abstract machine type for ARM VMs. The current
>> "virt" machine is re-written based on this new machine type accordingly.
>> These patches have been verified by booting existing VMs.
>>
>> Note that I am seeking inputs from the community by putting RFC in the
>> subject line. Please let me know your opinions. I will send out V1
>> afterwards.
>
> My view here is the same as it has been in the past regarding
> adding versioned machine types for 'virt': are you (in this case
> Redhat) willing to stand behind it, in the sense of taking on
> the maintenance burden of adding new machine versions, reviewing
> new code contributions for issues that require changes to make sure
> that the old versions stay looking like the old machine, testing
> that old versions look right, testing cross version migration,
> and so on?
I understand your concerns. Currently our in-house tree already carries
versioned ARM machine types, which mirror both QEMU 2.4 and QEMU 2.5.
Thus someone (including myself) from Red Hat shouldn't have any problem
of maintaining/testing it because we are already doing it downstream.
x86 and ppc have a similar situation.
>
> We need versioned machine types at *some* point; my intent here
> is to provide sufficient pushback to ensure that we don't give
> ourselves the maintenance headache until we truly need it...
>
mach-virt based products are coming soon, so versioning is just around
the corner. The advantage of introducing it upstream early is that the
upper layers in the stack have a chance to integrate, and the QEMU
downstreams don't need to diverge in how they add versioning support
themselves. This benefits not only Red Hat but also other companies.
Thanks,
-Wei
> thanks
> -- PMM
>
next prev parent reply other threads:[~2016-02-23 18:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-22 21:06 [Qemu-devel] [PATCH RFC 0/2] Versioning ARM virt machine types Wei Huang
2016-02-22 21:06 ` [Qemu-devel] [PATCH RFC 1/2] arm: virt: Add an abstract ARM virt machine type Wei Huang
2016-02-22 21:06 ` [Qemu-devel] [PATCH RFC 2/2] arm: virt: Move machine class init code to the abstract " Wei Huang
2016-02-22 22:14 ` [Qemu-devel] [PATCH RFC 0/2] Versioning ARM virt machine types Peter Maydell
2016-02-23 18:34 ` Wei Huang [this message]
2016-02-23 18:42 ` Peter Maydell
2016-02-23 19:09 ` Andrew Jones
2016-03-10 9:03 ` Peter Maydell
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=56CCA649.8090906@redhat.com \
--to=wei@redhat.com \
--cc=abologna@redhat.com \
--cc=drjones@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-arm@nongnu.org \
--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).