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