From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57799) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFcXw-0006nK-S1 for qemu-devel@nongnu.org; Wed, 22 Jun 2016 03:26:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bFcXr-00067m-MZ for qemu-devel@nongnu.org; Wed, 22 Jun 2016 03:25:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35502) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFcXr-00067Y-EN for qemu-devel@nongnu.org; Wed, 22 Jun 2016 03:25:55 -0400 Date: Wed, 22 Jun 2016 09:26:21 +0200 From: Jiri Denemark Message-ID: <20160622072621.GH2450045@orkuz.home> References: <1466514153-85777-1-git-send-email-dahi@linux.vnet.ibm.com> <20160621164431.GI2048@thinpad.lan.raisama.net> <20160621190144.174c93cd@thinkpad-w530> <20160621203309.GK2048@thinpad.lan.raisama.net> <20160621210949.GH4783@orkuz.home> <20160622085140.06984206@thinkpad-w530> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160622085140.06984206@thinkpad-w530> Subject: Re: [Qemu-devel] [RFC 00/28] s390x CPU models: exposing features List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: David Hildenbrand Cc: Eduardo Habkost , qemu-devel@nongnu.org, imammedo@redhat.com, cornelia.huck@de.ibm.com, borntraeger@de.ibm.com, fiuczy@linux.vnet.ibm.com, mimu@linux.vnet.ibm.com, libvir-list@redhat.com 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