[PATCH 0/3] QEMU kvm: Adding KICK_VCPU capability to i386 kvm

[PATCH 0/3] QEMU kvm: Adding KICK_VCPU capability to i386 kvm

[Raghavendra K T]

From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>

Three patch series following this, extends KVM-hypervisor
and Linux guest running on KVM-hypervisor to support pv-ticket spinlocks.

PV ticket spinlock helps to solve Lock Holder Preemption problem discussed in
http://www.amd64.org/fileadmin/user_upload/pub/LHP-commented_slides.pdf.

When spinlock is contended,a guest vcpu relinqueshes cpu by halt().
Correspondingly, One hypercall is introduced in KVM hypervisor,that allows
a vcpu to kick the halted vcpu to continue with execution.

The series will : 
- Update qemu with latest linux header files (to 3.2.0-rc1).
- Enable KICK_VCPU capability in kvm/i386.

Raghavendra K T(3):
  Sync the linux headers to 3.2.0-rc1
  Sync the linux headers to patched linux kernel with 
	KICK_VCPU capability.
  Add KICK_VCPU support in i386 target

---
The corresponding kernel patch is available in the thread
https://lkml.org/lkml/2011/11/30/62

[Qemu-devel] [PATCH 0/3] QEMU kvm: Adding KICK_VCPU capability to i386 kvm

[Raghavendra K T]

From: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>

Three patch series following this, extends KVM-hypervisor
and Linux guest running on KVM-hypervisor to support pv-ticket spinlocks.

PV ticket spinlock helps to solve Lock Holder Preemption problem discussed in
http://www.amd64.org/fileadmin/user_upload/pub/LHP-commented_slides.pdf.

When spinlock is contended,a guest vcpu relinqueshes cpu by halt().
Correspondingly, One hypercall is introduced in KVM hypervisor,that allows
a vcpu to kick the halted vcpu to continue with execution.

The series will : 
- Update qemu with latest linux header files (to 3.2.0-rc1).
- Enable KICK_VCPU capability in kvm/i386.

Raghavendra K T(3):
  Sync the linux headers to 3.2.0-rc1
  Sync the linux headers to patched linux kernel with 
	KICK_VCPU capability.
  Add KICK_VCPU support in i386 target

---
The corresponding kernel patch is available in the thread
https://lkml.org/lkml/2011/11/30/62

[PATCH 1/3] QEMU kvm: Syncing linux headers to 3.2.0-rc1

[Raghavendra K T]

 Update the kvm kernel headers to the 3.2.0-rc1 post using
