qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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
> 

  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).