From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:51681)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <marcel.a@redhat.com>) id 1WzWA1-0001D1-HB
	for qemu-devel@nongnu.org; Tue, 24 Jun 2014 15:13:48 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <marcel.a@redhat.com>) id 1WzW9u-0003kU-1Y
	for qemu-devel@nongnu.org; Tue, 24 Jun 2014 15:13:41 -0400
Received: from mx1.redhat.com ([209.132.183.28]:8266)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <marcel.a@redhat.com>) id 1WzW9t-0003kG-PV
	for qemu-devel@nongnu.org; Tue, 24 Jun 2014 15:13:33 -0400
Message-ID: <1403637201.20031.8.camel@localhost.localdomain>
From: Marcel Apfelbaum <marcel.a@redhat.com>
Date: Tue, 24 Jun 2014 22:13:21 +0300
In-Reply-To: <20140624175520.GU3222@otherpad.lan.raisama.net>
References: <1403108034-32054-1-git-send-email-mst@redhat.com>
	<1403108034-32054-27-git-send-email-mst@redhat.com>
	<20140624164431.GA14901@otherpad.lan.raisama.net>
	<CAFEAcA8TRtTJkzCHhKvVU1aG0isb5ZSCObwBURrR0tj3p5AyCg@mail.gmail.com>
	<20140624175520.GU3222@otherpad.lan.raisama.net>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] per-machine vs per-qemu-version compat_props
 macros (was Re: acpi:ich9: add memory hotplug handling)
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>, "Michael S. Tsirkin" <mst@redhat.com>, Alexey Kardashevskiy <aik@ozlabs.ru>, QEMU Developers <qemu-devel@nongnu.org>, Markus Armbruster <armbru@redhat.com>, Paul Mackerras <paulus@samba.org>, Anthony Liguori <aliguori@amazon.com>, Paolo Bonzini <pbonzini@redhat.com>, Igor Mammedov <imammedo@redhat.com>, Andreas =?ISO-8859-1?Q?F=E4rber?= <afaerber@suse.de>, Alexander Graf <agraf@suse.com>

On Tue, 2014-06-24 at 14:55 -0300, Eduardo Habkost wrote:
> On Tue, Jun 24, 2014 at 05:47:53PM +0100, Peter Maydell wrote:
> > On 24 June 2014 17:44, Eduardo Habkost <ehabkost@redhat.com> wrote:
> > > (I would go even further and say that no compat_props bit need to be
> > > specific to a machine-type family, and they are simply tied to the code
> > > included in a QEMU version. So every PC_COMPAT_* bit could go to a
> > > common QEMU_COMPAT_<version> macro, that could be reusable by all
> > > machine-types, and there's no need PC-specific compat macros.)
> > 
> > What if different machines in a particular release had the
> > property set to different defaults?
> 
> I never saw that happen, and I don't think it is even likely: default
> values set in instance_init, and compat_props are applied just after
> instance_init, before object_new() returns. So a machine-type would need
> to find a way to change fields after instance_init but before
> compat_props are applied.
> 
> Anyway, if a machine-type really needs that, it can still have its own
> set of compat macros to implement machine-type-specific compat_props. My
> point is that there's no need for that on the PC code today.
> 
+1

As discussed in today's KVM call, compat props per version is the best
approach.

Thanks,
Marcel