Re: [libvirt] libvirt<->QEMU interfaces for CPU models
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