Re: [Qemu-devel] [RFC 00/28] s390x CPU models: exposing features

[David Hildenbrand]

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