Add per guest pvr

This adds get/set pvr to differ wanted guest cpu on runtiome.
The intention to bring it up so early at the vm ioctl is that our kernel code can not know if which guest type we want to create on vcpu_create. Vcpu_create itself do not transport any structure and and is called before our hooks in the machine initialization.

We want to have our implementation ready to run different guest types at the same time, therefore we can't set this globally at the /dev/kvm ioctl. Currently this sets the pvr per machine while in the architecture itself it is a per processor attribute (this binds us to one processor type per virtual machine). If needed we might change this so that vcpu_create uses the last set vm pvr as pvr for a new cpu e.g create generic followed by coprocesser sequentially - comments?

Additionally this may later be extended to select the real pvr that e.g. will be presented to what a guest sees on a read to that spr. here the patch as it is atm folowed by the tlb patch that uses the function to select the right tlb layout.

Anyways, this probably isn't worth spending too much time on now. The immediate need is for the TLB accessors, and I think we can base those on the PVR without a full multi-arch guest solution.

Quoted 5 lines · On Wed, 2008-01-30 at 13:31 +0100, [email protected] wrote:

This adds get/set pvr to differ wanted guest cpu on runtiome.
The intention to bring it up so early at the vm ioctl is that our kernel code can not know if which guest type we want to create on vcpu_create. Vcpu_create itself do not transport any structure and and is called before our hooks in the machine initialization.

The analogue for x86 is cpuid, and that's handled as a vcpu ioctl. Of course, they don't go all the way with it, because their guests are somewhat tied to the host hardware (hardware manages e.g. guest register state).

Quoted 7 lines

We want to have our implementation ready to run different guest types at the same time, therefore we can't set this globally at the /dev/kvm ioctl. Currently this sets the pvr per machine while in the architecture itself it is a per processor attribute (this binds us to one processor type per virtual machine). If needed we might change this so that vcpu_create uses the last set vm pvr as pvr for a new cpu e.g create generic followed by coprocesser sequentially - comments?

Yes, I really don't like it. :) I think this should be a per-vcpu ioctl, and then we must make sure we've allocated enough vcpu memory for any guest architecture type (see vcpu_size as passed to kvm_init()).

Quoted 4 lines

Additionally this may later be extended to select the real pvr that e.g. will be presented to what a guest sees on a read to that spr. here the patch as it is atm folowed by the tlb patch that uses the function to select the right tlb layout.

Why aren't you using real PVR numbers already?

Anyways, this probably isn't worth spending too much time on now. The immediate need is for the TLB accessors, and I think we can base those on the PVR without a full multi-arch guest solution.

-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Thursday, January 31, 2008 10:57 PM
To: kvm-ppc-devel
Cc: Zhang Wei; Hollis Blanchard; [email protected]; [email protected]
Subject: [PATCH] [1/4] Add per guest pvr

Changed according to the comments of the first submission.

Subject: [PATCH] [1/4] Add per guest pvr
From: Christian Ehrhardt <[email protected]>

This adds a per vcpu call to get/set the the pvr in vcpu->arch.

Signed-off-by Christian Ehrhardt <[email protected]>

---

 arch/powerpc/kvm/powerpc.c |   13 +++++++++++++
 include/asm-powerpc/kvm.h  |    9 +++++++++
 include/linux/kvm.h        |    3 +++
 3 files changed, 25 insertions(+)

arch/powerpc/kvm/powerpc.c +13 -0

@@ -779,6 +779,19 @@ long kvm_arch_vcpu_ioctl(struct file *fi
 		r = kvm_vcpu_ioctl_interrupt(vcpu, &irq);
 		break;
 	}
+	case KVM_SET_GUEST_PVR: {
+		struct kvm_pvr __user *upvr = (struct kvm_pvr 
 __user *)arg;
+		r = copy_from_user(&(vcpu->arch.pvr), &(upvr->pvr),
+					sizeof(__u32));
+		break;
+	}
+	case KVM_GET_GUEST_PVR: {
+		struct kvm_pvr __user *upvr = (struct kvm_pvr 
 __user *)arg;
+		struct kvm_pvr kpvr;
+		kpvr.pvr = vcpu->arch.pvr;
+		r = copy_to_user(upvr, &kpvr, sizeof(struct kvm_pvr));
+		break;
+	}
 	default:

arch/powerpc/kvm/powerpc.c +0 -0

 		r = -EINVAL;
 	}

include/asm-powerpc/kvm.h +9 -0

@@ -53,4 +53,13 @@ struct kvm_fpu {
 struct kvm_fpu {
 };
 
+/*
+ * guest ident based on virtual pvr's to differ between cpu types
+ *  this may later on be extended to appear and behave as real pvr's
+*/
+#define KVM_PPC_PVR_PPC440EP 0x422218D3
+
+struct kvm_pvr {
+	__u32 pvr;
+};
 #endif /* __POWERPC_KVM_H__ */

include/linux/kvm.h +1 -0

@@ -249,6 +249,7 @@ struct kvm_vapic_addr {
 #define KVM_SET_USER_MEMORY_REGION _IOW(KVMIO, 0x46,\
 					struct 
 kvm_userspace_memory_region)
 #define KVM_SET_TSS_ADDR          _IO(KVMIO, 0x47)
+
 /*
  * KVM_CREATE_VCPU receives as a parameter the vcpu slot, and returns

* a vcpu fd.

include/linux/kvm.h +2 -0

@@ -288,5 +289,7 @@ struct kvm_vapic_addr {
 #define KVM_TPR_ACCESS_REPORTING  _IOWR(KVMIO,  0x92, struct 
 kvm_tpr_access_ctl)
 /* Available with KVM_CAP_VAPIC */
 #define KVM_SET_VAPIC_ADDR        _IOW(KVMIO,  0x93, struct 
 kvm_vapic_addr)
+#define KVM_SET_GUEST_PVR         _IOW(KVMIO,  0x94, struct kvm_pvr)
+#define KVM_GET_GUEST_PVR         _IOR(KVMIO,  0x95, struct kvm_pvr)

#endif