All of lore.kernel.org
 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-arm] [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
> 

WARNING: multiple messages have this Message-ID (diff)
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: 14+ 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-arm] [PATCH RFC 2/2] arm: virt: Move machine class init code to the abstract " Wei Huang
2016-02-22 21:06   ` [Qemu-devel] " Wei Huang
2016-02-22 22:14 ` [Qemu-arm] [PATCH RFC 0/2] Versioning ARM virt machine types Peter Maydell
2016-02-22 22:14   ` [Qemu-devel] " Peter Maydell
2016-02-23 18:34   ` Wei Huang [this message]
2016-02-23 18:34     ` Wei Huang
2016-02-23 18:42     ` [Qemu-arm] " Peter Maydell
2016-02-23 18:42       ` [Qemu-devel] " Peter Maydell
2016-02-23 19:09       ` [Qemu-arm] " Andrew Jones
2016-02-23 19:09         ` [Qemu-devel] " Andrew Jones
2016-03-10  9:03         ` [Qemu-arm] " Peter Maydell
2016-03-10  9:03           ` [Qemu-devel] " 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 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.