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

On Fri, Mar 01, 2013 at 02:12:38PM +0100, Jiri Denemark wrote: > 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". Also: more important than fixing the CPU definitions from libvirt, is to ask QEMU for host capabilities and CPU model definitions. The whole point of this is to solve the CPU model data duplication/synchronization problems between libvirt and QEMU. Once you are able to query CPU model definitions on runtime, you don't even need to make cpu_map.xml agree with QEMU. You can simply ask QEMU how each model looks like, and remove/add features from the command-line as necessary, so the resulting VM matches what the user asked for.

> > 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... If you query for the "-cpu host" capabilities first and ensure all features from a CPU model is available, enforce is supposed to not fail. I understand that a machine-friendly error reporting for "enforce" would be very useful, but note that if "enforce" fails, it is probably already too late for libvirt, and that means that what libvirt thinks about host capabilities and CPU models is already incorrect.

> > == 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? Maybe "complete machine" isn't the right expression, here. What I mean is: AFAIK, it is not possible to get a QMP monitor without actually having a machine being created by QEMU (even if it is a machine that will never run).

> > = 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. I just noticed another problem here, but this gave me an idea that would help solve the "enforce" error reporting problem: Problem: "qemu -machine <M> -cpu <model>" will create CPU objects where the CPU features are _already_ filtered based on host capabilities.

* Using "enforce" wouldn't solve it, because then QEMU would abort, and QMP would be unavailable. Solution: we could have a CPU object property like "removed-features" that would have the list of features that were disabled because they are not supported by the host (and would make "enforce" fail). * This would solve the problem above and also be a machine-friendly way to check for possible "enforce" errors. * In other words: instead of "enforce", libvirt could use "check" instead of "enforce", and before unpausing the VM (or even starting migration), it should first check if the "removed-features" property is empty. Would that work for you?