From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37984) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aYHnf-0003nU-TM for qemu-devel@nongnu.org; Tue, 23 Feb 2016 13:35:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aYHna-0001Zq-DW for qemu-devel@nongnu.org; Tue, 23 Feb 2016 13:35:07 -0500 References: <1456175198-25210-1-git-send-email-wei@redhat.com> From: Wei Huang Message-ID: <56CCA649.8090906@redhat.com> Date: Tue, 23 Feb 2016 12:34:49 -0600 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH RFC 0/2] Versioning ARM virt machine types List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Andrew Jones , qemu-arm , QEMU Developers , Andrea Bolognani On 02/22/2016 04:14 PM, Peter Maydell wrote: > On 22 February 2016 at 21:06, Wei Huang 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 >