From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52945) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aXykK-0006Im-9Q for qemu-devel@nongnu.org; Mon, 22 Feb 2016 17:14:25 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aXykJ-0006C0-E6 for qemu-devel@nongnu.org; Mon, 22 Feb 2016 17:14:24 -0500 Received: from mail-vk0-x231.google.com ([2607:f8b0:400c:c05::231]:35859) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aXykJ-0006Bo-1g for qemu-devel@nongnu.org; Mon, 22 Feb 2016 17:14:23 -0500 Received: by mail-vk0-x231.google.com with SMTP id c3so143889283vkb.3 for ; Mon, 22 Feb 2016 14:14:22 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <1456175198-25210-1-git-send-email-wei@redhat.com> References: <1456175198-25210-1-git-send-email-wei@redhat.com> From: Peter Maydell Date: Mon, 22 Feb 2016 22:14:02 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 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: Wei Huang Cc: Andrew Jones , qemu-arm , QEMU Developers , Andrea Bolognani 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? 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... thanks -- PMM