7:12 a.m.
On Thu, Feb 21, 2013 at 11:58:18 -0300, Eduardo Habkost wrote:
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...
= 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.
Definitely, we plan to start using "enforce" flag as soon as we have
better CPU probing interface with QEMU. Since libvirt does not currently
consult CPU specs with QEMU, some configurations in fact rely on QEMU
dropping features it can't provide. Of course, that's bad for several
reasons but we don't want such configurations to suddenly stop working.
We want to first fix the CPU specs libvirt creates so that we know they
will work with "enforce".
Limitation: no proper machine-friendly interface to report which
features
are missing.
Workaround: See "querying for host capabilities" below.
I doubt we will be ready to start using "enforce" before the machine
friendly interface is available...
= 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.
No problem, we already run QEMU and use several QMP commands to probe
its capabilities. And "qom-list-types" is actually one of them. To get
the list of CPU models, we would just call
{
"execute": "qom-list-types",
"arguments": {
"implements": "X86CPU"
}
}
right? What about other non-x86 architectures? Will we need to use
different class name or is there a generic CPU class that could be used
universally?
Solution: use QMP query-cpu-definitions command.
Limitation: needs a live QEMU process for the query.
IIUC, the result of this command will depend on machine type and we
can't use -M none we currently use for probing, right?
== 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.
Hmm, so is this complete machine needed even for getting CPU models from
qom-list-types or only for querying exact definitions using
query-cpu-definitions command?
Actually, what is query-cpu-definitions supposed to return? Currently it
seems it's just the CPU model names rather than details about all CPU
models. From the command name, one would expect to get more than just
names.
= 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.
This would be very useful for ensuring the guest sees the exact same CPU
after it's been migrated or restored from a stored state or a snapshot.
Should we make sure the guest will always see the same CPU even after
shutdown or is it ok if the guest CPU changes a bit on next boot, e.g.,
in case the host kernel was upgraded and is able to provide more
features?
However, probing several CPU definitions for compatibility with
host/kernel/QEMU would be quite inefficient. Although I guess we should
be able to limit doing so only in case a specific API (e.g.,
virConnectCompareCPU or virConnectBaselineCPU) is called, which would be
acceptable, I think.
= 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.
If we have machine friendly output of -cpu enforce, we may limit this
need to just a few configuration types (the ones effectively requesting
some kind of "host" CPU model). For other cases, libvirt could just try
to start QEMU with the requested CPU definition and report usable error
back rather than trying to pre-check the CPU.
Jirka