2) Requiring a running QEMU instance to run query-cpu-model-comparison
With my previous query-host-cpu proposal, the task of comparing the configuration requested by the user with host capabilities can be done directly by libvirt. This way, no extra QEMU instance needs to be run before starting a VM.
I think we can just easily get around this by not comparing a guest CPU to host (except for the explicit virConnectCompareCPU, which is not very useful in its current form anyway).
If there is some flexible way around that, great. But I think we (s390x) could life without this additional query.
So if I understand correctly, you say you don't need the API to compare guest CPU to host CPU, right? If so, that's exactly what I said too.
I think the coffee didn't do its work already :) . I wanted to write that we can _with_ this additional query. Meaning the involved overhead would be ok - in my opinion for s390x. What we could do to avoid one compare operation would be: a) Expand the host model b) Expand the target model (because on s390x we could have migration unsafe model) c) Work with the runnability information returned via query-cpu-definitions But as we have to do b) either way on s390x, we can directly do a compare operation. (which makes implementation a lot simpler, because libvirt then doesn't have to deal with any feature/model names). David