qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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(&microvm_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 --]

  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).