State of KVM bits in linux-headers

State of KVM bits in linux-headers

[Jan Kiszka]

Hi,

I'm a bit unhappy about the current state of our supposed to be
automatically sync'ed linux-headers directory in qemu. It has been
updated several times against undefined kernel trees, means against
neither a released version nor kvm.git. Now, if I run an update against
kvm.git + some local change, I get a churn of removals. Same will happen
when that local change ever goes upstream before the other stuff got
finally committed.

Alex, it looks to me like this is mostly PPC stuff. Can you comment on
the origin and workflow? E.g. KVM_CAP_SW_TLB: This has been added half a
year ago but is not in any Linux release around. Fishy...

I would like to see us avoiding this in the future. Headers update
patches should mention the source and should not be merged until the ABI
changes actually made it at least into kvm.git. Same applies, of course,
to the functional changes related to that ABI. Otherwise we risk quite
some mess on everyone's side.

Another thing: KVM_CAP_PPC_HIOR has been removed again from the kernel
and also the header. Is there real free space now or will the cap
reappear? If there should better be a placeholder, let's add it (to the
kernel).

Jan

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

[Qemu-devel] State of KVM bits in linux-headers

[Jan Kiszka]

Hi,

I'm a bit unhappy about the current state of our supposed to be
automatically sync'ed linux-headers directory in qemu. It has been
updated several times against undefined kernel trees, means against
neither a released version nor kvm.git. Now, if I run an update against
kvm.git + some local change, I get a churn of removals. Same will happen
when that local change ever goes upstream before the other stuff got
finally committed.

Alex, it looks to me like this is mostly PPC stuff. Can you comment on
the origin and workflow? E.g. KVM_CAP_SW_TLB: This has been added half a
year ago but is not in any Linux release around. Fishy...

I would like to see us avoiding this in the future. Headers update
patches should mention the source and should not be merged until the ABI
changes actually made it at least into kvm.git. Same applies, of course,
to the functional changes related to that ABI. Otherwise we risk quite
some mess on everyone's side.

Another thing: KVM_CAP_PPC_HIOR has been removed again from the kernel
and also the header. Is there real free space now or will the cap
reappear? If there should better be a placeholder, let's add it (to the
kernel).

Jan

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

Re: State of KVM bits in linux-headers

[Alexander Graf]

On 11.01.2012, at 20:16, Jan Kiszka wrote:

> Hi,
> 
> I'm a bit unhappy about the current state of our supposed to be
> automatically sync'ed linux-headers directory in qemu. It has been
> updated several times against undefined kernel trees, means against
> neither a released version nor kvm.git. Now, if I run an update against
> kvm.git + some local change, I get a churn of removals. Same will happen
> when that local change ever goes upstream before the other stuff got
> finally committed.

Yes, call me even more unhappy about it :(.

> Alex, it looks to me like this is mostly PPC stuff. Can you comment on
> the origin and workflow? E.g. KVM_CAP_SW_TLB: This has been added half a
> year ago but is not in any Linux release around. Fishy...

Ok, here's my workflow:

  * KVM: receive patches on the ML
  * KVM: wait for reviews, review myself
  * KVM: send out a pull request
  -- this is the point in time where I assume the ABI can be considered stable --
  * QEMU: run update on the headers, because in a perfect world things should hit kvm.git any day
  * KVM: pull request gets reviews causing not-pulls or abi changes and lots of churn because i need forever to pullreq again ;)

I guess you see the problem. Hence I haven't pushed any kernel header updates since I realized how badly broken that process was. However even the stuff that's in qemu.git now hasn't managed to get upstream yet.

> I would like to see us avoiding this in the future. Headers update
> patches should mention the source and should not be merged until the ABI
> changes actually made it at least into kvm.git. Same applies, of course,
> to the functional changes related to that ABI. Otherwise we risk quite
> some mess on everyone's side.

I agree.

> Another thing: KVM_CAP_PPC_HIOR has been removed again from the kernel
> and also the header. Is there real free space now or will the cap
> reappear? If there should better be a placeholder, let's add it (to the
> kernel).

I will reappear with ONE_REG semantics.


Alex

Re: [Qemu-devel] State of KVM bits in linux-headers

[Alexander Graf]

On 11.01.2012, at 20:16, Jan Kiszka wrote:

> Hi,
> 
> I'm a bit unhappy about the current state of our supposed to be
> automatically sync'ed linux-headers directory in qemu. It has been
> updated several times against undefined kernel trees, means against
> neither a released version nor kvm.git. Now, if I run an update against
> kvm.git + some local change, I get a churn of removals. Same will happen
> when that local change ever goes upstream before the other stuff got
> finally committed.

Yes, call me even more unhappy about it :(.

> Alex, it looks to me like this is mostly PPC stuff. Can you comment on
> the origin and workflow? E.g. KVM_CAP_SW_TLB: This has been added half a
> year ago but is not in any Linux release around. Fishy...

Ok, here's my workflow:

  * KVM: receive patches on the ML
  * KVM: wait for reviews, review myself
  * KVM: send out a pull request
  -- this is the point in time where I assume the ABI can be considered stable --
  * QEMU: run update on the headers, because in a perfect world things should hit kvm.git any day
  * KVM: pull request gets reviews causing not-pulls or abi changes and lots of churn because i need forever to pullreq again ;)

I guess you see the problem. Hence I haven't pushed any kernel header updates since I realized how badly broken that process was. However even the stuff that's in qemu.git now hasn't managed to get upstream yet.

> I would like to see us avoiding this in the future. Headers update
> patches should mention the source and should not be merged until the ABI
> changes actually made it at least into kvm.git. Same applies, of course,
> to the functional changes related to that ABI. Otherwise we risk quite
> some mess on everyone's side.

I agree.

> Another thing: KVM_CAP_PPC_HIOR has been removed again from the kernel
> and also the header. Is there real free space now or will the cap
> reappear? If there should better be a placeholder, let's add it (to the
> kernel).

I will reappear with ONE_REG semantics.


Alex

[RFC][PATCH] Update linux headers against kvm.git

[Jan Kiszka]

On 2012-01-11 20:16, Jan Kiszka wrote:
> Hi,
> 
> I'm a bit unhappy about the current state of our supposed to be
> automatically sync'ed linux-headers directory in qemu. It has been
> updated several times against undefined kernel trees, means against
> neither a released version nor kvm.git. Now, if I run an update against
> kvm.git + some local change, I get a churn of removals. Same will happen
> when that local change ever goes upstream before the other stuff got
> finally committed.
> 
> Alex, it looks to me like this is mostly PPC stuff. Can you comment on
> the origin and workflow? E.g. KVM_CAP_SW_TLB: This has been added half a
> year ago but is not in any Linux release around. Fishy...
> 
> I would like to see us avoiding this in the future. Headers update
> patches should mention the source and should not be merged until the ABI
> changes actually made it at least into kvm.git. Same applies, of course,
> to the functional changes related to that ABI. Otherwise we risk quite
> some mess on everyone's side.
> 
> Another thing: KVM_CAP_PPC_HIOR has been removed again from the kernel
> and also the header. Is there real free space now or will the cap
> reappear? If there should better be a placeholder, let's add it (to the
> kernel).
> 
> Jan
> 

Just to underline this, not for merge (yet).

Is it clear that those PPC features will be merged upstream as-is now?

Jan

---8<---

This synchronizes our headers with kvm.git ff92e9b557 - and breaks PPC
build. Fairly telling...

---
 linux-headers/asm-powerpc/kvm.h   |   37 -------------------------
 linux-headers/asm-x86/hyperv.h    |    1 +
 linux-headers/linux/kvm.h         |   54 ++----------------------------------
 linux-headers/linux/kvm_para.h    |    1 -
 linux-headers/linux/virtio_ring.h |    6 ++--
 5 files changed, 7 insertions(+), 92 deletions(-)

