On Fri, Mar 01, 2013 at 11:56:00PM +0100, Jiri Denemark wrote: [...] > > > > = 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. > > Ah, it seems logical now that you mention it :-) > > > * 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? > > Yes, that seems like it could work. In fact, it seems much better than > using enforce and trying to deal with aborted QEMU. To make the libvirt logic simpler, we could do this: have a "force" mode (in addition to check/enforce), that wouldn't filter any CPU feature based on host capabilities. This way libvirt wouldn't need any non-trivial logic to combine the "f-*" flags and "removed-features" to find out the CPU model details. Then libvirt would need to look only at "f-*" to find out the CPU model details at probing time (as long as "force" is used at probing time), and just make sure "removed-features" is empty before starting the VM (optionally parsing its value or checking the "f-*" property values, to find out which features are missing exactly). -- Eduardo -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list