Re: [libvirt] [RFC 00/28] s390x CPU models: exposing features
On Wed, Jun 22, 2016 at 09:54:51 +0200, David Hildenbrand wrote:
> > On Wed, Jun 22, 2016 at 09:34:49 +0200, David Hildenbrand wrote:
> > > 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).
> >
> > But why do you even need to do any comparison? Isn't it possible to let
> > QEMU do it when a domain starts? The thing is we should avoid doing
> > completely different things on each architecture.
> >
>
> Sure, QEMU will of course double check when starting the guest! So trying to
> start and failing is of course an option! So no check is needed if that is
> acceptable.
Yeah, I think it's the safest and easiest option now.
Jirka
Alright then, this RFC already handles that properly, so that seems to be
solved. The question now is if you guys see a fundamental problem in the way we
want to handle CPU models.
Especially
a) Having flexible, not migration safe CPU models that can be expanded to
migration safe models (using the expansion interface).
b) Letting QEMU carry out the task of comparing and baselining to be used
for e.g. for "virsh cpu-baseline" or "virsh cpu-compare".
c) Indicating the host model as the expansion of "-cpu host", e.g. for
"virsh
capabilities" (which says "host" for now for us).
Also, it will be good to know if the "expansion" interface with parameters
"full" or "migratable" is really helpful to you or if I should drop
that and
you will come up with an own "query-host-cpu".
We are also planning to implement the "query-cpu-definitions" runnability
information in the future, because as you said, it might be a good way to
quickly indicate runnable CPU models. But we are most likely not going to use it
for e.g. comparing or baselining or detection of runnability of a more complex
cpu model (having a lot of feature changes).
Thanks!
David