diff --git a/linux-headers/asm-powerpc/kvm.h b/linux-headers/asm-powerpc/kvm.h
index fb3fddc..f7727d9 100644
--- a/linux-headers/asm-powerpc/kvm.h
+++ b/linux-headers/asm-powerpc/kvm.h
@@ -292,41 +292,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..e36ad9a 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;
@@ -554,10 +555,9 @@ struct kvm_ppc_pvinfo {
 #define KVM_CAP_PPC_SMT 64
 #define KVM_CAP_PPC_RMA	65
 #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
+#define KVM_CAP_TSC_DEADLINE_TIMER 72
 
 #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/kvm_para.h b/linux-headers/linux/kvm_para.h
index b315e27..7bdcf93 100644
--- a/linux-headers/linux/kvm_para.h
+++ b/linux-headers/linux/kvm_para.h
@@ -26,4 +26,3 @@
 #include <asm/kvm_para.h>
 
 #endif /* __LINUX_KVM_PARA_H */
-
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;
 }
-- 
1.7.3.4

[Qemu-devel] [RFC][PATCH] Update linux headers against kvm.git

[Jan Kiszka]

On 2012-01-11 20:16, Jan Kiszka wrote:
> Hi,
> 
> I'm a bit unhappy about the current state of our supposed to be
> automatically sync'ed linux-headers directory in qemu. It has been
> updated several times against undefined kernel trees, means against
> neither a released version nor kvm.git. Now, if I run an update against
> kvm.git + some local change, I get a churn of removals. Same will happen
> when that local change ever goes upstream before the other stuff got
> finally committed.
> 
> Alex, it looks to me like this is mostly PPC stuff. Can you comment on
> the origin and workflow? E.g. KVM_CAP_SW_TLB: This has been added half a
> year ago but is not in any Linux release around. Fishy...
> 
> I would like to see us avoiding this in the future. Headers update
> patches should mention the source and should not be merged until the ABI
> changes actually made it at least into kvm.git. Same applies, of course,
> to the functional changes related to that ABI. Otherwise we risk quite
> some mess on everyone's side.
> 
> Another thing: KVM_CAP_PPC_HIOR has been removed again from the kernel
> and also the header. Is there real free space now or will the cap
> reappear? If there should better be a placeholder, let's add it (to the
> kernel).
> 
> Jan
> 

Just to underline this, not for merge (yet).

Is it clear that those PPC features will be merged upstream as-is now?

Jan

---8<---

This synchronizes our headers with kvm.git ff92e9b557 - and breaks PPC
build. Fairly telling...

---
 linux-headers/asm-powerpc/kvm.h   |   37 -------------------------
 linux-headers/asm-x86/hyperv.h    |    1 +
 linux-headers/linux/kvm.h         |   54 ++----------------------------------
 linux-headers/linux/kvm_para.h    |    1 -
 linux-headers/linux/virtio_ring.h |    6 ++--
 5 files changed, 7 insertions(+), 92 deletions(-)

diff --git a/linux-headers/asm-powerpc/kvm.h b/linux-headers/asm-powerpc/kvm.h
index fb3fddc..f7727d9 100644
--- a/linux-headers/asm-powerpc/kvm.h
+++ b/linux-headers/asm-powerpc/kvm.h
@@ -292,41 +292,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..e36ad9a 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;
@@ -554,10 +555,9 @@ struct kvm_ppc_pvinfo {
 #define KVM_CAP_PPC_SMT 64
 #define KVM_CAP_PPC_RMA	65
 #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
+#define KVM_CAP_TSC_DEADLINE_TIMER 72
 
 #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/kvm_para.h b/linux-headers/linux/kvm_para.h
index b315e27..7bdcf93 100644
--- a/linux-headers/linux/kvm_para.h
+++ b/linux-headers/linux/kvm_para.h
@@ -26,4 +26,3 @@
 #include <asm/kvm_para.h>
 
 #endif /* __LINUX_KVM_PARA_H */
-
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;
 }
-- 
1.7.3.4

Re: [Qemu-devel] State of KVM bits in linux-headers

[Anthony Liguori]

On 01/11/2012 01:32 PM, Alexander Graf wrote:
>
> On 11.01.2012, at 20:16, Jan Kiszka wrote:
>
>> Hi,
>>
>> I'm a bit unhappy about the current state of our supposed to be
>> automatically sync'ed linux-headers directory in qemu. It has been
>> updated several times against undefined kernel trees, means against
>> neither a released version nor kvm.git. Now, if I run an update against
>> kvm.git + some local change, I get a churn of removals. Same will happen
>> when that local change ever goes upstream before the other stuff got
>> finally committed.
>
> Yes, call me even more unhappy about it :(.

May I suggest the following:

1) Have the header syncing script take a commit hash that's stored in git.  Make 
script ensure that this has is in Linus' tree.

2) Maintain a patch on top of Linus' tree in qemu.git that the script would 
apply before actually syncing header files.

That let's us track how we're differing from upstream in a more reliable fashion.

>> Alex, it looks to me like this is mostly PPC stuff. Can you comment on
>> the origin and workflow? E.g. KVM_CAP_SW_TLB: This has been added half a
>> year ago but is not in any Linux release around. Fishy...
>
> Ok, here's my workflow:
>
>    * KVM: receive patches on the ML
>    * KVM: wait for reviews, review myself
>    * KVM: send out a pull request
>    -- this is the point in time where I assume the ABI can be considered stable --
>    * QEMU: run update on the headers, because in a perfect world things should hit kvm.git any day
>    * KVM: pull request gets reviews causing not-pulls or abi changes and lots of churn because i need forever to pullreq again ;)
>
> I guess you see the problem. Hence I haven't pushed any kernel header updates since I realized how badly broken that process was. However even the stuff that's in qemu.git now hasn't managed to get upstream yet.

I don't think it's a broken process.  I think you made a reasonable set of 
assumptions.  I think it was just an exceptional circumstance.

Regards,

Anthony Liguori

Re: State of KVM bits in linux-headers

[Jan Kiszka]

On 2012-01-11 20:32, Alexander Graf wrote:
> 
> On 11.01.2012, at 20:16, Jan Kiszka wrote:
> 
>> Hi,
>>
>> I'm a bit unhappy about the current state of our supposed to be
>> automatically sync'ed linux-headers directory in qemu. It has been
>> updated several times against undefined kernel trees, means against
>> neither a released version nor kvm.git. Now, if I run an update against
>> kvm.git + some local change, I get a churn of removals. Same will happen
>> when that local change ever goes upstream before the other stuff got
>> finally committed.
> 
> Yes, call me even more unhappy about it :(.
> 
>> Alex, it looks to me like this is mostly PPC stuff. Can you comment on
>> the origin and workflow? E.g. KVM_CAP_SW_TLB: This has been added half a
>> year ago but is not in any Linux release around. Fishy...
> 
> Ok, here's my workflow:
> 
>   * KVM: receive patches on the ML
>   * KVM: wait for reviews, review myself
>   * KVM: send out a pull request
>   -- this is the point in time where I assume the ABI can be considered stable --
>   * QEMU: run update on the headers, because in a perfect world things should hit kvm.git any day
>   * KVM: pull request gets reviews causing not-pulls or abi changes and lots of churn because i need forever to pullreq again ;)

Likely, the last item has to be moved up by two steps...

> 
> I guess you see the problem. Hence I haven't pushed any kernel header updates since I realized how badly broken that process was. However even the stuff that's in qemu.git now hasn't managed to get upstream yet.

On the other hand, if I recall correctly, there were some complaint on
the list recently about a header update patch again a Linux -rc version.
Because it removed the limbo land stuff in the same run, of course.
That's very bad. I see the problem: ppc targets will no longer build, at
least with KVM enabled, right? But this needs to be resolved now.

