On 08.07.2009, at 00:50, Hollis Blanchard wrote:

On Tue, 2009-07-07 at 18:40 +0300, Avi Kivity wrote:
On 07/07/2009 05:17 PM, Alexander Graf wrote:
Right now sregs is unused on PPC, so we can use it for initialization
of the CPU.

KVM on BookE always virtualizes the host CPU. On PPC64 we go a step further and take the PVR from userspace that tells us what kind of CPU we are supposed
to virtualize, because we support PPC32 and PPC64 guests.

In order to get that information, we use the sregs ioctl, because we don't
want to reset the guest CPU on every normal register set.

Signed-off-by: Alexander Graf<ag...@suse.de>
---
 arch/powerpc/include/asm/kvm.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/include/asm/kvm.h b/arch/powerpc/include/ asm/kvm.h
index bb2de6a..96b02cd 100644
--- a/arch/powerpc/include/asm/kvm.h
+++ b/arch/powerpc/include/asm/kvm.h
@@ -46,6 +46,7 @@ struct kvm_regs {
 };

 struct kvm_sregs {
+       __u64 pvr;
 };


You can only do that if existing userspace never calls KVM_SET_SREGS.
Hollis?

It doesn't.

Also, make sure to reserve a bunch of space in there so you if you
forget something you can add it later.

Agreed.

The PVR register is basically the equivalent of cpuid. It might make
more sense to exit to qemu to handle those accesses. Today, PVR reads
are emulated in-kernel.

I actually use it in 970.c to find out which guest MMU to choose from.
So even if we were to do it in userspace, we'd still need the information what CPU to create in the guest on the kernel side. Which in turn means we don't win anything from leaving the PVR emulation to userspace.

Hmm, I don't remember where arch->vcpu.pvr is being set at all for 440
and e500...

It used to be in some creation code - either general kvm or vcpu. But some recent patch removed vcpu->arch.pvr and made emulate.c do an mfspr(SPRN_PVR).

Alex

--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to