From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44790) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cCWnK-0000FQ-HN for qemu-devel@nongnu.org; Thu, 01 Dec 2016 14:13:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cCWnF-0005Ep-Kg for qemu-devel@nongnu.org; Thu, 01 Dec 2016 14:13:22 -0500 Received: from mx1.redhat.com ([209.132.183.28]:43278) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cCWnF-0005EZ-EK for qemu-devel@nongnu.org; Thu, 01 Dec 2016 14:13:17 -0500 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A3B574E4C1 for ; Thu, 1 Dec 2016 19:13:15 +0000 (UTC) Date: Thu, 1 Dec 2016 17:13:12 -0200 From: Eduardo Habkost Message-ID: <20161201191312.GA13060@thinpad.lan.raisama.net> References: <20161201170624.26496-1-lersek@redhat.com> <20161201170624.26496-8-lersek@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161201170624.26496-8-lersek@redhat.com> Subject: Re: [Qemu-devel] [PATCH v4 7/7] hw/i386/pc_q35: advertise broadcast SMI if VCPU hotplug is turned off List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Laszlo Ersek Cc: qemu devel list , "Michael S. Tsirkin" , Gerd Hoffmann , Igor Mammedov , Paolo Bonzini On Thu, Dec 01, 2016 at 06:06:24PM +0100, Laszlo Ersek wrote: > For the time being, we cannot handle SMIs in OVMF if VCPUs can show up > after boot. Otherwise, advertise ICH9_LPC_SMI_F_BROADCAST. > > Implement this generally, by introducing a new PCMachineClass method, > namely get_smi_host_features(), and implement the above logic for > pc-q35-2.9 and later. The idea is that future machine types might want to > calculate (the same or different) SMI host features from different > information, and that shouldn't affect earlier machine types. > > In turn, validating guest feature requests (inter-feature dependencies) > should be possible purely based on the available host feature set. For > example, in the future we might enforce that the guest select > ICH9_LPC_SMI_F_VCPU_PARKING as a prerequisite for > ICH9_LPC_SMI_F_BROADCAST, but only if the machine type itself advertises > ICH9_LPC_SMI_F_VCPU_PARKING. > > Cc: "Michael S. Tsirkin" > Cc: Eduardo Habkost > Cc: Gerd Hoffmann > Cc: Igor Mammedov > Cc: Paolo Bonzini > Signed-off-by: Laszlo Ersek > --- > include/hw/i386/pc.h | 1 + > hw/i386/pc_q35.c | 24 +++++++++++++++++++++++- > 2 files changed, 24 insertions(+), 1 deletion(-) > > diff --git a/include/hw/i386/pc.h b/include/hw/i386/pc.h > index 430735e501dd..e164947116b6 100644 > --- a/include/hw/i386/pc.h > +++ b/include/hw/i386/pc.h > @@ -116,10 +116,11 @@ struct PCMachineClass { > /*< public >*/ > > /* Methods: */ > HotplugHandler *(*get_hotplug_handler)(MachineState *machine, > DeviceState *dev); > + uint64_t (*get_smi_host_features)(void); I'd prefer to encode the differences between machine-types as data, instead of code, to make introspection easier in the future. Is it possible to encode this in a simple PCMachineClass struct data field or (even bettter) a QOM property? -- Eduardo