> 
>> I would like to see us avoiding this in the future. Headers update
>> patches should mention the source and should not be merged until the ABI
>> changes actually made it at least into kvm.git. Same applies, of course,
>> to the functional changes related to that ABI. Otherwise we risk quite
>> some mess on everyone's side.
> 
> I agree.
> 
>> Another thing: KVM_CAP_PPC_HIOR has been removed again from the kernel
>> and also the header. Is there real free space now or will the cap
>> reappear? If there should better be a placeholder, let's add it (to the
>> kernel).
> 
> I will reappear with ONE_REG semantics.
> 

OK.

Then please clean up now so that update-linux-headers.sh can be used
again by "normal" developers. :)

Jan

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

Re: [Qemu-devel] State of KVM bits in linux-headers

[Jan Kiszka]

On 2012-01-11 20:32, Alexander Graf wrote:
> 
> On 11.01.2012, at 20:16, Jan Kiszka wrote:
> 
>> Hi,
>>
>> I'm a bit unhappy about the current state of our supposed to be
>> automatically sync'ed linux-headers directory in qemu. It has been
>> updated several times against undefined kernel trees, means against
>> neither a released version nor kvm.git. Now, if I run an update against
>> kvm.git + some local change, I get a churn of removals. Same will happen
>> when that local change ever goes upstream before the other stuff got
>> finally committed.
> 
> Yes, call me even more unhappy about it :(.
> 
>> Alex, it looks to me like this is mostly PPC stuff. Can you comment on
>> the origin and workflow? E.g. KVM_CAP_SW_TLB: This has been added half a
>> year ago but is not in any Linux release around. Fishy...
> 
> Ok, here's my workflow:
> 
>   * KVM: receive patches on the ML
>   * KVM: wait for reviews, review myself
>   * KVM: send out a pull request
>   -- this is the point in time where I assume the ABI can be considered stable --
>   * QEMU: run update on the headers, because in a perfect world things should hit kvm.git any day
>   * KVM: pull request gets reviews causing not-pulls or abi changes and lots of churn because i need forever to pullreq again ;)

Likely, the last item has to be moved up by two steps...

> 
> I guess you see the problem. Hence I haven't pushed any kernel header updates since I realized how badly broken that process was. However even the stuff that's in qemu.git now hasn't managed to get upstream yet.

On the other hand, if I recall correctly, there were some complaint on
the list recently about a header update patch again a Linux -rc version.
Because it removed the limbo land stuff in the same run, of course.
That's very bad. I see the problem: ppc targets will no longer build, at
least with KVM enabled, right? But this needs to be resolved now.

> 
>> I would like to see us avoiding this in the future. Headers update
>> patches should mention the source and should not be merged until the ABI
>> changes actually made it at least into kvm.git. Same applies, of course,
>> to the functional changes related to that ABI. Otherwise we risk quite
>> some mess on everyone's side.
> 
> I agree.
> 
>> Another thing: KVM_CAP_PPC_HIOR has been removed again from the kernel
>> and also the header. Is there real free space now or will the cap
>> reappear? If there should better be a placeholder, let's add it (to the
>> kernel).
> 
> I will reappear with ONE_REG semantics.
> 

OK.

Then please clean up now so that update-linux-headers.sh can be used
again by "normal" developers. :)

Jan

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

Re: [Qemu-devel] State of KVM bits in linux-headers

[Anthony Liguori]

On 01/11/2012 01:38 PM, Jan Kiszka wrote:
>>
>>> I would like to see us avoiding this in the future. Headers update
>>> patches should mention the source and should not be merged until the ABI
>>> changes actually made it at least into kvm.git. Same applies, of course,
>>> to the functional changes related to that ABI. Otherwise we risk quite
>>> some mess on everyone's side.
>>
>> I agree.
>>
>>> Another thing: KVM_CAP_PPC_HIOR has been removed again from the kernel
>>> and also the header. Is there real free space now or will the cap
>>> reappear? If there should better be a placeholder, let's add it (to the
>>> kernel).
>>
>> I will reappear with ONE_REG semantics.
>>
>
> OK.
>
> Then please clean up now so that update-linux-headers.sh can be used
> again by "normal" developers. :)

Before we did submodules and had a responsive BIOS maintainer, we maintained 
patches within qemu.git for our external dependencies.  I think that's a good 
strategy here too.  It's a little painful, but not entirely awful.

At least it makes it possible for you to (hopefully) trivial rebase a patch if 
something is still in limbo.

Regards,

Anthony Liguori

>
> Jan
>

Re: [Qemu-devel] State of KVM bits in linux-headers

[Anthony Liguori]

On 01/11/2012 01:38 PM, Jan Kiszka wrote:
>>
>>> I would like to see us avoiding this in the future. Headers update
>>> patches should mention the source and should not be merged until the ABI
>>> changes actually made it at least into kvm.git. Same applies, of course,
>>> to the functional changes related to that ABI. Otherwise we risk quite
>>> some mess on everyone's side.
>>
>> I agree.
>>
>>> Another thing: KVM_CAP_PPC_HIOR has been removed again from the kernel
>>> and also the header. Is there real free space now or will the cap
>>> reappear? If there should better be a placeholder, let's add it (to the
>>> kernel).
>>
>> I will reappear with ONE_REG semantics.
>>
>
> OK.
>
> Then please clean up now so that update-linux-headers.sh can be used
> again by "normal" developers. :)

Before we did submodules and had a responsive BIOS maintainer, we maintained 
patches within qemu.git for our external dependencies.  I think that's a good 
strategy here too.  It's a little painful, but not entirely awful.

At least it makes it possible for you to (hopefully) trivial rebase a patch if 
something is still in limbo.

Regards,

Anthony Liguori

>
> Jan
>

Re: [Qemu-devel] State of KVM bits in linux-headers

[Alexander Graf]

On 11.01.2012, at 20:38, Anthony Liguori wrote:

> On 01/11/2012 01:32 PM, Alexander Graf wrote:
>> 
>> On 11.01.2012, at 20:16, Jan Kiszka wrote:
>> 
>>> Hi,
>>> 
>>> I'm a bit unhappy about the current state of our supposed to be
>>> automatically sync'ed linux-headers directory in qemu. It has been
>>> updated several times against undefined kernel trees, means against
>>> neither a released version nor kvm.git. Now, if I run an update against
>>> kvm.git + some local change, I get a churn of removals. Same will happen
>>> when that local change ever goes upstream before the other stuff got
>>> finally committed.
>> 
>> Yes, call me even more unhappy about it :(.
> 
> May I suggest the following:
> 
> 1) Have the header syncing script take a commit hash that's stored in git.  Make script ensure that this has is in Linus' tree.
> 
> 2) Maintain a patch on top of Linus' tree in qemu.git that the script would apply before actually syncing header files.
> 
> That let's us track how we're differing from upstream in a more reliable fashion.

Yeah, I guess the ultimate question it boils down to is: when is something upstream? The average time it takes for patches to trickle through to Linus right now is in the magnitude of half a year to a year.

> 
>>> Alex, it looks to me like this is mostly PPC stuff. Can you comment on
>>> the origin and workflow? E.g. KVM_CAP_SW_TLB: This has been added half a
>>> year ago but is not in any Linux release around. Fishy...
>> 
>> Ok, here's my workflow:
>> 
>>   * KVM: receive patches on the ML
>>   * KVM: wait for reviews, review myself
>>   * KVM: send out a pull request
>>   -- this is the point in time where I assume the ABI can be considered stable --
>>   * QEMU: run update on the headers, because in a perfect world things should hit kvm.git any day
>>   * KVM: pull request gets reviews causing not-pulls or abi changes and lots of churn because i need forever to pullreq again ;)
>> 
>> I guess you see the problem. Hence I haven't pushed any kernel header updates since I realized how badly broken that process was. However even the stuff that's in qemu.git now hasn't managed to get upstream yet.
> 
> I don't think it's a broken process.  I think you made a reasonable set of assumptions.  I think it was just an exceptional circumstance.

