8:58 a.m.
Hi,
After a long time trying to figure out the proper modelling inside QEMU,
I believe the plans are now clearer in QEMU, so it's time to coordinate
more closely with libvirt to try to make use of the new stuff.
I tried to enumerate the libvirt requirements and current problems, and
how we should be able to solve those problems using the X86CPU
subclasses and properties, on the following wiki page:
http://wiki.qemu.org/Features/CPUModels#Interfaces.2Frequirements_from_li...
I am pasting the section contents below, to facilitate discussion:
= Ensuring predictable set of guest features =
Requirement: libvirt needs to ensure all features required on the command-line
are present and exposed to the guest.
Current problem: libvirt doesn't use the "enforce" flag so it can't
guarantee
that a given feature will be actually exposed to the guest.
Solution: use the "enforce" flag on the "-cpu" option.
Limitation: no proper machine-friendly interface to report which features
are missing.
Workaround: See "querying for host capabilities" below.
== Future plans ==
Machine-friendly reporting of missing host features/capabilities.
= Listing CPU models =
Requirement: libvirt needs to know which CPU models are available to be used
with the "-cpu" option.
Current problem: libvirt relies on help output parsing for that.
Solution: use QMP qom-list-types command.
Dependency: X86CPU subclasses.
Limitation: needs a live QEMU process for the query.
Solution: use QMP query-cpu-definitions command.
Limitation: needs a live QEMU process for the query.
== Future plans ==
It would be interesting to get rid of the requirement for a live QEMU process
(with a complete machine being created) to be already running.
= Getting information about CPU models =
Requirement: libvirt uses the predefined CPU models from QEMU, but it needs to
be able to query for CPU model details, to find out how it can create a VM that
matches what was requested by the user.
Current problem: libvirt has a copy of the CPU model definitions on its
cpu_map.xml file, and the copy can be out of sync in case CPU models in QEMU
change. libvirt also assumes that the set of features on each model is always
the same on all machine-types, which is not true.
Challenge: the resulting CPU features depend on lots of factors, including
the machine-type.
Workaround: start a paused VM and query for the CPU device information
after the CPU was created.
Solution: start a paused VM with no devices, but with the right
machine-type and right CPU model. Use QMP QOM commands to query for CPU
flags (especially the properties starting with the "f-" prefix).
Dependency: X86CPU feature properties ("f-*" properties).
Limitation: requires a live QEMU process with the right machine-type/
CPU-model to be started, to make the query.
Requirement: libvirt needs to know if a specific CPU model can be used in the
current host.
See "Ensuring predictable set of guest features" above
See "Querying host capabilities" below
= 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).
Current problem: libvirt uses the CPUID intruction directly and assumes that
the presence of a feature in the host CPU means it can be enabled and exposed
to the guest. This breaks when virtualization of a feature requires:
• Additional hardware support (e.g. INVPCID);
• Additional host kernel code (this applies to _all_ CPU features, that need
to be reported as supported by GET_SUPPORTED_CPUID);
• Additional QEMU-side code;
• Specific configuration options (e.g. in-kernel IRQ chip).
Challenge: QEMU doesn't have a generic capability-querying interface, and host
capability querying depends on KVM to be initialized.
Workaround: start a paused VM using the "host" CPU model, that has every
single CPU feature supported by the host enabled by default, and query for
the information about the CPU though QMP, using the QOM commands.
Current solution: start a paused VM with no devices but with "host" CPU model
and use QMP QOM commands to query for the enabled CPU features.
Dependency: X86CPU feature properties
== Future plans ==
It would be interesting to have a more generic capability-querying interface
that doesn't require starting a whole machine with a live QEMU process.
See also: -query-capabilities RFC series from Anthony
Message-Id: <1332169763-30665-9-git-send-email-aliguori(a)us.ibm.com>
--
Eduardo