From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41230) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VdGPA-0007wK-VI for qemu-devel@nongnu.org; Mon, 04 Nov 2013 04:25:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VdGP5-0005YE-EJ for qemu-devel@nongnu.org; Mon, 04 Nov 2013 04:25:04 -0500 Received: from mail-pd0-f172.google.com ([209.85.192.172]:36493) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VdGP5-0005Y5-4k for qemu-devel@nongnu.org; Mon, 04 Nov 2013 04:24:59 -0500 Received: by mail-pd0-f172.google.com with SMTP id w10so6494326pde.3 for ; Mon, 04 Nov 2013 01:24:57 -0800 (PST) Message-ID: <527767E4.9040306@ozlabs.ru> Date: Mon, 04 Nov 2013 20:24:52 +1100 From: Alexey Kardashevskiy MIME-Version: 1.0 References: <1383536166-8673-1-git-send-email-aik@ozlabs.ru> <527761B7.8050402@ozlabs.ru> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH] RFC: powerpc: add PVR compatibility check List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: QEMU Developers , Paul Mackerras , Anthony Liguori , "list@suse.de:PReP" , open@suse.de, =?UTF-8?B?QW5kcmVhcyBGw6RyYmVy?= On 11/04/2013 08:05 PM, Alexander Graf wrote: > > On 04.11.2013, at 09:58, Alexey Kardashevskiy wrote: > >> On 11/04/2013 06:47 PM, Alexander Graf wrote: >>> >>> On 04.11.2013, at 04:36, Alexey Kardashevskiy wrote: >>> >>>> If QEMU is started with KVM enabled and -cpu specified, and the CPU is not >>>> from the family which the host is running on, an error should be displayed >>>> so this the patch does. >>>> >>>> Cc: Andreas Färber >>>> Signed-off-by: Alexey Kardashevskiy >>>> >>>> --- >>>> >>>> Is that correct to assume that the closest abstract class is a CPU family? >>>> It is most likely true but I want to double check :) >>> >>> I don't think this is correct. KVM on POWER7 is compatible to run a 750 >>> vcpu for example. >> >> >> Are you talking about PR KVM or HV KVM now? > > We are talking about QEMU here which means we always have to take the > whole picture into account. The 750-on-POWER7 case only works with PR > KVM. > >> How does it work? What are the >> PCR's v2.05/v.206 bits in this case? They must be set to something, no? >> >> I understood this as with KVM we have to create CPU of the family which the >> host CPU belongs to and if we want to support some lower version, then we >> use compatibility mode. Hm. > > That's HV KVM specific. There is no reason a user couldn't use QEMU on PR KVM. > >> >> >>>> Is there any nicer way of doing what the patch does? >>> >> >>> The only instance that knows whether it's compatible or not is the kvm >>> kernel module. Currently the only way we can check compatibility is >>> through the "pvr" value that user space pushes into the kernel. >> >> HV KVM does not virtualize PVR and the userspace can only try PCR which >> defines very few compatibility modes and KVM can fail on setting wrong modes. > > HV KVM should simply fail when vcpu pvr != host pvr. More precisely, pvr&mask != host_pvr&mask. That is what I really wanted here but I do not know how to distinguish PR and HV KVM in target-ppc/translate_init.c. >>> I see two ways we can enhance this. We could add checks to kvm's HV >>> mode to make sure the guest vcpu type is compatible. Since the list >>> of supported PVRs is quite small this might even be feasible. >> >> Since the list is small and we know all possible combinations - why to >> bother about this in the kernel? > > Yeah, we really need to check that guest vpcu == host vcpu for HV KVM. > >> >>> The other thing that would be nice would be to transfer a full blob of >>> capabilities into kvm that we can match for, similar to how cpuid on x86 >>> works. That way we can then match host features with guest features and >>> can check compatibility on a much more fine grained level. >> >> We have such a blob, it is called "client-architecture-support" :) But it >> is PAPR, i.e. "proprietary" :( And again, there is nothing (yet?) which we >> cannot process in QEMU and can in KVM. > > Please start to think outside of the HV KVM box. I am trying. I looked through PowerISA and did not find any mechanism to tell the guest whether the host supports Altivec or not. So I assumed that PR KVM can only do it by setting a PVR of a CPU which does or does not support Altivec. Yes, my patch does not take PR KVM into account, this is why it is an "RFC" patch and I am asking all these stupid questions as I do not really understand where to insert such a check in QEMU. After all, now it seems right to do this check in KVM to avoid having PR vs. HV cases in QEMU. >>> The big benefit of the second approach is that when someone crazy enough >>> comes in to implement e500mc on book3s kvm for example, he could do that >>> simply by setting a few different capability bits. It would also make >>> paired single selection more obvious for example. And we could limit >>> Altivec access to only CPUs that have it rather than exposing it for all >>> as we do today. >> >> I am confused. How do existing guest kernels know if Altivec is supported >> or not? I thought this is nailed to PVR and you cannot expose standalone >> features. > > Yes, today the only way we tell the kernel whether a guest vcpu supports > Altivec is through PVR. That was a bad design decision. I think it would > make more sense to give kvm a full list of features it can then base on > rather than only the PVR. We could then check those features against > host features, in the emulator and in external feature (altivec, spe, > fpu, etc) enablement. What will KVM do with those bits? How exactly will it tell the _guest_ that it does or does not support Altivec? I mean, in addition to setting a correct PVR? May be there is some good specification (besides PowerISA) which I am missing? -- Alexey