Several times in a row? No, the assumptions were just wrong. In the kvm world, pull requests don't mean upstream, they mean the same as a patch set.


Alex

Re: [Qemu-devel] State of KVM bits in linux-headers

[Alexander Graf]

On 11.01.2012, at 20:41, Anthony Liguori wrote:

> On 01/11/2012 01:38 PM, Jan Kiszka wrote:
>>> 
>>>> I would like to see us avoiding this in the future. Headers update
>>>> patches should mention the source and should not be merged until the ABI
>>>> changes actually made it at least into kvm.git. Same applies, of course,
>>>> to the functional changes related to that ABI. Otherwise we risk quite
>>>> some mess on everyone's side.
>>> 
>>> I agree.
>>> 
>>>> Another thing: KVM_CAP_PPC_HIOR has been removed again from the kernel
>>>> and also the header. Is there real free space now or will the cap
>>>> reappear? If there should better be a placeholder, let's add it (to the
>>>> kernel).
>>> 
>>> I will reappear with ONE_REG semantics.
>>> 
>> 
>> OK.
>> 
>> Then please clean up now so that update-linux-headers.sh can be used
>> again by "normal" developers. :)
> 
> Before we did submodules and had a responsive BIOS maintainer, we maintained patches within qemu.git for our external dependencies.  I think that's a good strategy here too.  It's a little painful, but not entirely awful.
> 
> At least it makes it possible for you to (hopefully) trivial rebase a patch if something is still in limbo.

Yeah, that works. I can easily script that part. It doesn't solve the actual underlying problem though that we don't know when the abi is actually stable. I'm slowly starting to understand Pekka ;).


Alex

Re: [Qemu-devel] State of KVM bits in linux-headers

[Jan Kiszka]

On 2012-01-11 20:38, Anthony Liguori wrote:
> On 01/11/2012 01:32 PM, Alexander Graf wrote:
>>
>> On 11.01.2012, at 20:16, Jan Kiszka wrote:
>>
>>> Hi,
>>>
>>> I'm a bit unhappy about the current state of our supposed to be
>>> automatically sync'ed linux-headers directory in qemu. It has been
>>> updated several times against undefined kernel trees, means against
>>> neither a released version nor kvm.git. Now, if I run an update against
>>> kvm.git + some local change, I get a churn of removals. Same will happen
>>> when that local change ever goes upstream before the other stuff got
>>> finally committed.
>>
>> Yes, call me even more unhappy about it :(.
> 
> May I suggest the following:
> 
> 1) Have the header syncing script take a commit hash that's stored in git.  Make 
> script ensure that this has is in Linus' tree.
> 
> 2) Maintain a patch on top of Linus' tree in qemu.git that the script would 
> apply before actually syncing header files.
> 
> That let's us track how we're differing from upstream in a more reliable fashion.

That sounds fairly complicated for a simple problem: Do not merge ABI
changes that aren't at least in kvm.git. There are also other reasons
for this, beside making the sync harder.

Jan

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

Re: [Qemu-devel] State of KVM bits in linux-headers

[Jan Kiszka]

On 2012-01-11 20:38, Anthony Liguori wrote:
> On 01/11/2012 01:32 PM, Alexander Graf wrote:
>>
>> On 11.01.2012, at 20:16, Jan Kiszka wrote:
>>
>>> Hi,
>>>
>>> I'm a bit unhappy about the current state of our supposed to be
>>> automatically sync'ed linux-headers directory in qemu. It has been
>>> updated several times against undefined kernel trees, means against
>>> neither a released version nor kvm.git. Now, if I run an update against
>>> kvm.git + some local change, I get a churn of removals. Same will happen
>>> when that local change ever goes upstream before the other stuff got
>>> finally committed.
>>
>> Yes, call me even more unhappy about it :(.
> 
> May I suggest the following:
> 
> 1) Have the header syncing script take a commit hash that's stored in git.  Make 
> script ensure that this has is in Linus' tree.
> 
> 2) Maintain a patch on top of Linus' tree in qemu.git that the script would 
> apply before actually syncing header files.
> 
> That let's us track how we're differing from upstream in a more reliable fashion.

That sounds fairly complicated for a simple problem: Do not merge ABI
changes that aren't at least in kvm.git. There are also other reasons
for this, beside making the sync harder.

Jan

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

Re: [Qemu-devel] State of KVM bits in linux-headers

[Alexander Graf]

On 11.01.2012, at 20:46, Jan Kiszka wrote:

> On 2012-01-11 20:38, Anthony Liguori wrote:
>> On 01/11/2012 01:32 PM, Alexander Graf wrote:
>>> 
>>> On 11.01.2012, at 20:16, Jan Kiszka wrote:
>>> 
>>>> Hi,
>>>> 
>>>> I'm a bit unhappy about the current state of our supposed to be
>>>> automatically sync'ed linux-headers directory in qemu. It has been
>>>> updated several times against undefined kernel trees, means against
>>>> neither a released version nor kvm.git. Now, if I run an update against
>>>> kvm.git + some local change, I get a churn of removals. Same will happen
>>>> when that local change ever goes upstream before the other stuff got
>>>> finally committed.
>>> 
>>> Yes, call me even more unhappy about it :(.
>> 
>> May I suggest the following:
>> 
>> 1) Have the header syncing script take a commit hash that's stored in git.  Make 
>> script ensure that this has is in Linus' tree.
>> 
>> 2) Maintain a patch on top of Linus' tree in qemu.git that the script would 
>> apply before actually syncing header files.
>> 
>> That let's us track how we're differing from upstream in a more reliable fashion.
> 
> That sounds fairly complicated for a simple problem: Do not merge ABI
> changes that aren't at least in kvm.git. There are also other reasons
> for this, beside making the sync harder.

Let's just try to get my patch queue into kvm.git asap and then never to push linux-header updates before they hit kvm.git again. That's easier than setting up any complicated processes or scripts.


Alex

Re: [Qemu-devel] State of KVM bits in linux-headers

[Alexander Graf]

On 11.01.2012, at 20:46, Jan Kiszka wrote:

> On 2012-01-11 20:38, Anthony Liguori wrote:
>> On 01/11/2012 01:32 PM, Alexander Graf wrote:
>>> 
>>> On 11.01.2012, at 20:16, Jan Kiszka wrote:
>>> 
>>>> Hi,
>>>> 
>>>> I'm a bit unhappy about the current state of our supposed to be
>>>> automatically sync'ed linux-headers directory in qemu. It has been
>>>> updated several times against undefined kernel trees, means against
>>>> neither a released version nor kvm.git. Now, if I run an update against
>>>> kvm.git + some local change, I get a churn of removals. Same will happen
>>>> when that local change ever goes upstream before the other stuff got
>>>> finally committed.
>>> 
>>> Yes, call me even more unhappy about it :(.
>> 
>> May I suggest the following:
>> 
>> 1) Have the header syncing script take a commit hash that's stored in git.  Make 
>> script ensure that this has is in Linus' tree.
>> 
>> 2) Maintain a patch on top of Linus' tree in qemu.git that the script would 
>> apply before actually syncing header files.
>> 
>> That let's us track how we're differing from upstream in a more reliable fashion.
> 
> That sounds fairly complicated for a simple problem: Do not merge ABI
> changes that aren't at least in kvm.git. There are also other reasons
> for this, beside making the sync harder.

