qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Salil Mehta <salil.mehta@opnsrc.net>
Cc: "Alex Bennée" <alex.bennee@linaro.org>,
	"mst@redhat.com" <mst@redhat.com>,
	"philmd@linaro.org" <philmd@linaro.org>,
	"david@redhat.com>> David Hildenbrand" <david@redhat.com>,
	"Jonathan Cameron" <jonathan.cameron@huawei.com>,
	"Salil Mehta" <salil.mehta@huawei.com>,
	qemu-devel@nongnu.org
Subject: Re: [Question] x86/microvm: why has_hotpluggable_cpus = false but hot(ub)plug APIs exist?
Date: Tue, 24 Oct 2023 10:05:54 +0200	[thread overview]
Message-ID: <20231024100554.3ef76ebf@imammedo.users.ipa.redhat.com> (raw)
In-Reply-To: <cbbf59ba-b7ab-b536-12ab-91a0bfc7f1c6@opnsrc.net>

On Wed, 18 Oct 2023 17:48:36 +0100
Salil Mehta <salil.mehta@opnsrc.net> wrote:

> Hi Alex,
> 
> On 18/10/2023 16:41, Alex Bennée wrote:
> > 
> > Salil Mehta <salil.mehta@opnsrc.net> writes:
> >   
> >> Hello,
> >>
> >> Came across below code excerpt in x86/microvm code and wanted to know
> >> why 'has_hotpluggable_cpus' flag has been set to 'false' while various
> >> hot(un)plug APIs have been defined?
> >>
> >> static void microvm_class_init(ObjectClass *oc, void *data)
> >> {
> >>      X86MachineClass *x86mc = X86_MACHINE_CLASS(oc);
> >>      MachineClass *mc = MACHINE_CLASS(oc);
> >>      HotplugHandlerClass *hc = HOTPLUG_HANDLER_CLASS(oc);
> >>
> >>      mc->init = microvm_machine_state_init;
> >>
> >>      mc->family = "microvm_i386";
> >>      [...]
> >>      mc->max_cpus = 288;
> >>      mc->has_hotpluggable_cpus = false;  --------> This one
> >>      [...]  
> > 
> >  From the original commit that added it:
> > 
> >    It's a minimalist machine type without PCI nor ACPI support, designed
> >    for short-lived guests. microvm also establishes a baseline for
> >    benchmarking and optimizing both QEMU and guest operating systems,
> >    since it is optimized for both boot time and footprint.  
> 
> 
> Agreed. It looks like ACPI is supported but neither CPU/Memory Hotplug 
> is supported for this minimalist machine type.
> 
> 
> static void microvm_devices_init(MicrovmMachineState *mms)
> {
>      const char *default_firmware;
>      X86MachineState *x86ms = X86_MACHINE(mms);
> 
>     [...]
> 
>      /* Optional and legacy devices */
>      if (x86_machine_is_acpi_enabled(x86ms)) {
>          DeviceState *dev = qdev_new(TYPE_ACPI_GED_X86);
>          qdev_prop_set_uint32(dev, "ged-event", ACPI_GED_PWR_DOWN_EVT);
>          sysbus_mmio_map(SYS_BUS_DEVICE(dev), 0, GED_MMIO_BASE);
>       /* sysbus_mmio_map(SYS_BUS_DEVICE(dev), 1, GED_MMIO_BASE_MEMHP); */
> 
>          [...]
> 
>          sysbus_realize(SYS_BUS_DEVICE(dev), &error_fatal);
>          x86ms->acpi_dev = HOTPLUG_HANDLER(dev);
>      }
>     [...]
> }
> 
> 
> 
> > 
> > Generally hotplug requires a dance between the VMM and the firmware to
> > properly shutdown and restart hotplug devices. The principle
> > communication mechanism for this is ACPI.  

firmware part in cpu/mem hoptlug usually provided by QEMU by the way of
ACPI tables (which may contain AML code that handles dance with QEMU
while exposing standard interface to guest OS to handle hotplug)

> 
> Agreed.
> 
> 
> 
> >   
> >>
> >>      /* hotplug (for cpu coldplug) */
> >>      mc->get_hotplug_handler = microvm_get_hotplug_handler;
> >>      hc->pre_plug = microvm_device_pre_plug_cb;
> >>      hc->plug = microvm_device_plug_cb;
> >>      hc->unplug_request = microvm_device_unplug_request_cb;
> >>      hc->unplug = microvm_device_unplug_cb;  
> 
> sorry, I also missed the definitions of the last 2 functions which says 
> that unplug is not supported so perhaps these functions are only 
> required to support cold plugging which corroborates with the comment as 
> well.

this function are usually used for both cold and hotplug of bus-less devices.
They provide an opt-in way for board to wire up such devices (incl. CPU).

> 
> Thanks
> Salil.
> 



  reply	other threads:[~2023-10-24  8:07 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-18 15:16 [Question] x86/microvm: why has_hotpluggable_cpus = false but hot(ub)plug APIs exist? Salil Mehta
2023-10-18 15:41 ` Alex Bennée
2023-10-18 16:48   ` Salil Mehta
2023-10-24  8:05     ` Igor Mammedov [this message]
2023-10-25  9:16       ` Salil Mehta via
2023-10-25  9:16         ` Salil Mehta
2023-10-25  9:31         ` David Hildenbrand
2023-10-25  9:54           ` Salil Mehta via
2023-10-25  9:54             ` Salil Mehta
2023-10-26 12:09             ` Igor Mammedov
2023-10-27 10:15               ` Salil Mehta via
2023-10-27 10:15                 ` Salil Mehta

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=20231024100554.3ef76ebf@imammedo.users.ipa.redhat.com \
    --to=imammedo@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=david@redhat.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=mst@redhat.com \
    --cc=philmd@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=salil.mehta@huawei.com \
    --cc=salil.mehta@opnsrc.net \
    /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).