Re: [Qemu-devel] libvirt<->QEMU interfaces for CPU models

[Eduardo Habkost]

On Fri, Mar 01, 2013 at 02:28:37PM +0100, Jiri Denemark wrote:
> On Thu, Feb 21, 2013 at 11:58:18 -0300, Eduardo Habkost wrote:
> > = Querying host capabilities =
> > 
> > Requirement: libvirt needs to know which feature can really be enabled, 
> > before
> > it tries to start a VM, and before it tries to start a live-migration 
> > process.
> > 
> > The set of available capabilities depend on:
> > 
> >   • Host CPU (hardware) capabilities;
> >   • Kernel capabilities (reported by GET_SUPPORTED_CPUID);
> >   • QEMU capabilities;
> >   • Specific configuration options (e.g. in-kernel IRQ chip is required for
> >     some features).
> 
> Actually, one more thing. Can any of these requirements change while a
> host is up and QEMU is not upgraded? I believe, host CPU capabilities
> can only change when the host starts. Kernel capabilities are a bit less
> clear since I guess they could possibly change when kvm module is
> unloaded and loaded back with a different options. QEMU capabilities
> should only change when different version is installed. And the specific
> configuration options are the most unclear to me. The reason I'm asking
> is whether libvirt could run-time cache CPU definitions (including all
> model details) in the same way we currently cache QEMU capabilities,
> such as availability of specific QMP commands.


That's a good question. Let's check each item so I don't forget any
detail:

> >   • Host CPU (hardware) capabilities;

This shouldn't change without a host reboot.

> >   • Kernel capabilities (reported by GET_SUPPORTED_CPUID);

This may possibly change if the KVM module is unloaded and reloaded with
different options, but... I guess we should simply require libvirtd to
be restarted if any user does that?

> >   • QEMU capabilities;

This shouldn't change as long as the QEMU binary doesn't change.


> >   • Specific configuration options (e.g. in-kernel IRQ chip is required for
> >     some features).

This part seems tricky. Currently kernel-irqchip is probably the only
option that affects which features are available, but what if other QEMU
options affect the set of features too?

I believe the answer is to rely on machine-types. I mean: if a new
option that affects "-cpu host" and the set of available CPU features is
created, there are two options:

  1) Using the default value;
  2) Setting the option explicitly.

1) If using the default value, the default will depend on machine-type, so
libvirt should already consider machine-type as an option that affects
available-CPU-features.

2) If using an explicit value, libvirt should use the explicit value only
after being changed to take into account the fact that the option
affects available-CPU-features.

So, let's add one more item to the list. The set of available
capabilities depend on:

  • Host CPU (hardware) capabilities;
  • Kernel capabilities (reported by GET_SUPPORTED_CPUID);
  • QEMU capabilities;
  • Specific configuration options:
    • kernel-irqchip (currently affects tsc-deadline and x2apic, but may
      affect other features in the future)
    • machine-type (may affect any feature in the future)

-- 
Eduardo