Let's just try to get my patch queue into kvm.git asap and then never to push linux-header updates before they hit kvm.git again. That's easier than setting up any complicated processes or scripts.


Alex

Re: [Qemu-devel] State of KVM bits in linux-headers

[Jan Kiszka]

On 2012-01-11 20:46, Alexander Graf wrote:
> 
> On 11.01.2012, at 20:41, Anthony Liguori wrote:
> 
>> On 01/11/2012 01:38 PM, Jan Kiszka wrote:
>>>>
>>>>> I would like to see us avoiding this in the future. Headers update
>>>>> patches should mention the source and should not be merged until the ABI
>>>>> changes actually made it at least into kvm.git. Same applies, of course,
>>>>> to the functional changes related to that ABI. Otherwise we risk quite
>>>>> some mess on everyone's side.
>>>>
>>>> I agree.
>>>>
>>>>> Another thing: KVM_CAP_PPC_HIOR has been removed again from the kernel
>>>>> and also the header. Is there real free space now or will the cap
>>>>> reappear? If there should better be a placeholder, let's add it (to the
>>>>> kernel).
>>>>
>>>> I will reappear with ONE_REG semantics.
>>>>
>>>
>>> OK.
>>>
>>> Then please clean up now so that update-linux-headers.sh can be used
>>> again by "normal" developers. :)
>>
>> Before we did submodules and had a responsive BIOS maintainer, we maintained patches within qemu.git for our external dependencies.  I think that's a good strategy here too.  It's a little painful, but not entirely awful.
>>
>> At least it makes it possible for you to (hopefully) trivial rebase a patch if something is still in limbo.
> 
> Yeah, that works. I can easily script that part. It doesn't solve the actual underlying problem though that we don't know when the abi is actually stable. I'm slowly starting to understand Pekka ;).

IIRC, we never had this problem with qemu-kvm - as the merges were
coordinated with the kernel (subsystem) tree.

Jan

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

Re: [Qemu-devel] State of KVM bits in linux-headers

[Jan Kiszka]

On 2012-01-11 20:46, Alexander Graf wrote:
> 
> On 11.01.2012, at 20:41, Anthony Liguori wrote:
> 
>> On 01/11/2012 01:38 PM, Jan Kiszka wrote:
>>>>
>>>>> I would like to see us avoiding this in the future. Headers update
>>>>> patches should mention the source and should not be merged until the ABI
>>>>> changes actually made it at least into kvm.git. Same applies, of course,
>>>>> to the functional changes related to that ABI. Otherwise we risk quite
>>>>> some mess on everyone's side.
>>>>
>>>> I agree.
>>>>
>>>>> Another thing: KVM_CAP_PPC_HIOR has been removed again from the kernel
>>>>> and also the header. Is there real free space now or will the cap
>>>>> reappear? If there should better be a placeholder, let's add it (to the
>>>>> kernel).
>>>>
>>>> I will reappear with ONE_REG semantics.
>>>>
>>>
>>> OK.
>>>
>>> Then please clean up now so that update-linux-headers.sh can be used
>>> again by "normal" developers. :)
>>
>> Before we did submodules and had a responsive BIOS maintainer, we maintained patches within qemu.git for our external dependencies.  I think that's a good strategy here too.  It's a little painful, but not entirely awful.
>>
>> At least it makes it possible for you to (hopefully) trivial rebase a patch if something is still in limbo.
> 
> Yeah, that works. I can easily script that part. It doesn't solve the actual underlying problem though that we don't know when the abi is actually stable. I'm slowly starting to understand Pekka ;).

IIRC, we never had this problem with qemu-kvm - as the merges were
coordinated with the kernel (subsystem) tree.

Jan

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

Re: [Qemu-devel] State of KVM bits in linux-headers

[Anthony Liguori]

On 01/11/2012 01:48 PM, Jan Kiszka wrote:
> On 2012-01-11 20:46, Alexander Graf wrote:
>>
>> On 11.01.2012, at 20:41, Anthony Liguori wrote:
>>
>>> On 01/11/2012 01:38 PM, Jan Kiszka wrote:
>>>>>
>>>>>> I would like to see us avoiding this in the future. Headers update
>>>>>> patches should mention the source and should not be merged until the ABI
>>>>>> changes actually made it at least into kvm.git. Same applies, of course,
>>>>>> to the functional changes related to that ABI. Otherwise we risk quite
>>>>>> some mess on everyone's side.
>>>>>
>>>>> I agree.
>>>>>
>>>>>> Another thing: KVM_CAP_PPC_HIOR has been removed again from the kernel
>>>>>> and also the header. Is there real free space now or will the cap
>>>>>> reappear? If there should better be a placeholder, let's add it (to the
>>>>>> kernel).
>>>>>
>>>>> I will reappear with ONE_REG semantics.
>>>>>
>>>>
>>>> OK.
>>>>
>>>> Then please clean up now so that update-linux-headers.sh can be used
>>>> again by "normal" developers. :)
>>>
>>> Before we did submodules and had a responsive BIOS maintainer, we maintained patches within qemu.git for our external dependencies.  I think that's a good strategy here too.  It's a little painful, but not entirely awful.
>>>
>>> At least it makes it possible for you to (hopefully) trivial rebase a patch if something is still in limbo.
>>
>> Yeah, that works. I can easily script that part. It doesn't solve the actual underlying problem though that we don't know when the abi is actually stable. I'm slowly starting to understand Pekka ;).
>
> IIRC, we never had this problem with qemu-kvm - as the merges were
> coordinated with the kernel (subsystem) tree.

Are you suggesting that kvm header updates go through uq/master?  That seems 
reasonable to me and is certainly the least amount of change.

Regards,

Anthony Liguori

>
> Jan
>

Re: [Qemu-devel] State of KVM bits in linux-headers

[Anthony Liguori]

On 01/11/2012 01:48 PM, Jan Kiszka wrote:
> On 2012-01-11 20:46, Alexander Graf wrote:
>>
>> On 11.01.2012, at 20:41, Anthony Liguori wrote:
>>
>>> On 01/11/2012 01:38 PM, Jan Kiszka wrote:
>>>>>
>>>>>> I would like to see us avoiding this in the future. Headers update
>>>>>> patches should mention the source and should not be merged until the ABI
>>>>>> changes actually made it at least into kvm.git. Same applies, of course,
>>>>>> to the functional changes related to that ABI. Otherwise we risk quite
>>>>>> some mess on everyone's side.
>>>>>
>>>>> I agree.
>>>>>
>>>>>> Another thing: KVM_CAP_PPC_HIOR has been removed again from the kernel
>>>>>> and also the header. Is there real free space now or will the cap
>>>>>> reappear? If there should better be a placeholder, let's add it (to the
>>>>>> kernel).
>>>>>
>>>>> I will reappear with ONE_REG semantics.
>>>>>
>>>>
>>>> OK.
>>>>
>>>> Then please clean up now so that update-linux-headers.sh can be used
>>>> again by "normal" developers. :)
>>>
>>> Before we did submodules and had a responsive BIOS maintainer, we maintained patches within qemu.git for our external dependencies.  I think that's a good strategy here too.  It's a little painful, but not entirely awful.
>>>
>>> At least it makes it possible for you to (hopefully) trivial rebase a patch if something is still in limbo.
>>
>> Yeah, that works. I can easily script that part. It doesn't solve the actual underlying problem though that we don't know when the abi is actually stable. I'm slowly starting to understand Pekka ;).
>
> IIRC, we never had this problem with qemu-kvm - as the merges were
> coordinated with the kernel (subsystem) tree.

Are you suggesting that kvm header updates go through uq/master?  That seems 
reasonable to me and is certainly the least amount of change.

Regards,

Anthony Liguori

>
> Jan
>

