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_libvirt > = 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list