From: Sergio Lopez <slp@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: pbonzini@redhat.com, rth@twiddle.net, qemu-devel@nongnu.org,
mst@redhat.com
Subject: Re: [Qemu-devel] [PATCH 4/4] hw/i386: Introduce the microvm machine type
Date: Fri, 28 Jun 2019 23:42:52 +0200 [thread overview]
Message-ID: <87mui1wfmr.fsf@redhat.com> (raw)
In-Reply-To: <20190628194703.GH1862@habkost.net>
[-- Attachment #1: Type: text/plain, Size: 4975 bytes --]
Eduardo Habkost <ehabkost@redhat.com> writes:
> Hi,
>
> This looks good, overall, I'm just confused by the versioning
> system. Comments below:
>
>
> On Fri, Jun 28, 2019 at 01:53:49PM +0200, Sergio Lopez wrote:
>> Microvm is a machine type inspired by both NEMU and Firecracker, and
>> constructed after the machine model implemented by the latter.
>>
>> It's main purpose is providing users a KVM-only machine type with fast
>> boot times, minimal attack surface (measured as the number of IO ports
>> and MMIO regions exposed to the Guest) and small footprint (specially
>> when combined with the ongoing QEMU modularization effort).
>>
>> Normally, other than the device support provided by KVM itself,
>> microvm only supports virtio-mmio devices. Microvm also includes a
>> legacy mode, which adds an ISA bus with a 16550A serial port, useful
>> for being able to see the early boot kernel messages.
>>
>> Signed-off-by: Sergio Lopez <slp@redhat.com>
> [...]
>> +static const TypeInfo microvm_machine_info = {
>> + .name = TYPE_MICROVM_MACHINE,
>> + .parent = TYPE_MACHINE,
>> + .abstract = true,
>> + .instance_size = sizeof(MicrovmMachineState),
>> + .instance_init = microvm_machine_instance_init,
>> + .class_size = sizeof(MicrovmMachineClass),
>> + .class_init = microvm_class_init,
>
> [1]
>
>> + .interfaces = (InterfaceInfo[]) {
>> + { TYPE_NMI },
>> + { }
>> + },
>> +};
>> +
>> +static void microvm_machine_init(void)
>> +{
>> + type_register_static(µvm_machine_info);
>> +}
>> +type_init(microvm_machine_init);
>> +
>> +static void microvm_1_0_instance_init(Object *obj)
>> +{
>> +}
>
> You shouldn't need a instance_init function if it's empty, I
> believe you can delete it.
Ack.
>> +
>> +static void microvm_machine_class_init(MachineClass *mc)
>
> Why do you need both microvm_machine_class_init() [1] and
> microvm_class_init()?
No idea. To be honest, I took the boilerplate from NEMU's virt machine
type (hence the copyright notice), and I assumed that was actually
mandatory.
>> +{
>> + mc->init = microvm_machine_state_init;
>> +
>> + mc->family = "microvm_i386";
>> + mc->desc = "Microvm (i386)";
>> + mc->units_per_default_bus = 1;
>> + mc->no_floppy = 1;
>> + machine_class_allow_dynamic_sysbus_dev(mc, "sysbus-debugcon");
>> + machine_class_allow_dynamic_sysbus_dev(mc, "sysbus-debugexit");
>> + mc->max_cpus = 288;
>
> Where does this limit come from?
From pc_q35.c:366. Apparently, having this limit defined is mandatory,
and I wasn't which value would make sense for microvm.
>> + mc->has_hotpluggable_cpus = false;
>> + mc->auto_enable_numa_with_memhp = false;
>> + mc->default_cpu_type = X86_CPU_TYPE_NAME ("host");
>> + mc->nvdimm_supported = false;
>> + mc->default_machine_opts = "accel=kvm";
>> +
>> + /* Machine class handlers */
>> + mc->cpu_index_to_instance_props = cpu_index_to_props;
>> + mc->get_default_cpu_node_id = cpu_get_default_cpu_node_id;
>> + mc->possible_cpu_arch_ids = cpu_possible_cpu_arch_ids;;
>
> I don't think these methods should be mandatory if you don't
> support NUMA or CPU hotplug. Do you really need them?
>
> (If the core machine code makes them mandatory, it's probably not
> intentional).
Ack, I'll check whether this is actually needed or not.
>> + mc->reset = microvm_machine_reset;
>> +}
>> +
>> +static void microvm_1_0_machine_class_init(MachineClass *mc)
>> +{
>> + microvm_machine_class_init(mc);
>> +}
>> +DEFINE_MICROVM_MACHINE_AS_LATEST(1, 0)
>
>
> We only have multiple versions of some machine types (pc-*,
> virt-*, pseries-*, s390-ccw-virtio-*) because of Guest ABI
> compatibility (which you are not implementing here). What's the
> reason behind having multiple microvm machine versions?
I though it could be a good idea to have versioning already in place, in
case we need it in the future. But, perhaps we can do a simple machine
definition and just add versioning when it's really needed?
> [...]
>> +#define TYPE_MICROVM_MACHINE MACHINE_TYPE_NAME("microvm")
>
> Using MACHINE_TYPE_NAME("microvm") might eventually cause
> conflicts with the "microvm" alias you are registering. I
> suggest using something like "microvm-machine-base".
>
> A separate base class will only be necessary if you are really
> planning to provide multiple versions of the machine type,
> though.
Ack.
Thanks!
Sergio.
>> +#define MICROVM_MACHINE(obj) \
>> + OBJECT_CHECK(MicrovmMachineState, (obj), TYPE_MICROVM_MACHINE)
>> +#define MICROVM_MACHINE_GET_CLASS(obj) \
>> + OBJECT_GET_CLASS(MicrovmMachineClass, obj, TYPE_MICROVM_MACHINE)
>> +#define MICROVM_MACHINE_CLASS(class) \
>> + OBJECT_CLASS_CHECK(MicrovmMachineClass, class, TYPE_MICROVM_MACHINE)
>> +
>> +#endif
>> --
>> 2.21.0
>>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2019-06-28 21:44 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-28 11:53 [Qemu-devel] [PATCH 0/4] Introduce the microvm machine type Sergio Lopez
2019-06-28 11:53 ` [Qemu-devel] [PATCH 1/4] hw/i386: Factorize CPU routine Sergio Lopez
2019-06-28 20:03 ` Eduardo Habkost
2019-06-28 21:44 ` Sergio Lopez
2019-07-01 9:25 ` Michael S. Tsirkin
2019-06-28 11:53 ` [Qemu-devel] [PATCH 2/4] hw/virtio: Factorize virtio-mmio headers Sergio Lopez
2019-06-28 14:03 ` Michael S. Tsirkin
2019-06-28 20:50 ` Sergio Lopez
2019-06-30 21:36 ` Michael S. Tsirkin
2019-07-02 8:19 ` Gerd Hoffmann
2019-07-02 13:22 ` Michael S. Tsirkin
2019-06-28 11:53 ` [Qemu-devel] [PATCH 3/4] hw/i386: Add an Intel MPTable generator Sergio Lopez
2019-06-28 11:53 ` [Qemu-devel] [PATCH 4/4] hw/i386: Introduce the microvm machine type Sergio Lopez
2019-06-28 14:06 ` Michael S. Tsirkin
2019-06-28 20:56 ` Sergio Lopez
2019-06-28 22:17 ` Paolo Bonzini
2019-06-30 21:37 ` Michael S. Tsirkin
2019-06-28 19:15 ` Maran Wilson
2019-06-28 21:05 ` Sergio Lopez
2019-06-28 21:54 ` Maran Wilson
2019-06-28 22:23 ` Sergio Lopez
2019-06-28 21:56 ` Paolo Bonzini
2019-06-28 19:47 ` Eduardo Habkost
2019-06-28 21:42 ` Sergio Lopez [this message]
2019-06-28 21:57 ` Paolo Bonzini
2019-06-28 13:21 ` [Qemu-devel] [PATCH 0/4] " Paolo Bonzini
2019-06-28 20:49 ` Sergio Lopez
2019-06-28 16:32 ` no-reply
2019-06-28 18:16 ` no-reply
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=87mui1wfmr.fsf@redhat.com \
--to=slp@redhat.com \
--cc=ehabkost@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.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).