Re: [Qemu-devel] State of KVM bits in linux-headers

[Alexander Graf]

On 11.01.2012, at 20:52, Anthony Liguori wrote:

> On 01/11/2012 01:48 PM, Jan Kiszka wrote:
>> On 2012-01-11 20:46, Alexander Graf wrote:
>>> 
>>> On 11.01.2012, at 20:41, Anthony Liguori wrote:
>>> 
>>>> On 01/11/2012 01:38 PM, Jan Kiszka wrote:
>>>>>> 
>>>>>>> I would like to see us avoiding this in the future. Headers update
>>>>>>> patches should mention the source and should not be merged until the ABI
>>>>>>> changes actually made it at least into kvm.git. Same applies, of course,
>>>>>>> to the functional changes related to that ABI. Otherwise we risk quite
>>>>>>> some mess on everyone's side.
>>>>>> 
>>>>>> I agree.
>>>>>> 
>>>>>>> Another thing: KVM_CAP_PPC_HIOR has been removed again from the kernel
>>>>>>> and also the header. Is there real free space now or will the cap
>>>>>>> reappear? If there should better be a placeholder, let's add it (to the
>>>>>>> kernel).
>>>>>> 
>>>>>> I will reappear with ONE_REG semantics.
>>>>>> 
>>>>> 
>>>>> OK.
>>>>> 
>>>>> Then please clean up now so that update-linux-headers.sh can be used
>>>>> again by "normal" developers. :)
>>>> 
>>>> Before we did submodules and had a responsive BIOS maintainer, we maintained patches within qemu.git for our external dependencies.  I think that's a good strategy here too.  It's a little painful, but not entirely awful.
>>>> 
>>>> At least it makes it possible for you to (hopefully) trivial rebase a patch if something is still in limbo.
>>> 
>>> Yeah, that works. I can easily script that part. It doesn't solve the actual underlying problem though that we don't know when the abi is actually stable. I'm slowly starting to understand Pekka ;).
>> 
>> IIRC, we never had this problem with qemu-kvm - as the merges were
>> coordinated with the kernel (subsystem) tree.
> 
> Are you suggesting that kvm header updates go through uq/master?  That seems reasonable to me and is certainly the least amount of change.

So how about code that actually leverages the new headers?


Alex

Re: [Qemu-devel] State of KVM bits in linux-headers

[Alexander Graf]

On 11.01.2012, at 20:52, Anthony Liguori wrote:

> On 01/11/2012 01:48 PM, Jan Kiszka wrote:
>> On 2012-01-11 20:46, Alexander Graf wrote:
>>> 
>>> On 11.01.2012, at 20:41, Anthony Liguori wrote:
>>> 
>>>> On 01/11/2012 01:38 PM, Jan Kiszka wrote:
>>>>>> 
>>>>>>> I would like to see us avoiding this in the future. Headers update
>>>>>>> patches should mention the source and should not be merged until the ABI
>>>>>>> changes actually made it at least into kvm.git. Same applies, of course,
>>>>>>> to the functional changes related to that ABI. Otherwise we risk quite
>>>>>>> some mess on everyone's side.
>>>>>> 
>>>>>> I agree.
>>>>>> 
>>>>>>> Another thing: KVM_CAP_PPC_HIOR has been removed again from the kernel
>>>>>>> and also the header. Is there real free space now or will the cap
>>>>>>> reappear? If there should better be a placeholder, let's add it (to the
>>>>>>> kernel).
>>>>>> 
>>>>>> I will reappear with ONE_REG semantics.
>>>>>> 
>>>>> 
>>>>> OK.
>>>>> 
>>>>> Then please clean up now so that update-linux-headers.sh can be used
>>>>> again by "normal" developers. :)
>>>> 
>>>> Before we did submodules and had a responsive BIOS maintainer, we maintained patches within qemu.git for our external dependencies.  I think that's a good strategy here too.  It's a little painful, but not entirely awful.
>>>> 
>>>> At least it makes it possible for you to (hopefully) trivial rebase a patch if something is still in limbo.
>>> 
>>> Yeah, that works. I can easily script that part. It doesn't solve the actual underlying problem though that we don't know when the abi is actually stable. I'm slowly starting to understand Pekka ;).
>> 
>> IIRC, we never had this problem with qemu-kvm - as the merges were
>> coordinated with the kernel (subsystem) tree.
> 
> Are you suggesting that kvm header updates go through uq/master?  That seems reasonable to me and is certainly the least amount of change.

So how about code that actually leverages the new headers?


Alex

Re: [Qemu-devel] State of KVM bits in linux-headers

[Jan Kiszka]

On 2012-01-11 20:52, Anthony Liguori wrote:
> On 01/11/2012 01:48 PM, Jan Kiszka wrote:
>> On 2012-01-11 20:46, Alexander Graf wrote:
>>>
>>> On 11.01.2012, at 20:41, Anthony Liguori wrote:
>>>
>>>> On 01/11/2012 01:38 PM, Jan Kiszka wrote:
>>>>>>
>>>>>>> I would like to see us avoiding this in the future. Headers update
>>>>>>> patches should mention the source and should not be merged until the ABI
>>>>>>> changes actually made it at least into kvm.git. Same applies, of course,
>>>>>>> to the functional changes related to that ABI. Otherwise we risk quite
>>>>>>> some mess on everyone's side.
>>>>>>
>>>>>> I agree.
>>>>>>
>>>>>>> Another thing: KVM_CAP_PPC_HIOR has been removed again from the kernel
>>>>>>> and also the header. Is there real free space now or will the cap
>>>>>>> reappear? If there should better be a placeholder, let's add it (to the
>>>>>>> kernel).
>>>>>>
>>>>>> I will reappear with ONE_REG semantics.
>>>>>>
>>>>>
>>>>> OK.
>>>>>
>>>>> Then please clean up now so that update-linux-headers.sh can be used
>>>>> again by "normal" developers. :)
>>>>
>>>> Before we did submodules and had a responsive BIOS maintainer, we maintained patches within qemu.git for our external dependencies.  I think that's a good strategy here too.  It's a little painful, but not entirely awful.
>>>>
>>>> At least it makes it possible for you to (hopefully) trivial rebase a patch if something is still in limbo.
>>>
>>> Yeah, that works. I can easily script that part. It doesn't solve the actual underlying problem though that we don't know when the abi is actually stable. I'm slowly starting to understand Pekka ;).
>>
>> IIRC, we never had this problem with qemu-kvm - as the merges were
>> coordinated with the kernel (subsystem) tree.
> 
> Are you suggesting that kvm header updates go through uq/master?  That seems 
> reasonable to me and is certainly the least amount of change.

Would be possible at least for changes that affect KVM bits. But we also
use that headers for virtio and vhost. VFIO will surely join that group.
So there is still coordination necessary.

Jan

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

Re: [Qemu-devel] State of KVM bits in linux-headers

[Jan Kiszka]

