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