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

> > > = 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.