On 2012-01-11 20:52, Anthony Liguori wrote:
> On 01/11/2012 01:48 PM, Jan Kiszka wrote:
>> On 2012-01-11 20:46, Alexander Graf wrote:
>>>
>>> On 11.01.2012, at 20:41, Anthony Liguori wrote:
>>>
>>>> On 01/11/2012 01:38 PM, Jan Kiszka wrote:
>>>>>>
>>>>>>> I would like to see us avoiding this in the future. Headers update
>>>>>>> patches should mention the source and should not be merged until the ABI
>>>>>>> changes actually made it at least into kvm.git. Same applies, of course,
>>>>>>> to the functional changes related to that ABI. Otherwise we risk quite
>>>>>>> some mess on everyone's side.
>>>>>>
>>>>>> I agree.
>>>>>>
>>>>>>> Another thing: KVM_CAP_PPC_HIOR has been removed again from the kernel
>>>>>>> and also the header. Is there real free space now or will the cap
>>>>>>> reappear? If there should better be a placeholder, let's add it (to the
>>>>>>> kernel).
>>>>>>
>>>>>> I will reappear with ONE_REG semantics.
>>>>>>
>>>>>
>>>>> OK.
>>>>>
>>>>> Then please clean up now so that update-linux-headers.sh can be used
>>>>> again by "normal" developers. :)
>>>>
>>>> Before we did submodules and had a responsive BIOS maintainer, we maintained patches within qemu.git for our external dependencies.  I think that's a good strategy here too.  It's a little painful, but not entirely awful.
>>>>
>>>> At least it makes it possible for you to (hopefully) trivial rebase a patch if something is still in limbo.
>>>
>>> Yeah, that works. I can easily script that part. It doesn't solve the actual underlying problem though that we don't know when the abi is actually stable. I'm slowly starting to understand Pekka ;).
>>
>> IIRC, we never had this problem with qemu-kvm - as the merges were
>> coordinated with the kernel (subsystem) tree.
> 
> Are you suggesting that kvm header updates go through uq/master?  That seems 
> reasonable to me and is certainly the least amount of change.

Would be possible at least for changes that affect KVM bits. But we also
use that headers for virtio and vhost. VFIO will surely join that group.
So there is still coordination necessary.

Jan

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

Re: [Qemu-devel] State of KVM bits in linux-headers

[Anthony Liguori]

On 01/11/2012 01:53 PM, Alexander Graf wrote:
>
> On 11.01.2012, at 20:52, Anthony Liguori wrote:
>
>>> IIRC, we never had this problem with qemu-kvm - as the merges were
>>> coordinated with the kernel (subsystem) tree.
>>
>> Are you suggesting that kvm header updates go through uq/master?  That seems reasonable to me and is certainly the least amount of change.
>
> So how about code that actually leverages the new headers?

