Re: [libvirt] [RFC 00/28] s390x CPU models: exposing features
> > > 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