scripts/update-linux-headers.sh script.

Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
diff --git a/linux-headers/asm-powerpc/kvm.h b/linux-headers/asm-powerpc/kvm.h
index fb3fddc..08fe69e 100644
--- a/linux-headers/asm-powerpc/kvm.h
+++ b/linux-headers/asm-powerpc/kvm.h
@@ -149,6 +149,12 @@ struct kvm_regs {
 #define KVM_SREGS_E_UPDATE_DBSR		(1 << 3)
 
 /*
+ * Book3S special bits to indicate contents in the struct by maintaining
+ * backwards compatibility with older structs. If adding a new field,
+ * please make sure to add a flag for that new field */
+#define KVM_SREGS_S_HIOR		(1 << 0)
+
+/*
  * In KVM_SET_SREGS, reserved/pad fields must be left untouched from a
  * previous KVM_GET_REGS.
  *
@@ -170,9 +176,11 @@ struct kvm_sregs {
 			} ppc64;
 			struct {
 				__u32 sr[16];
-				__u64 ibat[8];
-				__u64 dbat[8];
+				__u64 ibat[8]; 
+				__u64 dbat[8]; 
 			} ppc32;
+			__u64 flags; /* KVM_SREGS_S_ */
+			__u64 hior;
 		} s;
 		struct {
 			union {
@@ -292,41 +300,4 @@ struct kvm_allocate_rma {
 	__u64 rma_size;
 };
 
-struct kvm_book3e_206_tlb_entry {
-	__u32 mas8;
-	__u32 mas1;
-	__u64 mas2;
-	__u64 mas7_3;
-};
-
-struct kvm_book3e_206_tlb_params {
-	/*
-	 * For mmu types KVM_MMU_FSL_BOOKE_NOHV and KVM_MMU_FSL_BOOKE_HV:
-	 *
-	 * - The number of ways of TLB0 must be a power of two between 2 and
-	 *   16.
-	 * - TLB1 must be fully associative.
-	 * - The size of TLB0 must be a multiple of the number of ways, and
-	 *   the number of sets must be a power of two.
-	 * - The size of TLB1 may not exceed 64 entries.
-	 * - TLB0 supports 4 KiB pages.
-	 * - The page sizes supported by TLB1 are as indicated by
-	 *   TLB1CFG (if MMUCFG[MAVN] = 0) or TLB1PS (if MMUCFG[MAVN] = 1)
-	 *   as returned by KVM_GET_SREGS.
-	 * - TLB2 and TLB3 are reserved, and their entries in tlb_sizes[]
-	 *   and tlb_ways[] must be zero.
-	 *
-	 * tlb_ways[n] = tlb_sizes[n] means the array is fully associative.
-	 *
-	 * KVM will adjust TLBnCFG based on the sizes configured here,
-	 * though arrays greater than 2048 entries will have TLBnCFG[NENTRY]
-	 * set to zero.
-	 */
-	__u32 tlb_sizes[4];
-	__u32 tlb_ways[4];
-	__u32 reserved[8];
-};
-
-#define KVM_ONE_REG_PPC_HIOR	KVM_ONE_REG_PPC | 0x100
-
 #endif /* __LINUX_KVM_POWERPC_H */
diff --git a/linux-headers/asm-x86/hyperv.h b/linux-headers/asm-x86/hyperv.h
index 5df477a..b80420b 100644
--- a/linux-headers/asm-x86/hyperv.h
+++ b/linux-headers/asm-x86/hyperv.h
@@ -189,5 +189,6 @@
 #define HV_STATUS_INVALID_HYPERCALL_CODE	2
 #define HV_STATUS_INVALID_HYPERCALL_INPUT	3
 #define HV_STATUS_INVALID_ALIGNMENT		4
+#define HV_STATUS_INSUFFICIENT_BUFFERS		19
 
 #endif
diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index a8761d3..07bd557 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/linux/kvm.h
@@ -371,6 +371,7 @@ struct kvm_s390_psw {
 #define KVM_S390_INT_VIRTIO		0xffff2603u
 #define KVM_S390_INT_SERVICE		0xffff2401u
 #define KVM_S390_INT_EMERGENCY		0xffff1201u
+#define KVM_S390_INT_EXTERNAL_CALL	0xffff1202u
 
 struct kvm_s390_interrupt {
 	__u32 type;
@@ -556,8 +557,7 @@ struct kvm_ppc_pvinfo {
 #define KVM_CAP_MAX_VCPUS 66       /* returns max vcpus per vm */
 #define KVM_CAP_PPC_HIOR 67
 #define KVM_CAP_PPC_PAPR 68
-#define KVM_CAP_SW_TLB 69
-#define KVM_CAP_ONE_REG 70
+#define KVM_CAP_S390_GMAP 71
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
@@ -637,49 +637,6 @@ struct kvm_clock_data {
 	__u32 pad[9];
 };
 
-#define KVM_MMU_FSL_BOOKE_NOHV		0
-#define KVM_MMU_FSL_BOOKE_HV		1
-
-struct kvm_config_tlb {
-	__u64 params;
-	__u64 array;
-	__u32 mmu_type;
-	__u32 array_len;
-};
-
-struct kvm_dirty_tlb {
-	__u64 bitmap;
-	__u32 num_dirty;
-};
-
-/* Available with KVM_CAP_ONE_REG */
-
-#define KVM_ONE_REG_GENERIC		0x0000000000000000ULL
-
-/*
- * Architecture specific registers are to be defined in arch headers and
- * ORed with the arch identifier.
- */
-#define KVM_ONE_REG_PPC			0x1000000000000000ULL
-#define KVM_ONE_REG_X86			0x2000000000000000ULL
-#define KVM_ONE_REG_IA64		0x3000000000000000ULL
-#define KVM_ONE_REG_ARM			0x4000000000000000ULL
-#define KVM_ONE_REG_S390		0x5000000000000000ULL
-
-struct kvm_one_reg {
-	__u64 id;
-	union {
-		__u8 reg8;
-		__u16 reg16;
-		__u32 reg32;
-		__u64 reg64;
-		__u8 reg128[16];
-		__u8 reg256[32];
-		__u8 reg512[64];
-		__u8 reg1024[128];
-	} u;
-};
-
 /*
  * ioctls for VM fds
  */
@@ -806,11 +763,6 @@ struct kvm_one_reg {
 #define KVM_CREATE_SPAPR_TCE	  _IOW(KVMIO,  0xa8, struct kvm_create_spapr_tce)
 /* Available with KVM_CAP_RMA */
 #define KVM_ALLOCATE_RMA	  _IOR(KVMIO,  0xa9, struct kvm_allocate_rma)
-/* Available with KVM_CAP_SW_TLB */
-#define KVM_DIRTY_TLB		  _IOW(KVMIO,  0xaa, struct kvm_dirty_tlb)
-/* Available with KVM_CAP_ONE_REG */
-#define KVM_GET_ONE_REG		  _IOWR(KVMIO, 0xab, struct kvm_one_reg)
-#define KVM_SET_ONE_REG		  _IOW(KVMIO,  0xac, struct kvm_one_reg)
 
 #define KVM_DEV_ASSIGN_ENABLE_IOMMU	(1 << 0)
 
diff --git a/linux-headers/linux/virtio_ring.h b/linux-headers/linux/virtio_ring.h
index 78289ee..1b333e2 100644
--- a/linux-headers/linux/virtio_ring.h
+++ b/linux-headers/linux/virtio_ring.h
@@ -135,13 +135,13 @@ static __inline__ void vring_init(struct vring *vr, unsigned int num, void *p,
 	vr->num = num;
 	vr->desc = p;
 	vr->avail = p + num*sizeof(struct vring_desc);
-	vr->used = (void *)(((unsigned long)&vr->avail->ring[num] + align-1)
-			    & ~(align - 1));
+	vr->used = (void *)(((unsigned long)&vr->avail->ring[num] + sizeof(__u16)
+		+ align-1) & ~(align - 1));
 }
 
 static __inline__ unsigned vring_size(unsigned int num, unsigned long align)
 {
-	return ((sizeof(struct vring_desc) * num + sizeof(__u16) * (2 + num)
+	return ((sizeof(struct vring_desc) * num + sizeof(__u16) * (3 + num)
 		 + align - 1) & ~(align - 1))
 		+ sizeof(__u16) * 3 + sizeof(struct vring_used_elem) * num;
 }

[Qemu-devel] [PATCH 1/3] QEMU kvm: Syncing linux headers to 3.2.0-rc1

[Raghavendra K T]

 Update the kvm kernel headers to the 3.2.0-rc1 post using
scripts/update-linux-headers.sh script.

Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
diff --git a/linux-headers/asm-powerpc/kvm.h b/linux-headers/asm-powerpc/kvm.h
index fb3fddc..08fe69e 100644
--- a/linux-headers/asm-powerpc/kvm.h
+++ b/linux-headers/asm-powerpc/kvm.h
@@ -149,6 +149,12 @@ struct kvm_regs {
 #define KVM_SREGS_E_UPDATE_DBSR		(1 << 3)
 
 /*
+ * Book3S special bits to indicate contents in the struct by maintaining
+ * backwards compatibility with older structs. If adding a new field,
+ * please make sure to add a flag for that new field */
+#define KVM_SREGS_S_HIOR		(1 << 0)
+
+/*
  * In KVM_SET_SREGS, reserved/pad fields must be left untouched from a
  * previous KVM_GET_REGS.
  *
@@ -170,9 +176,11 @@ struct kvm_sregs {
 			} ppc64;
 			struct {
 				__u32 sr[16];
-				__u64 ibat[8];
-				__u64 dbat[8];
+				__u64 ibat[8]; 
+				__u64 dbat[8]; 
 			} ppc32;
+			__u64 flags; /* KVM_SREGS_S_ */
+			__u64 hior;
 		} s;
 		struct {
 			union {
@@ -292,41 +300,4 @@ struct kvm_allocate_rma {
 	__u64 rma_size;
 };
 
-struct kvm_book3e_206_tlb_entry {
-	__u32 mas8;
-	__u32 mas1;
-	__u64 mas2;
-	__u64 mas7_3;
-};
-
-struct kvm_book3e_206_tlb_params {
-	/*
-	 * For mmu types KVM_MMU_FSL_BOOKE_NOHV and KVM_MMU_FSL_BOOKE_HV:
-	 *
-	 * - The number of ways of TLB0 must be a power of two between 2 and
-	 *   16.
-	 * - TLB1 must be fully associative.
-	 * - The size of TLB0 must be a multiple of the number of ways, and
-	 *   the number of sets must be a power of two.
-	 * - The size of TLB1 may not exceed 64 entries.
-	 * - TLB0 supports 4 KiB pages.
-	 * - The page sizes supported by TLB1 are as indicated by
-	 *   TLB1CFG (if MMUCFG[MAVN] = 0) or TLB1PS (if MMUCFG[MAVN] = 1)
-	 *   as returned by KVM_GET_SREGS.
-	 * - TLB2 and TLB3 are reserved, and their entries in tlb_sizes[]
-	 *   and tlb_ways[] must be zero.
-	 *
-	 * tlb_ways[n] = tlb_sizes[n] means the array is fully associative.
-	 *
-	 * KVM will adjust TLBnCFG based on the sizes configured here,
-	 * though arrays greater than 2048 entries will have TLBnCFG[NENTRY]
-	 * set to zero.
-	 */
-	__u32 tlb_sizes[4];
-	__u32 tlb_ways[4];
-	__u32 reserved[8];
-};
-
-#define KVM_ONE_REG_PPC_HIOR	KVM_ONE_REG_PPC | 0x100
-
 #endif /* __LINUX_KVM_POWERPC_H */
diff --git a/linux-headers/asm-x86/hyperv.h b/linux-headers/asm-x86/hyperv.h
index 5df477a..b80420b 100644
--- a/linux-headers/asm-x86/hyperv.h
+++ b/linux-headers/asm-x86/hyperv.h
@@ -189,5 +189,6 @@
 #define HV_STATUS_INVALID_HYPERCALL_CODE	2
 #define HV_STATUS_INVALID_HYPERCALL_INPUT	3
 #define HV_STATUS_INVALID_ALIGNMENT		4
+#define HV_STATUS_INSUFFICIENT_BUFFERS		19
 
 #endif
diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index a8761d3..07bd557 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/linux/kvm.h
@@ -371,6 +371,7 @@ struct kvm_s390_psw {
 #define KVM_S390_INT_VIRTIO		0xffff2603u
 #define KVM_S390_INT_SERVICE		0xffff2401u
 #define KVM_S390_INT_EMERGENCY		0xffff1201u
+#define KVM_S390_INT_EXTERNAL_CALL	0xffff1202u
 
 struct kvm_s390_interrupt {
 	__u32 type;
@@ -556,8 +557,7 @@ struct kvm_ppc_pvinfo {
 #define KVM_CAP_MAX_VCPUS 66       /* returns max vcpus per vm */
 #define KVM_CAP_PPC_HIOR 67
 #define KVM_CAP_PPC_PAPR 68
-#define KVM_CAP_SW_TLB 69
-#define KVM_CAP_ONE_REG 70
+#define KVM_CAP_S390_GMAP 71
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
@@ -637,49 +637,6 @@ struct kvm_clock_data {
 	__u32 pad[9];
 };
 
-#define KVM_MMU_FSL_BOOKE_NOHV		0
-#define KVM_MMU_FSL_BOOKE_HV		1
-
-struct kvm_config_tlb {
-	__u64 params;
-	__u64 array;
-	__u32 mmu_type;
-	__u32 array_len;
-};
-
-struct kvm_dirty_tlb {
-	__u64 bitmap;
-	__u32 num_dirty;
-};
-
-/* Available with KVM_CAP_ONE_REG */
-
-#define KVM_ONE_REG_GENERIC		0x0000000000000000ULL
-
-/*
- * Architecture specific registers are to be defined in arch headers and
- * ORed with the arch identifier.
- */
-#define KVM_ONE_REG_PPC			0x1000000000000000ULL
-#define KVM_ONE_REG_X86			0x2000000000000000ULL
-#define KVM_ONE_REG_IA64		0x3000000000000000ULL
-#define KVM_ONE_REG_ARM			0x4000000000000000ULL
-#define KVM_ONE_REG_S390		0x5000000000000000ULL
-
-struct kvm_one_reg {
-	__u64 id;
-	union {
-		__u8 reg8;
-		__u16 reg16;
-		__u32 reg32;
-		__u64 reg64;
-		__u8 reg128[16];
-		__u8 reg256[32];
-		__u8 reg512[64];
-		__u8 reg1024[128];
-	} u;
-};
-
 /*
  * ioctls for VM fds
  */
@@ -806,11 +763,6 @@ struct kvm_one_reg {
 #define KVM_CREATE_SPAPR_TCE	  _IOW(KVMIO,  0xa8, struct kvm_create_spapr_tce)
 /* Available with KVM_CAP_RMA */
 #define KVM_ALLOCATE_RMA	  _IOR(KVMIO,  0xa9, struct kvm_allocate_rma)
-/* Available with KVM_CAP_SW_TLB */
-#define KVM_DIRTY_TLB		  _IOW(KVMIO,  0xaa, struct kvm_dirty_tlb)
-/* Available with KVM_CAP_ONE_REG */
-#define KVM_GET_ONE_REG		  _IOWR(KVMIO, 0xab, struct kvm_one_reg)
-#define KVM_SET_ONE_REG		  _IOW(KVMIO,  0xac, struct kvm_one_reg)
 
 #define KVM_DEV_ASSIGN_ENABLE_IOMMU	(1 << 0)
 
diff --git a/linux-headers/linux/virtio_ring.h b/linux-headers/linux/virtio_ring.h
index 78289ee..1b333e2 100644
--- a/linux-headers/linux/virtio_ring.h
+++ b/linux-headers/linux/virtio_ring.h
@@ -135,13 +135,13 @@ static __inline__ void vring_init(struct vring *vr, unsigned int num, void *p,
 	vr->num = num;
 	vr->desc = p;
 	vr->avail = p + num*sizeof(struct vring_desc);
-	vr->used = (void *)(((unsigned long)&vr->avail->ring[num] + align-1)
-			    & ~(align - 1));
+	vr->used = (void *)(((unsigned long)&vr->avail->ring[num] + sizeof(__u16)
+		+ align-1) & ~(align - 1));
 }
 
 static __inline__ unsigned vring_size(unsigned int num, unsigned long align)
 {
-	return ((sizeof(struct vring_desc) * num + sizeof(__u16) * (2 + num)
+	return ((sizeof(struct vring_desc) * num + sizeof(__u16) * (3 + num)
 		 + align - 1) & ~(align - 1))
 		+ sizeof(__u16) * 3 + sizeof(struct vring_used_elem) * num;
 }

Re: [PATCH 1/3] QEMU kvm: Syncing linux headers to 3.2.0-rc1

[Alexander Graf]

On 04.12.2011, at 19:25, Raghavendra K T wrote:

> Update the kvm kernel headers to the 3.2.0-rc1 post using
> scripts/update-linux-headers.sh script.
> 
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> ---
> diff --git a/linux-headers/asm-powerpc/kvm.h b/linux-headers/asm-powerpc/kvm.h
> index fb3fddc..08fe69e 100644
> --- a/linux-headers/asm-powerpc/kvm.h
> +++ b/linux-headers/asm-powerpc/kvm.h
> @@ -149,6 +149,12 @@ struct kvm_regs {
> #define KVM_SREGS_E_UPDATE_DBSR		(1 << 3)
> 
> /*
> + * Book3S special bits to indicate contents in the struct by maintaining
> + * backwards compatibility with older structs. If adding a new field,
> + * please make sure to add a flag for that new field */
> +#define KVM_SREGS_S_HIOR		(1 << 0)
> +
> +/*
>  * In KVM_SET_SREGS, reserved/pad fields must be left untouched from a
>  * previous KVM_GET_REGS.
>  *
> @@ -170,9 +176,11 @@ struct kvm_sregs {
> 			} ppc64;
> 			struct {
> 				__u32 sr[16];
> -				__u64 ibat[8];
> -				__u64 dbat[8];
> +				__u64 ibat[8]; 
> +				__u64 dbat[8]; 
> 			} ppc32;
> +			__u64 flags; /* KVM_SREGS_S_ */
> +			__u64 hior;
> 		} s;
> 		struct {
> 			union {
> @@ -292,41 +300,4 @@ struct kvm_allocate_rma {
> 	__u64 rma_size;
> };
> 
> -struct kvm_book3e_206_tlb_entry {
> -	__u32 mas8;
> -	__u32 mas1;
> -	__u64 mas2;
> -	__u64 mas7_3;
> -};
> -
> -struct kvm_book3e_206_tlb_params {
> -	/*
> -	 * For mmu types KVM_MMU_FSL_BOOKE_NOHV and KVM_MMU_FSL_BOOKE_HV:
> -	 *
> -	 * - The number of ways of TLB0 must be a power of two between 2 and
> -	 *   16.
> -	 * - TLB1 must be fully associative.
> -	 * - The size of TLB0 must be a multiple of the number of ways, and
> -	 *   the number of sets must be a power of two.
> -	 * - The size of TLB1 may not exceed 64 entries.
> -	 * - TLB0 supports 4 KiB pages.
> -	 * - The page sizes supported by TLB1 are as indicated by
> -	 *   TLB1CFG (if MMUCFG[MAVN] = 0) or TLB1PS (if MMUCFG[MAVN] = 1)
> -	 *   as returned by KVM_GET_SREGS.
> -	 * - TLB2 and TLB3 are reserved, and their entries in tlb_sizes[]
> -	 *   and tlb_ways[] must be zero.
> -	 *
> -	 * tlb_ways[n] = tlb_sizes[n] means the array is fully associative.
> -	 *
> -	 * KVM will adjust TLBnCFG based on the sizes configured here,
> -	 * though arrays greater than 2048 entries will have TLBnCFG[NENTRY]
> -	 * set to zero.
> -	 */
> -	__u32 tlb_sizes[4];
> -	__u32 tlb_ways[4];
> -	__u32 reserved[8];
> -};
> -
> -#define KVM_ONE_REG_PPC_HIOR	KVM_ONE_REG_PPC | 0x100
> -
> #endif /* __LINUX_KVM_POWERPC_H */
> diff --git a/linux-headers/asm-x86/hyperv.h b/linux-headers/asm-x86/hyperv.h
> index 5df477a..b80420b 100644
> --- a/linux-headers/asm-x86/hyperv.h
> +++ b/linux-headers/asm-x86/hyperv.h
> @@ -189,5 +189,6 @@
> #define HV_STATUS_INVALID_HYPERCALL_CODE	2
> #define HV_STATUS_INVALID_HYPERCALL_INPUT	3
> #define HV_STATUS_INVALID_ALIGNMENT		4
> +#define HV_STATUS_INSUFFICIENT_BUFFERS		19
> 
> #endif
> diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
> index a8761d3..07bd557 100644
> --- a/linux-headers/linux/kvm.h
> +++ b/linux-headers/linux/kvm.h
> @@ -371,6 +371,7 @@ struct kvm_s390_psw {
> #define KVM_S390_INT_VIRTIO		0xffff2603u
> #define KVM_S390_INT_SERVICE		0xffff2401u
> #define KVM_S390_INT_EMERGENCY		0xffff1201u
> +#define KVM_S390_INT_EXTERNAL_CALL	0xffff1202u
> 
> struct kvm_s390_interrupt {
> 	__u32 type;
> @@ -556,8 +557,7 @@ struct kvm_ppc_pvinfo {
> #define KVM_CAP_MAX_VCPUS 66       /* returns max vcpus per vm */
> #define KVM_CAP_PPC_HIOR 67
> #define KVM_CAP_PPC_PAPR 68
> -#define KVM_CAP_SW_TLB 69
> -#define KVM_CAP_ONE_REG 70
> +#define KVM_CAP_S390_GMAP 71
> 
> #ifdef KVM_CAP_IRQ_ROUTING
> 
> @@ -637,49 +637,6 @@ struct kvm_clock_data {
> 	__u32 pad[9];
> };
> 
> -#define KVM_MMU_FSL_BOOKE_NOHV		0
> -#define KVM_MMU_FSL_BOOKE_HV		1
> -
> -struct kvm_config_tlb {
> -	__u64 params;
> -	__u64 array;
> -	__u32 mmu_type;
> -	__u32 array_len;
> -};
> -
> -struct kvm_dirty_tlb {
> -	__u64 bitmap;
> -	__u32 num_dirty;
> -};
> -
> -/* Available with KVM_CAP_ONE_REG */
> -
> -#define KVM_ONE_REG_GENERIC		0x0000000000000000ULL

You're removing definitions here, indicating that something is going wrong :).


Alex

Re: [Qemu-devel] [PATCH 1/3] QEMU kvm: Syncing linux headers to 3.2.0-rc1

[Alexander Graf]

On 04.12.2011, at 19:25, Raghavendra K T wrote:

> Update the kvm kernel headers to the 3.2.0-rc1 post using
> scripts/update-linux-headers.sh script.
> 
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> ---
> diff --git a/linux-headers/asm-powerpc/kvm.h b/linux-headers/asm-powerpc/kvm.h
> index fb3fddc..08fe69e 100644
> --- a/linux-headers/asm-powerpc/kvm.h
> +++ b/linux-headers/asm-powerpc/kvm.h
> @@ -149,6 +149,12 @@ struct kvm_regs {
> #define KVM_SREGS_E_UPDATE_DBSR		(1 << 3)
> 
> /*
> + * Book3S special bits to indicate contents in the struct by maintaining
> + * backwards compatibility with older structs. If adding a new field,
> + * please make sure to add a flag for that new field */
> +#define KVM_SREGS_S_HIOR		(1 << 0)
> +
> +/*
>  * In KVM_SET_SREGS, reserved/pad fields must be left untouched from a
>  * previous KVM_GET_REGS.
>  *
> @@ -170,9 +176,11 @@ struct kvm_sregs {
> 			} ppc64;
> 			struct {
> 				__u32 sr[16];
> -				__u64 ibat[8];
> -				__u64 dbat[8];
> +				__u64 ibat[8]; 
> +				__u64 dbat[8]; 
> 			} ppc32;
> +			__u64 flags; /* KVM_SREGS_S_ */
> +			__u64 hior;
> 		} s;
> 		struct {
> 			union {
> @@ -292,41 +300,4 @@ struct kvm_allocate_rma {
> 	__u64 rma_size;
> };
> 
> -struct kvm_book3e_206_tlb_entry {
> -	__u32 mas8;
> -	__u32 mas1;
> -	__u64 mas2;
> -	__u64 mas7_3;
> -};
> -
> -struct kvm_book3e_206_tlb_params {
> -	/*
> -	 * For mmu types KVM_MMU_FSL_BOOKE_NOHV and KVM_MMU_FSL_BOOKE_HV:
> -	 *
> -	 * - The number of ways of TLB0 must be a power of two between 2 and
> -	 *   16.
> -	 * - TLB1 must be fully associative.
> -	 * - The size of TLB0 must be a multiple of the number of ways, and
> -	 *   the number of sets must be a power of two.
> -	 * - The size of TLB1 may not exceed 64 entries.
> -	 * - TLB0 supports 4 KiB pages.
> -	 * - The page sizes supported by TLB1 are as indicated by
> -	 *   TLB1CFG (if MMUCFG[MAVN] = 0) or TLB1PS (if MMUCFG[MAVN] = 1)
> -	 *   as returned by KVM_GET_SREGS.
> -	 * - TLB2 and TLB3 are reserved, and their entries in tlb_sizes[]
> -	 *   and tlb_ways[] must be zero.
> -	 *
> -	 * tlb_ways[n] = tlb_sizes[n] means the array is fully associative.
> -	 *
> -	 * KVM will adjust TLBnCFG based on the sizes configured here,
> -	 * though arrays greater than 2048 entries will have TLBnCFG[NENTRY]
> -	 * set to zero.
> -	 */
> -	__u32 tlb_sizes[4];
> -	__u32 tlb_ways[4];
> -	__u32 reserved[8];
> -};
> -
> -#define KVM_ONE_REG_PPC_HIOR	KVM_ONE_REG_PPC | 0x100
> -
> #endif /* __LINUX_KVM_POWERPC_H */
> diff --git a/linux-headers/asm-x86/hyperv.h b/linux-headers/asm-x86/hyperv.h
> index 5df477a..b80420b 100644
> --- a/linux-headers/asm-x86/hyperv.h
> +++ b/linux-headers/asm-x86/hyperv.h
> @@ -189,5 +189,6 @@
> #define HV_STATUS_INVALID_HYPERCALL_CODE	2
> #define HV_STATUS_INVALID_HYPERCALL_INPUT	3
> #define HV_STATUS_INVALID_ALIGNMENT		4
> +#define HV_STATUS_INSUFFICIENT_BUFFERS		19
> 
> #endif
> diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
> index a8761d3..07bd557 100644
> --- a/linux-headers/linux/kvm.h
> +++ b/linux-headers/linux/kvm.h
> @@ -371,6 +371,7 @@ struct kvm_s390_psw {
> #define KVM_S390_INT_VIRTIO		0xffff2603u
> #define KVM_S390_INT_SERVICE		0xffff2401u
> #define KVM_S390_INT_EMERGENCY		0xffff1201u
> +#define KVM_S390_INT_EXTERNAL_CALL	0xffff1202u
> 
> struct kvm_s390_interrupt {
> 	__u32 type;
> @@ -556,8 +557,7 @@ struct kvm_ppc_pvinfo {
> #define KVM_CAP_MAX_VCPUS 66       /* returns max vcpus per vm */
> #define KVM_CAP_PPC_HIOR 67
> #define KVM_CAP_PPC_PAPR 68
> -#define KVM_CAP_SW_TLB 69
> -#define KVM_CAP_ONE_REG 70
> +#define KVM_CAP_S390_GMAP 71
> 
> #ifdef KVM_CAP_IRQ_ROUTING
> 
> @@ -637,49 +637,6 @@ struct kvm_clock_data {
> 	__u32 pad[9];
> };
> 
> -#define KVM_MMU_FSL_BOOKE_NOHV		0
> -#define KVM_MMU_FSL_BOOKE_HV		1
> -
> -struct kvm_config_tlb {
> -	__u64 params;
> -	__u64 array;
> -	__u32 mmu_type;
> -	__u32 array_len;
> -};
> -
> -struct kvm_dirty_tlb {
> -	__u64 bitmap;
> -	__u32 num_dirty;
> -};
> -
> -/* Available with KVM_CAP_ONE_REG */
> -
> -#define KVM_ONE_REG_GENERIC		0x0000000000000000ULL

You're removing definitions here, indicating that something is going wrong :).


Alex

[PATCH 2/3] QEMU kvm: Syncing linux headers to support KICK_VCPU capability

[Raghavendra K T]

Update the kernel header that adds a hypercall to support pv-ticketlocks.

Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
diff --git a/linux-headers/asm-x86/kvm_para.h b/linux-headers/asm-x86/kvm_para.h
index f2ac46a..03d3a36 100644
--- a/linux-headers/asm-x86/kvm_para.h
+++ b/linux-headers/asm-x86/kvm_para.h
@@ -16,12 +16,14 @@
 #define KVM_FEATURE_CLOCKSOURCE		0
 #define KVM_FEATURE_NOP_IO_DELAY	1
 #define KVM_FEATURE_MMU_OP		2
+
 /* This indicates that the new set of kvmclock msrs
  * are available. The use of 0x11 and 0x12 is deprecated
  */
 #define KVM_FEATURE_CLOCKSOURCE2        3
 #define KVM_FEATURE_ASYNC_PF		4
 #define KVM_FEATURE_STEAL_TIME		5
+#define KVM_FEATURE_KICK_VCPU		6
 
 /* The last 8 bits are used to indicate how to interpret the flags field
  * in pvclock structure. If no bits are set, all flags are ignored.
diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index 07bd557..47ab6ff 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/linux/kvm.h
@@ -558,6 +558,7 @@ struct kvm_ppc_pvinfo {
 #define KVM_CAP_PPC_HIOR 67
 #define KVM_CAP_PPC_PAPR 68
 #define KVM_CAP_S390_GMAP 71
+#define KVM_CAP_KICK_VCPU 72
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
diff --git a/linux-headers/linux/kvm_para.h b/linux-headers/linux/kvm_para.h
index b315e27..e4a0e3e 100644
--- a/linux-headers/linux/kvm_para.h
+++ b/linux-headers/linux/kvm_para.h
@@ -19,6 +19,7 @@
 #define KVM_HC_MMU_OP			2
 #define KVM_HC_FEATURES			3
 #define KVM_HC_PPC_MAP_MAGIC_PAGE	4
+#define KVM_HC_KICK_CPU			5
 
 /*
  * hypercalls use architecture specific

[Qemu-devel] [PATCH 2/3] QEMU kvm: Syncing linux headers to support KICK_VCPU capability

[Raghavendra K T]

Update the kernel header that adds a hypercall to support pv-ticketlocks.

Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
diff --git a/linux-headers/asm-x86/kvm_para.h b/linux-headers/asm-x86/kvm_para.h
index f2ac46a..03d3a36 100644
--- a/linux-headers/asm-x86/kvm_para.h
+++ b/linux-headers/asm-x86/kvm_para.h
@@ -16,12 +16,14 @@
 #define KVM_FEATURE_CLOCKSOURCE		0
 #define KVM_FEATURE_NOP_IO_DELAY	1
 #define KVM_FEATURE_MMU_OP		2
+
 /* This indicates that the new set of kvmclock msrs
  * are available. The use of 0x11 and 0x12 is deprecated
  */
 #define KVM_FEATURE_CLOCKSOURCE2        3
 #define KVM_FEATURE_ASYNC_PF		4
 #define KVM_FEATURE_STEAL_TIME		5
+#define KVM_FEATURE_KICK_VCPU		6
 
 /* The last 8 bits are used to indicate how to interpret the flags field
  * in pvclock structure. If no bits are set, all flags are ignored.
diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index 07bd557..47ab6ff 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/linux/kvm.h
@@ -558,6 +558,7 @@ struct kvm_ppc_pvinfo {
 #define KVM_CAP_PPC_HIOR 67
 #define KVM_CAP_PPC_PAPR 68
 #define KVM_CAP_S390_GMAP 71
+#define KVM_CAP_KICK_VCPU 72
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
diff --git a/linux-headers/linux/kvm_para.h b/linux-headers/linux/kvm_para.h
index b315e27..e4a0e3e 100644
--- a/linux-headers/linux/kvm_para.h
+++ b/linux-headers/linux/kvm_para.h
@@ -19,6 +19,7 @@
 #define KVM_HC_MMU_OP			2
 #define KVM_HC_FEATURES			3
 #define KVM_HC_PPC_MAP_MAGIC_PAGE	4
+#define KVM_HC_KICK_CPU			5
 
 /*
  * hypercalls use architecture specific

Re: [PATCH 2/3] QEMU kvm: Syncing linux headers to support KICK_VCPU capability

[Alexander Graf]

On 04.12.2011, at 19:26, Raghavendra K T wrote:

> Update the kernel header that adds a hypercall to support pv-ticketlocks.
> 
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> ---
> diff --git a/linux-headers/asm-x86/kvm_para.h b/linux-headers/asm-x86/kvm_para.h

You're patching the synced kernel headers? This is definitely wrong. The workflow is always kernel headers -> qemu linux-headers. We don't patch anything in linux-headers manually. Everything goes through the sync script.


Alex

Re: [Qemu-devel] [PATCH 2/3] QEMU kvm: Syncing linux headers to support KICK_VCPU capability

[Alexander Graf]

On 04.12.2011, at 19:26, Raghavendra K T wrote:

> Update the kernel header that adds a hypercall to support pv-ticketlocks.
> 
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> ---
> diff --git a/linux-headers/asm-x86/kvm_para.h b/linux-headers/asm-x86/kvm_para.h

You're patching the synced kernel headers? This is definitely wrong. The workflow is always kernel headers -> qemu linux-headers. We don't patch anything in linux-headers manually. Everything goes through the sync script.


Alex

[PATCH 3/3] QEMU kvm/i386 : Adding KICK_VCPU capability support in i386 target.

[Raghavendra K T]

 Extend the KVM Hypervisor to enable KICK_VCPU feature that allows
a vcpu to kick the halted vcpu to continue with execution in PV ticket
spinlock.

Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 5bfc21f..69bce21 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -97,6 +97,7 @@ struct kvm_para_features {
     { KVM_CAP_NOP_IO_DELAY, KVM_FEATURE_NOP_IO_DELAY },
     { KVM_CAP_PV_MMU, KVM_FEATURE_MMU_OP },
     { KVM_CAP_ASYNC_PF, KVM_FEATURE_ASYNC_PF },
+    { KVM_CAP_KICK_VCPU, KVM_FEATURE_KICK_VCPU },
     { -1, -1 }
 };
 

[Qemu-devel] [PATCH 3/3] QEMU kvm/i386 : Adding KICK_VCPU capability support in i386 target.

[Raghavendra K T]

 Extend the KVM Hypervisor to enable KICK_VCPU feature that allows
a vcpu to kick the halted vcpu to continue with execution in PV ticket
spinlock.

Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
---
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 5bfc21f..69bce21 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -97,6 +97,7 @@ struct kvm_para_features {
     { KVM_CAP_NOP_IO_DELAY, KVM_FEATURE_NOP_IO_DELAY },
     { KVM_CAP_PV_MMU, KVM_FEATURE_MMU_OP },
     { KVM_CAP_ASYNC_PF, KVM_FEATURE_ASYNC_PF },
+    { KVM_CAP_KICK_VCPU, KVM_FEATURE_KICK_VCPU },
     { -1, -1 }
 };
 

Re: [PATCH 3/3] QEMU kvm/i386 : Adding KICK_VCPU capability support in i386 target.

[Alexander Graf]

On 04.12.2011, at 19:26, Raghavendra K T wrote:

> Extend the KVM Hypervisor to enable KICK_VCPU feature that allows
> a vcpu to kick the halted vcpu to continue with execution in PV ticket
> spinlock.
> 
> Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> ---
> diff --git a/target-i386/kvm.c b/target-i386/kvm.c
> index 5bfc21f..69bce21 100644
> --- a/target-i386/kvm.c
> +++ b/target-i386/kvm.c
> @@ -97,6 +97,7 @@ struct kvm_para_features {
>     { KVM_CAP_NOP_IO_DELAY, KVM_FEATURE_NOP_IO_DELAY },
>     { KVM_CAP_PV_MMU, KVM_FEATURE_MMU_OP },
>     { KVM_CAP_ASYNC_PF, KVM_FEATURE_ASYNC_PF },
> +    { KVM_CAP_KICK_VCPU, KVM_FEATURE_KICK_VCPU },

So this is handled in the kernel? Who enables the feature? Is it always on? Why bother with it in user space at all then?


Alex

Re: [Qemu-devel] [PATCH 3/3] QEMU kvm/i386 : Adding KICK_VCPU capability support in i386 target.

[Alexander Graf]

On 04.12.2011, at 19:26, Raghavendra K T wrote:

> Extend the KVM Hypervisor to enable KICK_VCPU feature that allows
> a vcpu to kick the halted vcpu to continue with execution in PV ticket
> spinlock.
> 
> Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> ---
> diff --git a/target-i386/kvm.c b/target-i386/kvm.c
> index 5bfc21f..69bce21 100644
> --- a/target-i386/kvm.c
> +++ b/target-i386/kvm.c
> @@ -97,6 +97,7 @@ struct kvm_para_features {
>     { KVM_CAP_NOP_IO_DELAY, KVM_FEATURE_NOP_IO_DELAY },
>     { KVM_CAP_PV_MMU, KVM_FEATURE_MMU_OP },
>     { KVM_CAP_ASYNC_PF, KVM_FEATURE_ASYNC_PF },
> +    { KVM_CAP_KICK_VCPU, KVM_FEATURE_KICK_VCPU },

So this is handled in the kernel? Who enables the feature? Is it always on? Why bother with it in user space at all then?


Alex

Re: [PATCH 3/3] QEMU kvm/i386 : Adding KICK_VCPU capability support in i386 target.

[Avi Kivity]

On 12/19/2011 03:54 PM, Alexander Graf wrote:
> On 04.12.2011, at 19:26, Raghavendra K T wrote:
>
> > Extend the KVM Hypervisor to enable KICK_VCPU feature that allows
> > a vcpu to kick the halted vcpu to continue with execution in PV ticket
> > spinlock.
> > 
> > Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> > Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> > ---
> > diff --git a/target-i386/kvm.c b/target-i386/kvm.c
> > index 5bfc21f..69bce21 100644
> > --- a/target-i386/kvm.c
> > +++ b/target-i386/kvm.c
> > @@ -97,6 +97,7 @@ struct kvm_para_features {
> >     { KVM_CAP_NOP_IO_DELAY, KVM_FEATURE_NOP_IO_DELAY },
> >     { KVM_CAP_PV_MMU, KVM_FEATURE_MMU_OP },
> >     { KVM_CAP_ASYNC_PF, KVM_FEATURE_ASYNC_PF },
> > +    { KVM_CAP_KICK_VCPU, KVM_FEATURE_KICK_VCPU },
>
> So this is handled in the kernel? Who enables the feature? Is it always on? Why bother with it in user space at all then?

Backwards compatibility

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH 3/3] QEMU kvm/i386 : Adding KICK_VCPU capability support in i386 target.

[Avi Kivity]

On 12/19/2011 03:54 PM, Alexander Graf wrote:
> On 04.12.2011, at 19:26, Raghavendra K T wrote:
>
> > Extend the KVM Hypervisor to enable KICK_VCPU feature that allows
> > a vcpu to kick the halted vcpu to continue with execution in PV ticket
> > spinlock.
> > 
> > Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
> > Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
> > ---
> > diff --git a/target-i386/kvm.c b/target-i386/kvm.c
> > index 5bfc21f..69bce21 100644
> > --- a/target-i386/kvm.c
> > +++ b/target-i386/kvm.c
> > @@ -97,6 +97,7 @@ struct kvm_para_features {
> >     { KVM_CAP_NOP_IO_DELAY, KVM_FEATURE_NOP_IO_DELAY },
> >     { KVM_CAP_PV_MMU, KVM_FEATURE_MMU_OP },
> >     { KVM_CAP_ASYNC_PF, KVM_FEATURE_ASYNC_PF },
> > +    { KVM_CAP_KICK_VCPU, KVM_FEATURE_KICK_VCPU },
>
> So this is handled in the kernel? Who enables the feature? Is it always on? Why bother with it in user space at all then?

Backwards compatibility

-- 
error compiling committee.c: too many arguments to function

Re: [PATCH 3/3] QEMU kvm/i386 : Adding KICK_VCPU capability support in i386 target.

[Alexander Graf]

On 19.12.2011, at 14:59, Avi Kivity wrote:

> On 12/19/2011 03:54 PM, Alexander Graf wrote:
>> On 04.12.2011, at 19:26, Raghavendra K T wrote:
>> 
>>> Extend the KVM Hypervisor to enable KICK_VCPU feature that allows
>>> a vcpu to kick the halted vcpu to continue with execution in PV ticket
>>> spinlock.
>>> 
>>> Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
>>> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
>>> ---
>>> diff --git a/target-i386/kvm.c b/target-i386/kvm.c
>>> index 5bfc21f..69bce21 100644
>>> --- a/target-i386/kvm.c
>>> +++ b/target-i386/kvm.c
>>> @@ -97,6 +97,7 @@ struct kvm_para_features {
>>>    { KVM_CAP_NOP_IO_DELAY, KVM_FEATURE_NOP_IO_DELAY },
>>>    { KVM_CAP_PV_MMU, KVM_FEATURE_MMU_OP },
>>>    { KVM_CAP_ASYNC_PF, KVM_FEATURE_ASYNC_PF },
>>> +    { KVM_CAP_KICK_VCPU, KVM_FEATURE_KICK_VCPU },
>> 
>> So this is handled in the kernel? Who enables the feature? Is it always on? Why bother with it in user space at all then?
> 
> Backwards compatibility

If we want backwards compatibility, we need more than just a simple feature check, no? Oh, you feed that into CPUID? That's nifty. Ok, so you behave like VMX/SVM do on real hardware - you always expose the functionality but don't list it in CPUID for older user space.

Makes sense.


Alex

Re: [Qemu-devel] [PATCH 3/3] QEMU kvm/i386 : Adding KICK_VCPU capability support in i386 target.

[Alexander Graf]

On 19.12.2011, at 14:59, Avi Kivity wrote:

> On 12/19/2011 03:54 PM, Alexander Graf wrote:
>> On 04.12.2011, at 19:26, Raghavendra K T wrote:
>> 
>>> Extend the KVM Hypervisor to enable KICK_VCPU feature that allows
>>> a vcpu to kick the halted vcpu to continue with execution in PV ticket
>>> spinlock.
>>> 
>>> Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
>>> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
>>> ---
>>> diff --git a/target-i386/kvm.c b/target-i386/kvm.c
>>> index 5bfc21f..69bce21 100644
>>> --- a/target-i386/kvm.c
>>> +++ b/target-i386/kvm.c
>>> @@ -97,6 +97,7 @@ struct kvm_para_features {
>>>    { KVM_CAP_NOP_IO_DELAY, KVM_FEATURE_NOP_IO_DELAY },
>>>    { KVM_CAP_PV_MMU, KVM_FEATURE_MMU_OP },
>>>    { KVM_CAP_ASYNC_PF, KVM_FEATURE_ASYNC_PF },
>>> +    { KVM_CAP_KICK_VCPU, KVM_FEATURE_KICK_VCPU },
>> 
>> So this is handled in the kernel? Who enables the feature? Is it always on? Why bother with it in user space at all then?
> 
> Backwards compatibility

If we want backwards compatibility, we need more than just a simple feature check, no? Oh, you feed that into CPUID? That's nifty. Ok, so you behave like VMX/SVM do on real hardware - you always expose the functionality but don't list it in CPUID for older user space.

Makes sense.


Alex

Re: [PATCH 3/3] QEMU kvm/i386 : Adding KICK_VCPU capability support in i386 target.

[Jan Kiszka]

On 2011-12-19 15:03, Alexander Graf wrote:
> 
> On 19.12.2011, at 14:59, Avi Kivity wrote:
> 
>> On 12/19/2011 03:54 PM, Alexander Graf wrote:
>>> On 04.12.2011, at 19:26, Raghavendra K T wrote:
>>>
>>>> Extend the KVM Hypervisor to enable KICK_VCPU feature that allows
>>>> a vcpu to kick the halted vcpu to continue with execution in PV ticket
>>>> spinlock.
>>>>
>>>> Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
>>>> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
>>>> ---
>>>> diff --git a/target-i386/kvm.c b/target-i386/kvm.c
>>>> index 5bfc21f..69bce21 100644
>>>> --- a/target-i386/kvm.c
>>>> +++ b/target-i386/kvm.c
>>>> @@ -97,6 +97,7 @@ struct kvm_para_features {
>>>>    { KVM_CAP_NOP_IO_DELAY, KVM_FEATURE_NOP_IO_DELAY },
>>>>    { KVM_CAP_PV_MMU, KVM_FEATURE_MMU_OP },
>>>>    { KVM_CAP_ASYNC_PF, KVM_FEATURE_ASYNC_PF },
>>>> +    { KVM_CAP_KICK_VCPU, KVM_FEATURE_KICK_VCPU },
>>>
>>> So this is handled in the kernel? Who enables the feature? Is it always on? Why bother with it in user space at all then?
>>
>> Backwards compatibility
> 
> If we want backwards compatibility, we need more than just a simple feature check, no? Oh, you feed that into CPUID? That's nifty. Ok, so you behave like VMX/SVM do on real hardware - you always expose the functionality but don't list it in CPUID for older user space.

Do we want this to be on when providing a compat machine type ("pc-0.12"
etc.) to the guest? Then it does need more work (see the dance around
kvmclock).

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] [PATCH 3/3] QEMU kvm/i386 : Adding KICK_VCPU capability support in i386 target.

[Jan Kiszka]

On 2011-12-19 15:03, Alexander Graf wrote:
> 
> On 19.12.2011, at 14:59, Avi Kivity wrote:
> 
>> On 12/19/2011 03:54 PM, Alexander Graf wrote:
>>> On 04.12.2011, at 19:26, Raghavendra K T wrote:
>>>
>>>> Extend the KVM Hypervisor to enable KICK_VCPU feature that allows
>>>> a vcpu to kick the halted vcpu to continue with execution in PV ticket
>>>> spinlock.
>>>>
>>>> Signed-off-by: Srivatsa Vaddagiri <vatsa@linux.vnet.ibm.com>
>>>> Signed-off-by: Raghavendra K T <raghavendra.kt@linux.vnet.ibm.com>
>>>> ---
>>>> diff --git a/target-i386/kvm.c b/target-i386/kvm.c
>>>> index 5bfc21f..69bce21 100644
>>>> --- a/target-i386/kvm.c
>>>> +++ b/target-i386/kvm.c
>>>> @@ -97,6 +97,7 @@ struct kvm_para_features {
>>>>    { KVM_CAP_NOP_IO_DELAY, KVM_FEATURE_NOP_IO_DELAY },
>>>>    { KVM_CAP_PV_MMU, KVM_FEATURE_MMU_OP },
>>>>    { KVM_CAP_ASYNC_PF, KVM_FEATURE_ASYNC_PF },
>>>> +    { KVM_CAP_KICK_VCPU, KVM_FEATURE_KICK_VCPU },
>>>
>>> So this is handled in the kernel? Who enables the feature? Is it always on? Why bother with it in user space at all then?
>>
>> Backwards compatibility
> 
> If we want backwards compatibility, we need more than just a simple feature check, no? Oh, you feed that into CPUID? That's nifty. Ok, so you behave like VMX/SVM do on real hardware - you always expose the functionality but don't list it in CPUID for older user space.

Do we want this to be on when providing a compat machine type ("pc-0.12"
etc.) to the guest? Then it does need more work (see the dance around
kvmclock).

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

Re: [PATCH 3/3] QEMU kvm/i386 : Adding KICK_VCPU capability support in i386 target.

[Avi Kivity]

On 12/19/2011 04:11 PM, Jan Kiszka wrote:
> >>
> >> Backwards compatibility
> > 
> > If we want backwards compatibility, we need more than just a simple feature check, no? Oh, you feed that into CPUID? That's nifty. Ok, so you behave like VMX/SVM do on real hardware - you always expose the functionality but don't list it in CPUID for older user space.
>
> Do we want this to be on when providing a compat machine type ("pc-0.12"
> etc.) to the guest? Then it does need more work (see the dance around
> kvmclock).

We do.  I have a feeling the whole cpuid stuff, paravirt and
non-paravirt, needs some fixing in this area.  It's different than the
normal compat code since not only qemu, but also kvm and the host cpu
have a say in what's supported and what's not.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH 3/3] QEMU kvm/i386 : Adding KICK_VCPU capability support in i386 target.

[Avi Kivity]

On 12/19/2011 04:11 PM, Jan Kiszka wrote:
> >>
> >> Backwards compatibility
> > 
> > If we want backwards compatibility, we need more than just a simple feature check, no? Oh, you feed that into CPUID? That's nifty. Ok, so you behave like VMX/SVM do on real hardware - you always expose the functionality but don't list it in CPUID for older user space.
>
> Do we want this to be on when providing a compat machine type ("pc-0.12"
> etc.) to the guest? Then it does need more work (see the dance around
> kvmclock).

We do.  I have a feeling the whole cpuid stuff, paravirt and
non-paravirt, needs some fixing in this area.  It's different than the
normal compat code since not only qemu, but also kvm and the host cpu
have a say in what's supported and what's not.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH 3/3] QEMU kvm/i386 : Adding KICK_VCPU capability support in i386 target.

[Raghavendra K T]

On 12/26/2011 07:37 PM, Avi Kivity wrote:
> On 12/19/2011 04:11 PM, Jan Kiszka wrote:
>>>>
>>>> Backwards compatibility
>>>
>>> If we want backwards compatibility, we need more than just a simple feature check, no? Oh, you feed that into CPUID? That's nifty. Ok, so you behave like VMX/SVM do on real hardware - you always expose the functionality but don't list it in CPUID for older user space.
>>
>> Do we want this to be on when providing a compat machine type ("pc-0.12"
>> etc.) to the guest? Then it does need more work (see the dance around
>> kvmclock).
>
> We do.  I have a feeling the whole cpuid stuff, paravirt and
> non-paravirt, needs some fixing in this area.  It's different than the
> normal compat code since not only qemu, but also kvm and the host cpu
> have a say in what's supported and what's not.
>

Sorry, missed all threads except this due to some problem with mail
client config.  Yet to explore on what is to be done, But I  Agree for
the changes and work needed in this direction.

Re: [Qemu-devel] [PATCH 3/3] QEMU kvm/i386 : Adding KICK_VCPU capability support in i386 target.

[Raghavendra K T]

On 12/26/2011 07:37 PM, Avi Kivity wrote:
> On 12/19/2011 04:11 PM, Jan Kiszka wrote:
>>>>
>>>> Backwards compatibility
>>>
>>> If we want backwards compatibility, we need more than just a simple feature check, no? Oh, you feed that into CPUID? That's nifty. Ok, so you behave like VMX/SVM do on real hardware - you always expose the functionality but don't list it in CPUID for older user space.
>>
>> Do we want this to be on when providing a compat machine type ("pc-0.12"
>> etc.) to the guest? Then it does need more work (see the dance around
>> kvmclock).
>
> We do.  I have a feeling the whole cpuid stuff, paravirt and
> non-paravirt, needs some fixing in this area.  It's different than the
> normal compat code since not only qemu, but also kvm and the host cpu
> have a say in what's supported and what's not.
>

Sorry, missed all threads except this due to some problem with mail
client config.  Yet to explore on what is to be done, But I  Agree for
the changes and work needed in this direction.