Shared KVM infrastructure should go through uq/master.  So changes to kvm-all.c, 
linux-headers/* should go through uq/master.

Target specific kvm changes should go through the appropriate submaintainers tree.

Regards,

Anthony Liguori

>
>
> Alex
>
>

Re: [Qemu-devel] State of KVM bits in linux-headers

[Alexander Graf]

On 11.01.2012, at 20:59, Anthony Liguori wrote:

> On 01/11/2012 01:53 PM, Alexander Graf wrote:
>> 
>> On 11.01.2012, at 20:52, Anthony Liguori wrote:
>> 
>>>> IIRC, we never had this problem with qemu-kvm - as the merges were
>>>> coordinated with the kernel (subsystem) tree.
>>> 
>>> Are you suggesting that kvm header updates go through uq/master?  That seems reasonable to me and is certainly the least amount of change.
>> 
>> So how about code that actually leverages the new headers?
> 
> Shared KVM infrastructure should go through uq/master.  So changes to kvm-all.c, linux-headers/* should go through uq/master.
> 
> Target specific kvm changes should go through the appropriate submaintainers tree.

So then if I add some target specific stuff to KVM, I have to

  * send pullreq to KVM
  * wait for that to be applied
  * post a patch to uq/master to update headers
  * wait for that to merge back to qemu.git
  * send a pull request to qemu.git

right? And then after about 3 months we'll have the feature available ;).


Alex

Re: [Qemu-devel] State of KVM bits in linux-headers

[Anthony Liguori]

On 01/11/2012 02:05 PM, Alexander Graf wrote:
>
> On 11.01.2012, at 20:59, Anthony Liguori wrote:
>
>> On 01/11/2012 01:53 PM, Alexander Graf wrote:
>>>
>>> On 11.01.2012, at 20:52, Anthony Liguori wrote:
>>>
>>>>> IIRC, we never had this problem with qemu-kvm - as the merges were
>>>>> coordinated with the kernel (subsystem) tree.
>>>>
>>>> Are you suggesting that kvm header updates go through uq/master?  That seems reasonable to me and is certainly the least amount of change.
>>>
>>> So how about code that actually leverages the new headers?
>>
>> Shared KVM infrastructure should go through uq/master.  So changes to kvm-all.c, linux-headers/* should go through uq/master.
>>
>> Target specific kvm changes should go through the appropriate submaintainers tree.
>
> So then if I add some target specific stuff to KVM,

That requires a header update?

> I have to
>
>    * send pullreq to KVM
>    * wait for that to be applied
>    * post a patch to uq/master to update headers

Strictly from a QEMU perspective, we can't depend on APIs that aren't committed 
upstream yet.

>    * wait for that to merge back to qemu.git
>    * send a pull request to qemu.git

Maybe we need to bring a stripped down version of Linux into qemu.git to make it 
easier to simultaneously update both trees... ;-)

>
> right? And then after about 3 months we'll have the feature available ;).

You can always just get Acked-by's from the appropriate maintainers.  That's 
just as good as going through the tree.

Regards,

Anthony Liguori

>
> Alex
>
>

Re: State of KVM bits in linux-headers

[Alexander Graf]

On 11.01.2012, at 21:16, Anthony Liguori wrote:

> On 01/11/2012 02:05 PM, Alexander Graf wrote:
>> 
>> On 11.01.2012, at 20:59, Anthony Liguori wrote:
>> 
>>> On 01/11/2012 01:53 PM, Alexander Graf wrote:
>>>> 
>>>> On 11.01.2012, at 20:52, Anthony Liguori wrote:
>>>> 
>>>>>> IIRC, we never had this problem with qemu-kvm - as the merges were
>>>>>> coordinated with the kernel (subsystem) tree.
>>>>> 
>>>>> Are you suggesting that kvm header updates go through uq/master?  That seems reasonable to me and is certainly the least amount of change.
>>>> 
>>>> So how about code that actually leverages the new headers?
>>> 
>>> Shared KVM infrastructure should go through uq/master.  So changes to kvm-all.c, linux-headers/* should go through uq/master.
>>> 
>>> Target specific kvm changes should go through the appropriate submaintainers tree.
>> 
>> So then if I add some target specific stuff to KVM,
> 
> That requires a header update?

Almost all of the time, yes. The target is still rather incomplete. And even in places where it is, hardware evolves and we just get new information we need to pass back and forth.

> 
>> I have to
>> 
>>   * send pullreq to KVM
>>   * wait for that to be applied
>>   * post a patch to uq/master to update headers
> 
> Strictly from a QEMU perspective, we can't depend on APIs that aren't committed upstream yet.

The question again is: When do we consider something upstream?

> 
>>   * wait for that to merge back to qemu.git
>>   * send a pull request to qemu.git
> 
> Maybe we need to bring a stripped down version of Linux into qemu.git to make it easier to simultaneously update both trees... ;-)

Nice one ;)

> 
>> 
>> right? And then after about 3 months we'll have the feature available ;).
> 
> You can always just get Acked-by's from the appropriate maintainers.  That's just as good as going through the tree.

So every time we change headers, I just require Avi's ack and then he can't complain on those patches later? Good idea! :)


Alex

Re: [Qemu-devel] State of KVM bits in linux-headers

[Alexander Graf]

On 11.01.2012, at 21:16, Anthony Liguori wrote:

> On 01/11/2012 02:05 PM, Alexander Graf wrote:
>> 
>> On 11.01.2012, at 20:59, Anthony Liguori wrote:
>> 
>>> On 01/11/2012 01:53 PM, Alexander Graf wrote:
>>>> 
>>>> On 11.01.2012, at 20:52, Anthony Liguori wrote:
>>>> 
>>>>>> IIRC, we never had this problem with qemu-kvm - as the merges were
>>>>>> coordinated with the kernel (subsystem) tree.
>>>>> 
>>>>> Are you suggesting that kvm header updates go through uq/master?  That seems reasonable to me and is certainly the least amount of change.
>>>> 
>>>> So how about code that actually leverages the new headers?
>>> 
>>> Shared KVM infrastructure should go through uq/master.  So changes to kvm-all.c, linux-headers/* should go through uq/master.
>>> 
>>> Target specific kvm changes should go through the appropriate submaintainers tree.
>> 
>> So then if I add some target specific stuff to KVM,
> 
> That requires a header update?

Almost all of the time, yes. The target is still rather incomplete. And even in places where it is, hardware evolves and we just get new information we need to pass back and forth.

> 
>> I have to
>> 
>>   * send pullreq to KVM
>>   * wait for that to be applied
>>   * post a patch to uq/master to update headers
> 
> Strictly from a QEMU perspective, we can't depend on APIs that aren't committed upstream yet.

The question again is: When do we consider something upstream?

> 
>>   * wait for that to merge back to qemu.git
>>   * send a pull request to qemu.git
> 
> Maybe we need to bring a stripped down version of Linux into qemu.git to make it easier to simultaneously update both trees... ;-)

Nice one ;)

> 
>> 
>> right? And then after about 3 months we'll have the feature available ;).
> 
> You can always just get Acked-by's from the appropriate maintainers.  That's just as good as going through the tree.

So every time we change headers, I just require Avi's ack and then he can't complain on those patches later? Good idea! :)


Alex

Re: [Qemu-devel] State of KVM bits in linux-headers

[Gleb Natapov]

On Wed, Jan 11, 2012 at 08:46:38PM +0100, Alexander Graf wrote:
> 
> On 11.01.2012, at 20:41, Anthony Liguori wrote:
> 
> > On 01/11/2012 01:38 PM, Jan Kiszka wrote:
> >>> 
> >>>> I would like to see us avoiding this in the future. Headers update
> >>>> patches should mention the source and should not be merged until the ABI
> >>>> changes actually made it at least into kvm.git. Same applies, of course,
> >>>> to the functional changes related to that ABI. Otherwise we risk quite
> >>>> some mess on everyone's side.
> >>> 
> >>> I agree.
> >>> 
> >>>> Another thing: KVM_CAP_PPC_HIOR has been removed again from the kernel
> >>>> and also the header. Is there real free space now or will the cap
> >>>> reappear? If there should better be a placeholder, let's add it (to the
> >>>> kernel).
> >>> 
> >>> I will reappear with ONE_REG semantics.
> >>> 
> >> 
> >> OK.
> >> 
> >> Then please clean up now so that update-linux-headers.sh can be used
> >> again by "normal" developers. :)
> > 
> > Before we did submodules and had a responsive BIOS maintainer, we maintained patches within qemu.git for our external dependencies.  I think that's a good strategy here too.  It's a little painful, but not entirely awful.
> > 
> > At least it makes it possible for you to (hopefully) trivial rebase a patch if something is still in limbo.
> 
> Yeah, that works. I can easily script that part. It doesn't solve the actual underlying problem though that we don't know when the abi is actually stable. I'm slowly starting to understand Pekka ;).
> 
> 
In my recent experience with submitting Joerg's patch series that
touches both kernel and tools/perf I didn't see any advantages in
having them in the same repository. Yes, the repository is the same,
but maintainers are different and have their own timelines and
priorities. Long story short userspace part was applied almost three
month after the kernel part.

--
			Gleb.

Re: [Qemu-devel] State of KVM bits in linux-headers

[Gleb Natapov]

On Wed, Jan 11, 2012 at 08:46:38PM +0100, Alexander Graf wrote:
> 
> On 11.01.2012, at 20:41, Anthony Liguori wrote:
> 
> > On 01/11/2012 01:38 PM, Jan Kiszka wrote:
> >>> 
> >>>> I would like to see us avoiding this in the future. Headers update
> >>>> patches should mention the source and should not be merged until the ABI
> >>>> changes actually made it at least into kvm.git. Same applies, of course,
> >>>> to the functional changes related to that ABI. Otherwise we risk quite
> >>>> some mess on everyone's side.
> >>> 
> >>> I agree.
> >>> 
> >>>> Another thing: KVM_CAP_PPC_HIOR has been removed again from the kernel
> >>>> and also the header. Is there real free space now or will the cap
> >>>> reappear? If there should better be a placeholder, let's add it (to the
> >>>> kernel).
> >>> 
> >>> I will reappear with ONE_REG semantics.
> >>> 
> >> 
> >> OK.
> >> 
> >> Then please clean up now so that update-linux-headers.sh can be used
> >> again by "normal" developers. :)
> > 
> > Before we did submodules and had a responsive BIOS maintainer, we maintained patches within qemu.git for our external dependencies.  I think that's a good strategy here too.  It's a little painful, but not entirely awful.
> > 
> > At least it makes it possible for you to (hopefully) trivial rebase a patch if something is still in limbo.
> 
> Yeah, that works. I can easily script that part. It doesn't solve the actual underlying problem though that we don't know when the abi is actually stable. I'm slowly starting to understand Pekka ;).
> 
> 
In my recent experience with submitting Joerg's patch series that
touches both kernel and tools/perf I didn't see any advantages in
having them in the same repository. Yes, the repository is the same,
but maintainers are different and have their own timelines and
priorities. Long story short userspace part was applied almost three
month after the kernel part.

--
			Gleb.

Re: [Qemu-devel] State of KVM bits in linux-headers

[Avi Kivity]

On 01/11/2012 11:48 PM, Alexander Graf wrote:
> > 
> > Strictly from a QEMU perspective, we can't depend on APIs that aren't committed upstream yet.

We can't release any qemu that depends on something not upstream.

> The question again is: When do we consider something upstream?

This far from a qemu release, we can consider anything in in kvm.git
master (or slightly trailing that, kvm.git linux-next) as upstream. 
It's very rare that an ABI gets pulled out of that and not merged, and
if it is, we can pull out the qemu feature.  An ABI can change, but that
just means we need to echo the change in qemu.

As qemu gets closer to release, we'll need to look at Linus' tree
instead of kvm.git.


> >> 
> >> right? And then after about 3 months we'll have the feature available ;).
> > 
> > You can always just get Acked-by's from the appropriate maintainers.  That's just as good as going through the tree.
>
> So every time we change headers, I just require Avi's ack and then he can't complain on those patches later? Good idea! :)

Of course I can complain about my patches later.

Complained-about-by: Avi Kivity <avi@redhat.com>

But yes, if your change involves multiple subsystem, get it through the
most affected subsystem and get acks from the rest.

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

Re: [Qemu-devel] State of KVM bits in linux-headers

[Avi Kivity]

On 01/11/2012 11:48 PM, Alexander Graf wrote:
> > 
> > Strictly from a QEMU perspective, we can't depend on APIs that aren't committed upstream yet.

We can't release any qemu that depends on something not upstream.

> The question again is: When do we consider something upstream?

This far from a qemu release, we can consider anything in in kvm.git
master (or slightly trailing that, kvm.git linux-next) as upstream. 
It's very rare that an ABI gets pulled out of that and not merged, and
if it is, we can pull out the qemu feature.  An ABI can change, but that
just means we need to echo the change in qemu.

As qemu gets closer to release, we'll need to look at Linus' tree
instead of kvm.git.


> >> 
> >> right? And then after about 3 months we'll have the feature available ;).
> > 
> > You can always just get Acked-by's from the appropriate maintainers.  That's just as good as going through the tree.
>
> So every time we change headers, I just require Avi's ack and then he can't complain on those patches later? Good idea! :)

Of course I can complain about my patches later.

Complained-about-by: Avi Kivity <avi@redhat.com>

But yes, if your change involves multiple subsystem, get it through the
most affected subsystem and get acks from the rest.

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