[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC 00/28] s390x CPU models: exposing features
From: |
Jiri Denemark |
Subject: |
Re: [Qemu-devel] [RFC 00/28] s390x CPU models: exposing features |
Date: |
Wed, 22 Jun 2016 09:26:21 +0200 |
User-agent: |
Mutt/1.5.24 (2015-08-30) |
On Wed, Jun 22, 2016 at 08:51:40 +0200, David Hildenbrand wrote:
> > On Tue, Jun 21, 2016 at 17:33:09 -0300, Eduardo Habkost wrote:
> > > On Tue, Jun 21, 2016 at 07:01:44PM +0200, David Hildenbrand wrote:
> > > I still don't think we want to set in stone that "the result the
> > > guest sees when using -cpu host" is always the same as "what the
> > > host supports running".
> > >
> > > For example: let's assume a given architecture have two features
> > > (A and B) that are both supported by the host but can never be
> > > enabled together. For actual "-cpu host" usage, QEMU would have
> > > to choose between enabling A and B. For querying host
> > > capabilities, we still want to let management software know that
> > > either A or B are supported.
> >
> > What libvirt is really interested in is the guest CPU which would be
> > used with -cpu host. This is actually what I thought query-host-cpu was
> > all about. Perhaps because there's no difference for x86.
>
> That's also what I had in mind first. Let me explain why they are not the same
> on s390x and why it is problematic (actually both types are not the same!):
>
> 1. Certain CPU features are only valid for LPAR guests, they can't be
> virtualized for KVM guests (remember that we always have at least one level of
> virtualization on s390x). So we will never be able to provide these features
> to
> a KVM guest, therefore we will never be able to completely mimic the real host
> model.
>
> 2. We have a whole lot of unpublished features. We would have to include them
> in
> the "real host model", but we can't. For the "host" model, this is not a
> problem, because we simply don't virtualize them. But the "real host model"
> would then vary between say QEMZ versions, which looks really strage, because
> in essance, QEMU/KVM looks like the wrong interface to query for a "real host
> model".
>
> 3. We don't have the kernel interfaces in place to query the "real host
> model".
> We can only query what we are able to virtualize. And that is indeed different
> compared to what I said previously.
>
> And as I can't see any use case for s390x, we most probably will never be able
> to support the interface you are suggesting here. Which is fine, if it makes
> sense for x86.
Well, as I said I always thought about query-host-cpu as a way to get
the CPU configuration QEMU would provide with -cpu host. Thanks to this
discussion I realized its semantics is different and thus what I really
need is actually the command you suggested, i.e.,
query-cpu-model-expansion.
> > > 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.
Jirka
- [Qemu-devel] [RFC 27/28] s390x/cpumodel: implement QMP interface "query-cpu-model-comparison", (continued)
- [Qemu-devel] [RFC 27/28] s390x/cpumodel: implement QMP interface "query-cpu-model-comparison", David Hildenbrand, 2016/06/21
- [Qemu-devel] [RFC 22/28] s390x/kvm: let the CPU model control CMM(A), David Hildenbrand, 2016/06/21
- Re: [Qemu-devel] [RFC 00/28] s390x CPU models: exposing features, Eduardo Habkost, 2016/06/21
- Re: [Qemu-devel] [RFC 00/28] s390x CPU models: exposing features, David Hildenbrand, 2016/06/21
- Re: [Qemu-devel] [RFC 00/28] s390x CPU models: exposing features, Eduardo Habkost, 2016/06/21
- Re: [Qemu-devel] [RFC 00/28] s390x CPU models: exposing features, Jiri Denemark, 2016/06/21
- Re: [Qemu-devel] [RFC 00/28] s390x CPU models: exposing features, Eduardo Habkost, 2016/06/21
- Re: [Qemu-devel] [libvirt] [RFC 00/28] s390x CPU models: exposing features, Jiri Denemark, 2016/06/22
- Re: [Qemu-devel] [libvirt] [RFC 00/28] s390x CPU models: exposing features, David Hildenbrand, 2016/06/22
- Re: [Qemu-devel] [RFC 00/28] s390x CPU models: exposing features, David Hildenbrand, 2016/06/22
- Re: [Qemu-devel] [RFC 00/28] s390x CPU models: exposing features,
Jiri Denemark <=
- Re: [Qemu-devel] [RFC 00/28] s390x CPU models: exposing features, David Hildenbrand, 2016/06/22
- Re: [Qemu-devel] [RFC 00/28] s390x CPU models: exposing features, Jiri Denemark, 2016/06/22
- Re: [Qemu-devel] [RFC 00/28] s390x CPU models: exposing features, David Hildenbrand, 2016/06/22
- Re: [Qemu-devel] [RFC 00/28] s390x CPU models: exposing features, Jiri Denemark, 2016/06/22
- Re: [Qemu-devel] [RFC 00/28] s390x CPU models: exposing features, David Hildenbrand, 2016/06/23
Re: [Qemu-devel] [RFC 00/28] s390x CPU models: exposing features, Jiri Denemark, 2016/06/21
Re: [Qemu-devel] [RFC 00/28] s390x CPU models: exposing features, David Hildenbrand, 2016/06/30