From: Igor Mammedov <imammedo@redhat.com>
To: Laszlo Ersek <lersek@redhat.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
qemu devel list <qemu-devel@nongnu.org>,
"Michael S. Tsirkin" <mst@redhat.com>,
Gerd Hoffmann <kraxel@redhat.com>,
Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v4 7/7] hw/i386/pc_q35: advertise broadcast SMI if VCPU hotplug is turned off
Date: Fri, 2 Dec 2016 13:18:15 +0100 [thread overview]
Message-ID: <20161202131815.17d07ef5@nial.brq.redhat.com> (raw)
In-Reply-To: <20fba314-63c0-e003-415d-20b142d9a075@redhat.com>
On Thu, 1 Dec 2016 21:42:58 +0100
Laszlo Ersek <lersek@redhat.com> wrote:
> On 12/01/16 20:13, Eduardo Habkost wrote:
> > 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" <mst@redhat.com>
> >> Cc: Eduardo Habkost <ehabkost@redhat.com>
> >> Cc: Gerd Hoffmann <kraxel@redhat.com>
> >> Cc: Igor Mammedov <imammedo@redhat.com>
> >> Cc: Paolo Bonzini <pbonzini@redhat.com>
> >> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> >> ---
> >> 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?
> >
>
> I don't know how else to capture the (smp_cpus == max_cpus) question,
> for saying that "this machine type supports SMI broadcast, as long as
> VCPU hotplug is disabled in the configuration".
(smp_cpus == max_cpus) doesn't mean that CPU hotplug is disabled
(it actually can't be disabled at all).
In addition, it's possible to start machine with
-smp 1,sockets=2,max_cpus=2 -device mycputype,socket=2
where all cpus will be coldpugged
It would be better to use PCMachineState.boot_cpus which contains
present cpus count.
I'd drop hotplug check (as usecase is broken in many places anyway)
and even won't touch PCMachineState, instead add a property like
ICH9_LPC.enable_smi_broadcast(on by default) and disable it for
old machine types using compat props.
We can work on making CPU hotplug and OVMF work in follow up patches.
> Technically we could give PCMC two new (data) fields, a host features
> bitmap for when VCPU hotplug is enabled, and another for when VCPU
> hotplug is disabled. Then board code would take the right field and pass
> it on to ich9_lpc_pm_init().
>
> Thanks
> Laszlo
next prev parent reply other threads:[~2016-12-02 12:18 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-01 17:06 [Qemu-devel] [PATCH v4 0/7] q35: add negotiable broadcast SMI Laszlo Ersek
2016-12-01 17:06 ` [Qemu-devel] [PATCH v4 1/7] fw-cfg: support writeable blobs Laszlo Ersek
2016-12-20 15:58 ` Marcel Apfelbaum
2017-01-10 13:33 ` Laszlo Ersek
2016-12-01 17:06 ` [Qemu-devel] [PATCH v4 2/7] fw-cfg: turn FW_CFG_FILE_SLOTS into a device property Laszlo Ersek
2016-12-02 11:10 ` Gerd Hoffmann
2016-12-02 11:48 ` Laszlo Ersek
2016-12-02 12:47 ` Gerd Hoffmann
2016-12-06 10:50 ` Igor Mammedov
2016-12-06 11:43 ` Laszlo Ersek
2016-12-06 12:02 ` Igor Mammedov
2016-12-06 16:22 ` Laszlo Ersek
2017-01-10 15:02 ` Michael S. Tsirkin
2016-12-01 17:06 ` [Qemu-devel] [PATCH v4 3/7] fw-cfg: expose "file_slots" parameter in fw_cfg_init_io_dma() Laszlo Ersek
2016-12-06 11:49 ` Igor Mammedov
2016-12-06 16:46 ` Laszlo Ersek
2016-12-06 16:52 ` Laszlo Ersek
2016-12-06 23:21 ` David Gibson
2016-12-06 18:09 ` Igor Mammedov
2016-12-06 19:29 ` Stefano Stabellini
2017-01-10 15:02 ` Michael S. Tsirkin
2016-12-01 17:06 ` [Qemu-devel] [PATCH v4 4/7] hw/i386/pc: introduce 2.9 machine types with 0x20 fw_cfg file slots Laszlo Ersek
2016-12-01 17:06 ` [Qemu-devel] [PATCH v4 5/7] hw/isa/lpc_ich9: add SMI feature negotiation via fw_cfg Laszlo Ersek
2016-12-02 11:54 ` Igor Mammedov
2016-12-02 12:00 ` Laszlo Ersek
2016-12-01 17:06 ` [Qemu-devel] [PATCH v4 6/7] hw/isa/lpc_ich9: add broadcast SMI feature Laszlo Ersek
2016-12-01 17:06 ` [Qemu-devel] [PATCH v4 7/7] hw/i386/pc_q35: advertise broadcast SMI if VCPU hotplug is turned off Laszlo Ersek
2016-12-01 19:13 ` Eduardo Habkost
2016-12-01 20:42 ` Laszlo Ersek
2016-12-01 20:53 ` Eduardo Habkost
2016-12-02 12:18 ` Igor Mammedov [this message]
2016-12-02 19:32 ` Laszlo Ersek
2016-12-20 23:01 ` [Qemu-devel] [PATCH v4 0/7] q35: add negotiable broadcast SMI no-reply
2016-12-21 15:22 ` [Qemu-devel] checkpatch.pl false positive (was Re: [PATCH v4 0/7] q35: add negotiable broadcast SMI) Eduardo Habkost
2016-12-21 17:47 ` Paolo Bonzini
2016-12-21 18:01 ` Eduardo Habkost
2016-12-21 18:08 ` Paolo Bonzini
2016-12-21 18:19 ` Eduardo Habkost
2017-01-10 15:06 ` [Qemu-devel] [PATCH v4 0/7] q35: add negotiable broadcast SMI Michael S. Tsirkin
2017-01-10 15:23 ` Laszlo Ersek
2017-01-10 16:05 ` Michael S. Tsirkin
2017-01-10 16:19 ` Laszlo Ersek
2017-01-10 16:21 ` Igor Mammedov
2017-01-10 16:30 ` Laszlo Ersek
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=20161202131815.17d07ef5@nial.brq.redhat.com \
--to=imammedo@redhat.com \
--cc=ehabkost@redhat.com \
--cc=kraxel@redhat.com \
--cc=lersek@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).