From: "Alex Bennée" <alex.bennee@linaro.org>
To: Salil Mehta <salil.mehta@opnsrc.net>
Cc: "mst@redhat.com" <mst@redhat.com>,
"imammedo@redhat.com >> Igor Mammedov" <imammedo@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: Wed, 18 Oct 2023 16:41:09 +0100 [thread overview]
Message-ID: <87o7gw9btp.fsf@linaro.org> (raw)
In-Reply-To: <78103368-9ea5-167b-5700-7d3d174ff564@opnsrc.net>
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.
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.
>
> /* 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;
> [...]
> }
>
>
> Best regards
> Salil
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
next prev parent reply other threads:[~2023-10-18 15:43 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 [this message]
2023-10-18 16:48 ` Salil Mehta
2023-10-24 8:05 ` Igor Mammedov
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=87o7gw9btp.fsf@linaro.org \
--to=alex.bennee@linaro.org \
--cc=david@redhat.com \
--cc=imammedo@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.