[Qemu-devel] [PULL 0/4] ppc patches for qemu-2.7 stable branch

[Qemu-devel] [PULL 0/4] ppc patches for qemu-2.7 stable branch

[David Gibson]

The following changes since commit 1dc33ed90bf1fe1c2014dffa0d9e863c520d953a:

  Update version for v2.7.0 release (2016-09-02 13:44:11 +0100)

are available in the git repository at:

  git://github.com/dgibson/qemu.git tags/ppc-for-2.7-20161013

for you to fetch changes up to 2e68f28854f0120c9a938a61b64aaf1eaecb162b:

  ppc: Check the availability of transactional memory (2016-10-13 12:58:06 +1100)

----------------------------------------------------------------
qemu-2.7 (stable): ppc patch queue 2016-10-13

TCG for ppc does not properly implement hardware transactional memory.
It has a stub implementation in which transactions always fail.
Unfortunately in v2.7.0, HTM is advertised as being available to
guests, which means guests may incorrectly attempt to use it and hang.

This has been the case for a while, but has become more urgent with
recent (guest) Linux kernel versions which attempt to lazily enable
TM.  Under TCG that now triggers the problem regularly, instead of
just when running a TM aware userspace program.

The problem is already fixed in the 2.8/master branch, by correctly
advertising HTM as not being available with TCG.  This series
backports the relevant patches to the qemu-2.7 stable branch to fix
the problem there.

----------------------------------------------------------------
Cornelia Huck (1):
      linux-headers: update

Thomas Huth (3):
      hw/ppc/spapr: Move code related to "ibm,pa-features" to a separate function
      hw/ppc/spapr: Fix the selection of the processor features
      ppc: Check the availability of transactional memory

 hw/ppc/spapr.c                                     | 76 ++++++++++-------
 include/standard-headers/linux/input-event-codes.h | 32 ++++++++
 include/standard-headers/linux/input.h             |  1 +
 include/standard-headers/linux/virtio_config.h     | 10 ++-
 include/standard-headers/linux/virtio_ids.h        |  1 +
 include/standard-headers/linux/virtio_net.h        |  3 +
 include/standard-headers/linux/virtio_vsock.h      | 94 ++++++++++++++++++++++
 linux-headers/asm-arm/kvm.h                        |  4 +-
 linux-headers/asm-arm64/kvm.h                      |  2 +
 linux-headers/asm-s390/kvm.h                       | 41 ++++++++++
 linux-headers/asm-x86/unistd_x32.h                 |  4 +-
 linux-headers/linux/kvm.h                          | 18 ++++-
 linux-headers/linux/vhost.h                        | 33 ++++++++
 target-ppc/kvm.c                                   |  7 ++
 target-ppc/kvm_ppc.h                               |  6 ++
 15 files changed, 295 insertions(+), 37 deletions(-)
 create mode 100644 include/standard-headers/linux/virtio_vsock.h

[Qemu-devel] [PULL 1/4] linux-headers: update

[David Gibson]

From: Cornelia Huck <cornelia.huck@de.ibm.com>

Update headers against 4.8-rc2.

Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
---
 include/standard-headers/linux/input-event-codes.h | 32 ++++++++
 include/standard-headers/linux/input.h             |  1 +
 include/standard-headers/linux/virtio_config.h     | 10 ++-
 include/standard-headers/linux/virtio_ids.h        |  1 +
 include/standard-headers/linux/virtio_net.h        |  3 +
 include/standard-headers/linux/virtio_vsock.h      | 94 ++++++++++++++++++++++
 linux-headers/asm-arm/kvm.h                        |  4 +-
 linux-headers/asm-arm64/kvm.h                      |  2 +
 linux-headers/asm-s390/kvm.h                       | 41 ++++++++++
 linux-headers/asm-x86/unistd_x32.h                 |  4 +-
 linux-headers/linux/kvm.h                          | 18 ++++-
 linux-headers/linux/vhost.h                        | 33 ++++++++
 12 files changed, 236 insertions(+), 7 deletions(-)
 create mode 100644 include/standard-headers/linux/virtio_vsock.h

diff --git a/include/standard-headers/linux/input-event-codes.h b/include/standard-headers/linux/input-event-codes.h
index 354f0de..5c10f7e 100644
--- a/include/standard-headers/linux/input-event-codes.h
+++ b/include/standard-headers/linux/input-event-codes.h
@@ -611,6 +611,37 @@
 #define KEY_KBDINPUTASSIST_ACCEPT		0x264
 #define KEY_KBDINPUTASSIST_CANCEL		0x265
 
+/* Diagonal movement keys */
+#define KEY_RIGHT_UP			0x266
+#define KEY_RIGHT_DOWN			0x267
+#define KEY_LEFT_UP			0x268
+#define KEY_LEFT_DOWN			0x269
+
+#define KEY_ROOT_MENU			0x26a /* Show Device's Root Menu */
+/* Show Top Menu of the Media (e.g. DVD) */
+#define KEY_MEDIA_TOP_MENU		0x26b
+#define KEY_NUMERIC_11			0x26c
+#define KEY_NUMERIC_12			0x26d
+/*
+ * Toggle Audio Description: refers to an audio service that helps blind and
+ * visually impaired consumers understand the action in a program. Note: in
+ * some countries this is referred to as "Video Description".
+ */
+#define KEY_AUDIO_DESC			0x26e
+#define KEY_3D_MODE			0x26f
+#define KEY_NEXT_FAVORITE		0x270
+#define KEY_STOP_RECORD			0x271
+#define KEY_PAUSE_RECORD		0x272
+#define KEY_VOD				0x273 /* Video on Demand */
+#define KEY_UNMUTE			0x274
+#define KEY_FASTREVERSE			0x275
+#define KEY_SLOWREVERSE			0x276
+/*
+ * Control a data application associated with the currently viewed channel,
+ * e.g. teletext or data broadcast application (MHEG, MHP, HbbTV, etc.)
+ */
+#define KEY_DATA			0x275
+
 #define BTN_TRIGGER_HAPPY		0x2c0
 #define BTN_TRIGGER_HAPPY1		0x2c0
 #define BTN_TRIGGER_HAPPY2		0x2c1
@@ -749,6 +780,7 @@
 #define SW_ROTATE_LOCK		0x0c  /* set = rotate locked/disabled */
 #define SW_LINEIN_INSERT	0x0d  /* set = inserted */
 #define SW_MUTE_DEVICE		0x0e  /* set = device disabled */
+#define SW_PEN_INSERTED		0x0f  /* set = pen inserted */
 #define SW_MAX_			0x0f
 #define SW_CNT			(SW_MAX_+1)
 
diff --git a/include/standard-headers/linux/input.h b/include/standard-headers/linux/input.h
index a52b202..7361a16 100644
--- a/include/standard-headers/linux/input.h
+++ b/include/standard-headers/linux/input.h
@@ -244,6 +244,7 @@ struct input_mask {
 #define BUS_ATARI		0x1B
 #define BUS_SPI			0x1C
 #define BUS_RMI			0x1D
+#define BUS_CEC			0x1E
 
 /*
  * MT_TOOL types
diff --git a/include/standard-headers/linux/virtio_config.h b/include/standard-headers/linux/virtio_config.h
index b30d0cb..b777069 100644
--- a/include/standard-headers/linux/virtio_config.h
+++ b/include/standard-headers/linux/virtio_config.h
@@ -49,7 +49,7 @@
  * transport being used (eg. virtio_ring), the rest are per-device feature
  * bits. */
 #define VIRTIO_TRANSPORT_F_START	28
-#define VIRTIO_TRANSPORT_F_END		33
+#define VIRTIO_TRANSPORT_F_END		34
 
 #ifndef VIRTIO_CONFIG_NO_LEGACY
 /* Do we get callbacks when the ring is completely used, even if we've
@@ -63,4 +63,12 @@
 /* v1.0 compliant. */
 #define VIRTIO_F_VERSION_1		32
 
+/*
+ * If clear - device has the IOMMU bypass quirk feature.
+ * If set - use platform tools to detect the IOMMU.
+ *
+ * Note the reverse polarity (compared to most other features),
+ * this is for compatibility with legacy systems.
+ */
+#define VIRTIO_F_IOMMU_PLATFORM		33
 #endif /* _LINUX_VIRTIO_CONFIG_H */
diff --git a/include/standard-headers/linux/virtio_ids.h b/include/standard-headers/linux/virtio_ids.h
index 77925f5..3228d58 100644
--- a/include/standard-headers/linux/virtio_ids.h
+++ b/include/standard-headers/linux/virtio_ids.h
@@ -41,5 +41,6 @@
 #define VIRTIO_ID_CAIF	       12 /* Virtio caif */
 #define VIRTIO_ID_GPU          16 /* virtio GPU */
 #define VIRTIO_ID_INPUT        18 /* virtio input */
+#define VIRTIO_ID_VSOCK        19 /* virtio vsock transport */
 
 #endif /* _LINUX_VIRTIO_IDS_H */
diff --git a/include/standard-headers/linux/virtio_net.h b/include/standard-headers/linux/virtio_net.h
index a78f33e..30ff249 100644
--- a/include/standard-headers/linux/virtio_net.h
+++ b/include/standard-headers/linux/virtio_net.h
@@ -35,6 +35,7 @@
 #define VIRTIO_NET_F_CSUM	0	/* Host handles pkts w/ partial csum */
 #define VIRTIO_NET_F_GUEST_CSUM	1	/* Guest handles pkts w/ partial csum */
 #define VIRTIO_NET_F_CTRL_GUEST_OFFLOADS 2 /* Dynamic offload configuration. */
+#define VIRTIO_NET_F_MTU	3	/* Initial MTU advice */
 #define VIRTIO_NET_F_MAC	5	/* Host has given MAC address. */
 #define VIRTIO_NET_F_GUEST_TSO4	7	/* Guest can handle TSOv4 in. */
 #define VIRTIO_NET_F_GUEST_TSO6	8	/* Guest can handle TSOv6 in. */
@@ -73,6 +74,8 @@ struct virtio_net_config {
 	 * Legal values are between 1 and 0x8000
 	 */
 	uint16_t max_virtqueue_pairs;
+	/* Default maximum transmit unit advice */
+	uint16_t mtu;
 } QEMU_PACKED;
 
 /*
diff --git a/include/standard-headers/linux/virtio_vsock.h b/include/standard-headers/linux/virtio_vsock.h
new file mode 100644
index 0000000..be44321
--- /dev/null
+++ b/include/standard-headers/linux/virtio_vsock.h
@@ -0,0 +1,94 @@
+/*
+ * This header, excluding the #ifdef __KERNEL__ part, is BSD licensed so
+ * anyone can use the definitions to implement compatible drivers/servers:
+ *
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in the
+ *    documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of IBM nor the names of its contributors
+ *    may be used to endorse or promote products derived from this software
+ *    without specific prior written permission.
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS''
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL IBM OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ *
+ * Copyright (C) Red Hat, Inc., 2013-2015
+ * Copyright (C) Asias He <asias@redhat.com>, 2013
+ * Copyright (C) Stefan Hajnoczi <stefanha@redhat.com>, 2015
+ */
+
+#ifndef _LINUX_VIRTIO_VSOCK_H
+#define _LINUX_VIRTIO_VSOCK_H
+
+#include "standard-headers/linux/types.h"
+#include "standard-headers/linux/virtio_ids.h"
+#include "standard-headers/linux/virtio_config.h"
+
+struct virtio_vsock_config {
+	uint64_t guest_cid;
+} QEMU_PACKED;
+
+enum virtio_vsock_event_id {
+	VIRTIO_VSOCK_EVENT_TRANSPORT_RESET = 0,
+};
+
+struct virtio_vsock_event {
+	uint32_t id;
+} QEMU_PACKED;
+
+struct virtio_vsock_hdr {
+	uint64_t	src_cid;
+	uint64_t	dst_cid;
+	uint32_t	src_port;
+	uint32_t	dst_port;
+	uint32_t	len;
+	uint16_t	type;		/* enum virtio_vsock_type */
+	uint16_t	op;		/* enum virtio_vsock_op */
+	uint32_t	flags;
+	uint32_t	buf_alloc;
+	uint32_t	fwd_cnt;
+} QEMU_PACKED;
+
+enum virtio_vsock_type {
+	VIRTIO_VSOCK_TYPE_STREAM = 1,
+};
+
+enum virtio_vsock_op {
+	VIRTIO_VSOCK_OP_INVALID = 0,
+
+	/* Connect operations */
+	VIRTIO_VSOCK_OP_REQUEST = 1,
+	VIRTIO_VSOCK_OP_RESPONSE = 2,
+	VIRTIO_VSOCK_OP_RST = 3,
+	VIRTIO_VSOCK_OP_SHUTDOWN = 4,
+
+	/* To send payload */
+	VIRTIO_VSOCK_OP_RW = 5,
+
+	/* Tell the peer our credit info */
+	VIRTIO_VSOCK_OP_CREDIT_UPDATE = 6,
+	/* Request the peer to send the credit info to us */
+	VIRTIO_VSOCK_OP_CREDIT_REQUEST = 7,
+};
+
+/* VIRTIO_VSOCK_OP_SHUTDOWN flags values */
+enum virtio_vsock_shutdown {
+	VIRTIO_VSOCK_SHUTDOWN_RCV = 1,
+	VIRTIO_VSOCK_SHUTDOWN_SEND = 2,
+};
+
+#endif /* _LINUX_VIRTIO_VSOCK_H */
diff --git a/linux-headers/asm-arm/kvm.h b/linux-headers/asm-arm/kvm.h
index c98e4dc..541268c 100644
--- a/linux-headers/asm-arm/kvm.h
+++ b/linux-headers/asm-arm/kvm.h
@@ -139,8 +139,8 @@ struct kvm_arch_memory_slot {
 #define ARM_CP15_REG64(...) __ARM_CP15_REG64(__VA_ARGS__)
 
 #define KVM_REG_ARM_TIMER_CTL		ARM_CP15_REG32(0, 14, 3, 1)
-#define KVM_REG_ARM_TIMER_CNT		ARM_CP15_REG64(1, 14) 
-#define KVM_REG_ARM_TIMER_CVAL		ARM_CP15_REG64(3, 14) 
+#define KVM_REG_ARM_TIMER_CNT		ARM_CP15_REG64(1, 14)
+#define KVM_REG_ARM_TIMER_CVAL		ARM_CP15_REG64(3, 14)
 
 /* Normal registers are mapped as coprocessor 16. */
 #define KVM_REG_ARM_CORE		(0x0010 << KVM_REG_ARM_COPROC_SHIFT)
diff --git a/linux-headers/asm-arm64/kvm.h b/linux-headers/asm-arm64/kvm.h
index 7d82d1f..fd5a276 100644
--- a/linux-headers/asm-arm64/kvm.h
+++ b/linux-headers/asm-arm64/kvm.h
@@ -87,9 +87,11 @@ struct kvm_regs {
 /* Supported VGICv3 address types  */
 #define KVM_VGIC_V3_ADDR_TYPE_DIST	2
 #define KVM_VGIC_V3_ADDR_TYPE_REDIST	3
+#define KVM_VGIC_ITS_ADDR_TYPE		4
 
 #define KVM_VGIC_V3_DIST_SIZE		SZ_64K
 #define KVM_VGIC_V3_REDIST_SIZE		(2 * SZ_64K)
+#define KVM_VGIC_V3_ITS_SIZE		(2 * SZ_64K)
 
 #define KVM_ARM_VCPU_POWER_OFF		0 /* CPU is started in OFF state */
 #define KVM_ARM_VCPU_EL1_32BIT		1 /* CPU running a 32bit VM */
diff --git a/linux-headers/asm-s390/kvm.h b/linux-headers/asm-s390/kvm.h
index 09ae5dc..ac63ca6 100644
--- a/linux-headers/asm-s390/kvm.h
+++ b/linux-headers/asm-s390/kvm.h
@@ -93,6 +93,47 @@ struct kvm_s390_vm_cpu_machine {
 	__u64 fac_list[256];
 };
 
+#define KVM_S390_VM_CPU_PROCESSOR_FEAT	2
+#define KVM_S390_VM_CPU_MACHINE_FEAT	3
+
+#define KVM_S390_VM_CPU_FEAT_NR_BITS	1024
+#define KVM_S390_VM_CPU_FEAT_ESOP	0
+#define KVM_S390_VM_CPU_FEAT_SIEF2	1
+#define KVM_S390_VM_CPU_FEAT_64BSCAO	2
+#define KVM_S390_VM_CPU_FEAT_SIIF	3
+#define KVM_S390_VM_CPU_FEAT_GPERE	4
+#define KVM_S390_VM_CPU_FEAT_GSLS	5
+#define KVM_S390_VM_CPU_FEAT_IB		6
+#define KVM_S390_VM_CPU_FEAT_CEI	7
+#define KVM_S390_VM_CPU_FEAT_IBS	8
+#define KVM_S390_VM_CPU_FEAT_SKEY	9
+#define KVM_S390_VM_CPU_FEAT_CMMA	10
+#define KVM_S390_VM_CPU_FEAT_PFMFI	11
+#define KVM_S390_VM_CPU_FEAT_SIGPIF	12
+struct kvm_s390_vm_cpu_feat {
+	__u64 feat[16];
+};
+
+#define KVM_S390_VM_CPU_PROCESSOR_SUBFUNC	4
+#define KVM_S390_VM_CPU_MACHINE_SUBFUNC		5
+/* for "test bit" instructions MSB 0 bit ordering, for "query" raw blocks */
+struct kvm_s390_vm_cpu_subfunc {
+	__u8 plo[32];		/* always */
+	__u8 ptff[16];		/* with TOD-clock steering */
+	__u8 kmac[16];		/* with MSA */
+	__u8 kmc[16];		/* with MSA */
+	__u8 km[16];		/* with MSA */
+	__u8 kimd[16];		/* with MSA */
+	__u8 klmd[16];		/* with MSA */
+	__u8 pckmo[16];		/* with MSA3 */
+	__u8 kmctr[16];		/* with MSA4 */
+	__u8 kmf[16];		/* with MSA4 */
+	__u8 kmo[16];		/* with MSA4 */
+	__u8 pcc[16];		/* with MSA4 */
+	__u8 ppno[16];		/* with MSA5 */
+	__u8 reserved[1824];
+};
+
 /* kvm attributes for crypto */
 #define KVM_S390_VM_CRYPTO_ENABLE_AES_KW	0
 #define KVM_S390_VM_CRYPTO_ENABLE_DEA_KW	1
diff --git a/linux-headers/asm-x86/unistd_x32.h b/linux-headers/asm-x86/unistd_x32.h
index 0230779..e5aea76 100644
--- a/linux-headers/asm-x86/unistd_x32.h
+++ b/linux-headers/asm-x86/unistd_x32.h
@@ -306,9 +306,7 @@
 #define __NR_vmsplice (__X32_SYSCALL_BIT + 532)
 #define __NR_move_pages (__X32_SYSCALL_BIT + 533)
 #define __NR_preadv (__X32_SYSCALL_BIT + 534)
-#define __NR_preadv2 (__X32_SYSCALL_BIT + 534)
 #define __NR_pwritev (__X32_SYSCALL_BIT + 535)
-#define __NR_pwritev2 (__X32_SYSCALL_BIT + 535)
 #define __NR_rt_tgsigqueueinfo (__X32_SYSCALL_BIT + 536)
 #define __NR_recvmmsg (__X32_SYSCALL_BIT + 537)
 #define __NR_sendmmsg (__X32_SYSCALL_BIT + 538)
@@ -319,5 +317,7 @@
 #define __NR_io_setup (__X32_SYSCALL_BIT + 543)
 #define __NR_io_submit (__X32_SYSCALL_BIT + 544)
 #define __NR_execveat (__X32_SYSCALL_BIT + 545)
+#define __NR_preadv2 (__X32_SYSCALL_BIT + 546)
+#define __NR_pwritev2 (__X32_SYSCALL_BIT + 547)
 
 #endif /* _ASM_X86_UNISTD_X32_H */
diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index e60e21b..4806e06 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/linux/kvm.h
@@ -866,6 +866,10 @@ struct kvm_ppc_smmu_info {
 #define KVM_CAP_ARM_PMU_V3 126
 #define KVM_CAP_VCPU_ATTRIBUTES 127
 #define KVM_CAP_MAX_VCPU_ID 128
+#define KVM_CAP_X2APIC_API 129
+#define KVM_CAP_S390_USER_INSTR0 130
+#define KVM_CAP_MSI_DEVID 131
+#define KVM_CAP_PPC_HTM 132
 
 #ifdef KVM_CAP_IRQ_ROUTING
 
@@ -878,7 +882,10 @@ struct kvm_irq_routing_msi {
 	__u32 address_lo;
 	__u32 address_hi;
 	__u32 data;
-	__u32 pad;
+	union {
+		__u32 pad;
+		__u32 devid;
+	};
 };
 
 struct kvm_irq_routing_s390_adapter {
@@ -1024,12 +1031,14 @@ struct kvm_one_reg {
 	__u64 addr;
 };
 
+#define KVM_MSI_VALID_DEVID	(1U << 0)
 struct kvm_msi {
 	__u32 address_lo;
 	__u32 address_hi;
 	__u32 data;
 	__u32 flags;
-	__u8  pad[16];
+	__u32 devid;
+	__u8  pad[12];
 };
 
 struct kvm_arm_device_addr {
@@ -1074,6 +1083,8 @@ enum kvm_device_type {
 #define KVM_DEV_TYPE_FLIC		KVM_DEV_TYPE_FLIC
 	KVM_DEV_TYPE_ARM_VGIC_V3,
 #define KVM_DEV_TYPE_ARM_VGIC_V3	KVM_DEV_TYPE_ARM_VGIC_V3
+	KVM_DEV_TYPE_ARM_VGIC_ITS,
+#define KVM_DEV_TYPE_ARM_VGIC_ITS	KVM_DEV_TYPE_ARM_VGIC_ITS
 	KVM_DEV_TYPE_MAX,
 };
 
@@ -1313,4 +1324,7 @@ struct kvm_assigned_msix_entry {
 	__u16 padding[3];
 };
 
+#define KVM_X2APIC_API_USE_32BIT_IDS            (1ULL << 0)
+#define KVM_X2APIC_API_DISABLE_BROADCAST_QUIRK  (1ULL << 1)
+
 #endif /* __LINUX_KVM_H */
diff --git a/linux-headers/linux/vhost.h b/linux-headers/linux/vhost.h
index 571294c..ac7a1f1 100644
--- a/linux-headers/linux/vhost.h
+++ b/linux-headers/linux/vhost.h
@@ -47,6 +47,32 @@ struct vhost_vring_addr {
 	__u64 log_guest_addr;
 };
 
+/* no alignment requirement */
+struct vhost_iotlb_msg {
+	__u64 iova;
+	__u64 size;
+	__u64 uaddr;
+#define VHOST_ACCESS_RO      0x1
+#define VHOST_ACCESS_WO      0x2
+#define VHOST_ACCESS_RW      0x3
+	__u8 perm;
+#define VHOST_IOTLB_MISS           1
+#define VHOST_IOTLB_UPDATE         2
+#define VHOST_IOTLB_INVALIDATE     3
+#define VHOST_IOTLB_ACCESS_FAIL    4
+	__u8 type;
+};
+
+#define VHOST_IOTLB_MSG 0x1
+
+struct vhost_msg {
+	int type;
+	union {
+		struct vhost_iotlb_msg iotlb;
+		__u8 padding[64];
+	};
+};
+
 struct vhost_memory_region {
 	__u64 guest_phys_addr;
 	__u64 memory_size; /* bytes */
@@ -146,6 +172,8 @@ struct vhost_memory {
 #define VHOST_F_LOG_ALL 26
 /* vhost-net should add virtio_net_hdr for RX, and strip for TX packets. */
 #define VHOST_NET_F_VIRTIO_NET_HDR 27
+/* Vhost have device IOTLB */
+#define VHOST_F_DEVICE_IOTLB 63
 
 /* VHOST_SCSI specific definitions */
 
@@ -175,4 +203,9 @@ struct vhost_scsi_target {
 #define VHOST_SCSI_SET_EVENTS_MISSED _IOW(VHOST_VIRTIO, 0x43, __u32)
 #define VHOST_SCSI_GET_EVENTS_MISSED _IOW(VHOST_VIRTIO, 0x44, __u32)
 
+/* VHOST_VSOCK specific defines */
+
+#define VHOST_VSOCK_SET_GUEST_CID	_IOW(VHOST_VIRTIO, 0x60, __u64)
+#define VHOST_VSOCK_SET_RUNNING		_IOW(VHOST_VIRTIO, 0x61, int)
+
 #endif
-- 
2.7.4

[Qemu-devel] [PULL 2/4] hw/ppc/spapr: Move code related to "ibm, pa-features" to a separate function

[David Gibson]

From: Thomas Huth <thuth@redhat.com>

The function spapr_populate_cpu_dt() has become quite big
already, and since we likely have to extend the pa-features
property for every new processor generation, it is nicer
if we put the related code into a separate function.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
(cherry picked from commit 230bf719d3a3b144a4ffa441e5d6170ef0ad8999)
---
 hw/ppc/spapr.c | 66 ++++++++++++++++++++++++++++++++--------------------------
 1 file changed, 36 insertions(+), 30 deletions(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 30d6800..36d9077 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -594,6 +594,41 @@ static int spapr_populate_memory(sPAPRMachineState *spapr, void *fdt)
     return 0;
 }
 
+/* Populate the "ibm,pa-features" property */
+static void spapr_populate_pa_features(CPUPPCState *env, void *fdt, int offset)
+{
+    uint8_t pa_features_206[] = { 6, 0,
+        0xf6, 0x1f, 0xc7, 0x00, 0x80, 0xc0 };
+    uint8_t pa_features_207[] = { 24, 0,
+        0xf6, 0x1f, 0xc7, 0xc0, 0x80, 0xf0,
+        0x80, 0x00, 0x00, 0x00, 0x00, 0x00,
+        0x00, 0x00, 0x00, 0x00, 0x80, 0x00,
+        0x80, 0x00, 0x80, 0x00, 0x80, 0x00 };
+    uint8_t *pa_features;
+    size_t pa_size;
+
+    if (env->mmu_model == POWERPC_MMU_2_06) {
+        pa_features = pa_features_206;
+        pa_size = sizeof(pa_features_206);
+    } else { /* env->mmu_model == POWERPC_MMU_2_07 */
+        pa_features = pa_features_207;
+        pa_size = sizeof(pa_features_207);
+    }
+
+    if (env->ci_large_pages) {
+        /*
+         * Note: we keep CI large pages off by default because a 64K capable
+         * guest provisioned with large pages might otherwise try to map a qemu
+         * framebuffer (or other kind of memory mapped PCI BAR) using 64K pages
+         * even if that qemu runs on a 4k host.
+         * We dd this bit back here if we are confident this is not an issue
+         */
+        pa_features[3] |= 0x20;
+    }
+
+    _FDT((fdt_setprop(fdt, offset, "ibm,pa-features", pa_features, pa_size)));
+}
+
 static void spapr_populate_cpu_dt(CPUState *cs, void *fdt, int offset,
                                   sPAPRMachineState *spapr)
 {
@@ -621,24 +656,6 @@ static void spapr_populate_cpu_dt(CPUState *cs, void *fdt, int offset,
         _FDT((fdt_setprop_cell(fdt, offset, "ibm,my-drc-index", drc_index)));
     }
 
-    /* Note: we keep CI large pages off for now because a 64K capable guest
-     * provisioned with large pages might otherwise try to map a qemu
-     * framebuffer (or other kind of memory mapped PCI BAR) using 64K pages
-     * even if that qemu runs on a 4k host.
-     *
-     * We can later add this bit back when we are confident this is not
-     * an issue (!HV KVM or 64K host)
-     */
-    uint8_t pa_features_206[] = { 6, 0,
-        0xf6, 0x1f, 0xc7, 0x00, 0x80, 0xc0 };
-    uint8_t pa_features_207[] = { 24, 0,
-        0xf6, 0x1f, 0xc7, 0xc0, 0x80, 0xf0,
-        0x80, 0x00, 0x00, 0x00, 0x00, 0x00,
-        0x00, 0x00, 0x00, 0x00, 0x80, 0x00,
-        0x80, 0x00, 0x80, 0x00, 0x80, 0x00 };
-    uint8_t *pa_features;
-    size_t pa_size;
-
     _FDT((fdt_setprop_cell(fdt, offset, "reg", index)));
     _FDT((fdt_setprop_string(fdt, offset, "device_type", "cpu")));
 
@@ -705,18 +722,7 @@ static void spapr_populate_cpu_dt(CPUState *cs, void *fdt, int offset,
                           page_sizes_prop, page_sizes_prop_size)));
     }
 
-    /* Do the ibm,pa-features property, adjust it for ci-large-pages */
-    if (env->mmu_model == POWERPC_MMU_2_06) {
-        pa_features = pa_features_206;
-        pa_size = sizeof(pa_features_206);
-    } else /* env->mmu_model == POWERPC_MMU_2_07 */ {
-        pa_features = pa_features_207;
-        pa_size = sizeof(pa_features_207);
-    }
-    if (env->ci_large_pages) {
-        pa_features[3] |= 0x20;
-    }
-    _FDT((fdt_setprop(fdt, offset, "ibm,pa-features", pa_features, pa_size)));
+    spapr_populate_pa_features(env, fdt, offset);
 
     _FDT((fdt_setprop_cell(fdt, offset, "ibm,chip-id",
                            cs->cpu_index / vcpus_per_socket)));
-- 
2.7.4

[Qemu-devel] [PULL 3/4] hw/ppc/spapr: Fix the selection of the processor features

[David Gibson]

From: Thomas Huth <thuth@redhat.com>

The current code uses pa_features_206 for POWERPC_MMU_2_06, and
for everything else, it uses pa_features_207. This is bad in some
cases because there is also a "degraded" MMU version of ISA 2.06,
called POWERPC_MMU_2_06a, which should of course use the flags for
2.06 instead. And there is also the possibility that the user runs
the pseries machine with a POWER5+ or even 970 processor. In that
case we certainly do not want to set the flags for 2.07, and rather
simply skip the setting of the pa-features property instead.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
(cherry picked from commit 4cbec30d769a73853b60dc7f275e6e7da9ab5162)
---
 hw/ppc/spapr.c | 11 +++++++++--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 36d9077..9f0d99b 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -607,12 +607,19 @@ static void spapr_populate_pa_features(CPUPPCState *env, void *fdt, int offset)
     uint8_t *pa_features;
     size_t pa_size;
 
-    if (env->mmu_model == POWERPC_MMU_2_06) {
+    switch (env->mmu_model) {
+    case POWERPC_MMU_2_06:
+    case POWERPC_MMU_2_06a:
         pa_features = pa_features_206;
         pa_size = sizeof(pa_features_206);
-    } else { /* env->mmu_model == POWERPC_MMU_2_07 */
+        break;
+    case POWERPC_MMU_2_07:
+    case POWERPC_MMU_2_07a:
         pa_features = pa_features_207;
         pa_size = sizeof(pa_features_207);
+        break;
+    default:
+        return;
     }
 
     if (env->ci_large_pages) {
-- 
2.7.4

[Qemu-devel] [PULL 4/4] ppc: Check the availability of transactional memory

[David Gibson]

From: Thomas Huth <thuth@redhat.com>

KVM-PR currently does not support transactional memory, and the
implementation in TCG is just a fake. We should not announce TM
support in the ibm,pa-features property when running on such a
system, so disable it by default and only enable it if the KVM
implementation supports it (i.e. recent versions of KVM-HV).
These changes are based on some earlier work from Anton Blanchard
(thanks!).

Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
(cherry picked from commit bac3bf287ab60e264b636f5f00c116a19b655762)
---
 hw/ppc/spapr.c       | 5 ++++-
 target-ppc/kvm.c     | 7 +++++++
 target-ppc/kvm_ppc.h | 6 ++++++
 3 files changed, 17 insertions(+), 1 deletion(-)

diff --git a/hw/ppc/spapr.c b/hw/ppc/spapr.c
index 9f0d99b..82723d1 100644
--- a/hw/ppc/spapr.c
+++ b/hw/ppc/spapr.c
@@ -603,7 +603,7 @@ static void spapr_populate_pa_features(CPUPPCState *env, void *fdt, int offset)
         0xf6, 0x1f, 0xc7, 0xc0, 0x80, 0xf0,
         0x80, 0x00, 0x00, 0x00, 0x00, 0x00,
         0x00, 0x00, 0x00, 0x00, 0x80, 0x00,
-        0x80, 0x00, 0x80, 0x00, 0x80, 0x00 };
+        0x80, 0x00, 0x80, 0x00, 0x00, 0x00 };
     uint8_t *pa_features;
     size_t pa_size;
 
@@ -632,6 +632,9 @@ static void spapr_populate_pa_features(CPUPPCState *env, void *fdt, int offset)
          */
         pa_features[3] |= 0x20;
     }
+    if (kvmppc_has_cap_htm() && pa_size > 24) {
+        pa_features[24] |= 0x80;    /* Transactional memory support */
+    }
 
     _FDT((fdt_setprop(fdt, offset, "ibm,pa-features", pa_features, pa_size)));
 }
diff --git a/target-ppc/kvm.c b/target-ppc/kvm.c
index dcb68b9..f26a141 100644
--- a/target-ppc/kvm.c
+++ b/target-ppc/kvm.c
@@ -79,6 +79,7 @@ static int cap_ppc_watchdog;
 static int cap_papr;
 static int cap_htab_fd;
 static int cap_fixup_hcalls;
+static int cap_htm;             /* Hardware transactional memory support */
 
 static uint32_t debug_inst_opcode;
 
@@ -121,6 +122,7 @@ int kvm_arch_init(MachineState *ms, KVMState *s)
      * only activated after this by kvmppc_set_papr() */
     cap_htab_fd = kvm_check_extension(s, KVM_CAP_PPC_HTAB_FD);
     cap_fixup_hcalls = kvm_check_extension(s, KVM_CAP_PPC_FIXUP_HCALL);
+    cap_htm = kvm_vm_check_extension(s, KVM_CAP_PPC_HTM);
 
     if (!cap_interrupt_level) {
         fprintf(stderr, "KVM: Couldn't find level irq capability. Expect the "
@@ -2339,6 +2341,11 @@ bool kvmppc_has_cap_fixup_hcalls(void)
     return cap_fixup_hcalls;
 }
 
+bool kvmppc_has_cap_htm(void)
+{
+    return cap_htm;
+}
+
 static PowerPCCPUClass *ppc_cpu_get_family_class(PowerPCCPUClass *pcc)
 {
     ObjectClass *oc = OBJECT_CLASS(pcc);
diff --git a/target-ppc/kvm_ppc.h b/target-ppc/kvm_ppc.h
index 5461d10..e45c815 100644
--- a/target-ppc/kvm_ppc.h
+++ b/target-ppc/kvm_ppc.h
@@ -54,6 +54,7 @@ void kvmppc_hash64_free_pteg(uint64_t token);
 void kvmppc_hash64_write_pte(CPUPPCState *env, target_ulong pte_index,
                              target_ulong pte0, target_ulong pte1);
 bool kvmppc_has_cap_fixup_hcalls(void);
+bool kvmppc_has_cap_htm(void);
 int kvmppc_enable_hwrng(void);
 int kvmppc_put_books_sregs(PowerPCCPU *cpu);
 PowerPCCPUClass *kvm_ppc_get_host_cpu_class(void);
@@ -244,6 +245,11 @@ static inline bool kvmppc_has_cap_fixup_hcalls(void)
     abort();
 }
 
+static inline bool kvmppc_has_cap_htm(void)
+{
+    return false;
+}
+
 static inline int kvmppc_enable_hwrng(void)
 {
     return -1;
-- 
2.7.4

Re: [Qemu-devel] [PULL 0/4] ppc patches for qemu-2.7 stable branch

[Peter Maydell]

On 13 October 2016 at 06:15, David Gibson <david@gibson.dropbear.id.au> wrote:
> The following changes since commit 1dc33ed90bf1fe1c2014dffa0d9e863c520d953a:
>
>   Update version for v2.7.0 release (2016-09-02 13:44:11 +0100)
>
> are available in the git repository at:
>
>   git://github.com/dgibson/qemu.git tags/ppc-for-2.7-20161013
>
> for you to fetch changes up to 2e68f28854f0120c9a938a61b64aaf1eaecb162b:
>
>   ppc: Check the availability of transactional memory (2016-10-13 12:58:06 +1100)

Applied to master, thanks. (I hope that was what you had in mind;
if not we'll have to unwind stuff somehow...)

-- PMM

Re: [Qemu-devel] [PULL 0/4] ppc patches for qemu-2.7 stable branch

[Peter Maydell]

On 13 October 2016 at 12:54, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 13 October 2016 at 06:15, David Gibson <david@gibson.dropbear.id.au> wrote:
>> The following changes since commit 1dc33ed90bf1fe1c2014dffa0d9e863c520d953a:
>>
>>   Update version for v2.7.0 release (2016-09-02 13:44:11 +0100)
>>
>> are available in the git repository at:
>>
>>   git://github.com/dgibson/qemu.git tags/ppc-for-2.7-20161013
>>
>> for you to fetch changes up to 2e68f28854f0120c9a938a61b64aaf1eaecb162b:
>>
>>   ppc: Check the availability of transactional memory (2016-10-13 12:58:06 +1100)
>
> Applied to master, thanks. (I hope that was what you had in mind;
> if not we'll have to unwind stuff somehow...)

unwind> looking more closely, there's no actual diff between HEAD
now and what it was, so the merge commit is a no-op of sorts.
Hopefully it doesn't cause any problems.

More generally, we need to come up with something for distinguishing
PULL requests not for master, because my current workflow basically
says "anything that says 'for you to fetch changes up to' will get
merged into master...

thanks
-- PMM

Re: [Qemu-devel] [PULL 0/4] ppc patches for qemu-2.7 stable branch

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 1659 bytes --]

On Thu, Oct 13, 2016 at 12:57:19PM +0100, Peter Maydell wrote:
> On 13 October 2016 at 12:54, Peter Maydell <peter.maydell@linaro.org> wrote:
> > On 13 October 2016 at 06:15, David Gibson <david@gibson.dropbear.id.au> wrote:
> >> The following changes since commit 1dc33ed90bf1fe1c2014dffa0d9e863c520d953a:
> >>
> >>   Update version for v2.7.0 release (2016-09-02 13:44:11 +0100)
> >>
> >> are available in the git repository at:
> >>
> >>   git://github.com/dgibson/qemu.git tags/ppc-for-2.7-20161013
> >>
> >> for you to fetch changes up to 2e68f28854f0120c9a938a61b64aaf1eaecb162b:
> >>
> >>   ppc: Check the availability of transactional memory (2016-10-13 12:58:06 +1100)
> >
> > Applied to master, thanks. (I hope that was what you had in mind;
> > if not we'll have to unwind stuff somehow...)
> 
> unwind> looking more closely, there's no actual diff between HEAD
> now and what it was, so the merge commit is a no-op of sorts.
> Hopefully it doesn't cause any problems.

Right.. these were all (clean) cherry picks from the master branch
anyway, so I'd expect it to be a no-op.

> More generally, we need to come up with something for distinguishing
> PULL requests not for master, because my current workflow basically
> says "anything that says 'for you to fetch changes up to' will get
> merged into master...

Um.. yes.. this was intended for merge to the 2.7 branch, not master.
Any ideas how I should express that?

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Qemu-devel] [Qemu-ppc] [PULL 0/4] ppc patches for qemu-2.7 stable branch

[Greg Kurz]

[-- Attachment #1: Type: text/plain, Size: 2015 bytes --]

On Fri, 14 Oct 2016 09:28:35 +1100
David Gibson <david@gibson.dropbear.id.au> wrote:

> On Thu, Oct 13, 2016 at 12:57:19PM +0100, Peter Maydell wrote:
> > On 13 October 2016 at 12:54, Peter Maydell <peter.maydell@linaro.org> wrote:  
> > > On 13 October 2016 at 06:15, David Gibson <david@gibson.dropbear.id.au> wrote:  
> > >> The following changes since commit 1dc33ed90bf1fe1c2014dffa0d9e863c520d953a:
> > >>
> > >>   Update version for v2.7.0 release (2016-09-02 13:44:11 +0100)
> > >>
> > >> are available in the git repository at:
> > >>
> > >>   git://github.com/dgibson/qemu.git tags/ppc-for-2.7-20161013
> > >>
> > >> for you to fetch changes up to 2e68f28854f0120c9a938a61b64aaf1eaecb162b:
> > >>
> > >>   ppc: Check the availability of transactional memory (2016-10-13 12:58:06 +1100)  
> > >
> > > Applied to master, thanks. (I hope that was what you had in mind;
> > > if not we'll have to unwind stuff somehow...)  
> >   
> > unwind> looking more closely, there's no actual diff between HEAD  
> > now and what it was, so the merge commit is a no-op of sorts.
> > Hopefully it doesn't cause any problems.  
> 
> Right.. these were all (clean) cherry picks from the master branch
> anyway, so I'd expect it to be a no-op.
> 
> > More generally, we need to come up with something for distinguishing
> > PULL requests not for master, because my current workflow basically
> > says "anything that says 'for you to fetch changes up to' will get
> > merged into master...  
> 
> Um.. yes.. this was intended for merge to the 2.7 branch, not master.
> Any ideas how I should express that?
> 

I'm not aware of any formal process, other than sending a mail to
qemu-stable and Cc: Michael Roth. This is often done by simply
replying to selected messages in the pull requests for the master
branch.

Then Michael does all the cherry picking stuff and usually sends a 
patch round-up two weeks before the stable release, for people to
review.

Cheers.

--
Greg

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [Qemu-devel] [Qemu-ppc] [PULL 0/4] ppc patches for qemu-2.7 stable branch

[Peter Maydell]

On 14 October 2016 at 09:27, Greg Kurz <groug@kaod.org> wrote:
> On Fri, 14 Oct 2016 09:28:35 +1100
> David Gibson <david@gibson.dropbear.id.au> wrote:
>
>> On Thu, Oct 13, 2016 at 12:57:19PM +0100, Peter Maydell wrote:
>> > On 13 October 2016 at 12:54, Peter Maydell <peter.maydell@linaro.org> wrote:
>> > More generally, we need to come up with something for distinguishing
>> > PULL requests not for master, because my current workflow basically
>> > says "anything that says 'for you to fetch changes up to' will get
>> > merged into master...
>>
>> Um.. yes.. this was intended for merge to the 2.7 branch, not master.
>> Any ideas how I should express that?
>>
>
> I'm not aware of any formal process, other than sending a mail to
> qemu-stable and Cc: Michael Roth. This is often done by simply
> replying to selected messages in the pull requests for the master
> branch.
>
> Then Michael does all the cherry picking stuff and usually sends a
> patch round-up two weeks before the stable release, for people to
> review.

Yes, I think I was partly thrown because in general patches
don't go into the stable branches via pull requests.
That said, my current filter/workflow is clearly broken
so I'm open to any suggestions for easy-for-me-to-filter-for
ways to flag up that a pull request isn't aimed at master.

thanks
-- PMM

Re: [Qemu-devel] [Qemu-ppc] [PULL 0/4] ppc patches for qemu-2.7 stable branch

[Thomas Huth]

On 14.10.2016 19:38, Peter Maydell wrote:
> On 14 October 2016 at 09:27, Greg Kurz <groug@kaod.org> wrote:
>> On Fri, 14 Oct 2016 09:28:35 +1100
>> David Gibson <david@gibson.dropbear.id.au> wrote:
>>
>>> On Thu, Oct 13, 2016 at 12:57:19PM +0100, Peter Maydell wrote:
>>>> On 13 October 2016 at 12:54, Peter Maydell <peter.maydell@linaro.org> wrote:
>>>> More generally, we need to come up with something for distinguishing
>>>> PULL requests not for master, because my current workflow basically
>>>> says "anything that says 'for you to fetch changes up to' will get
>>>> merged into master...
>>>
>>> Um.. yes.. this was intended for merge to the 2.7 branch, not master.
>>> Any ideas how I should express that?
>>>
>>
>> I'm not aware of any formal process, other than sending a mail to
>> qemu-stable and Cc: Michael Roth. This is often done by simply
>> replying to selected messages in the pull requests for the master
>> branch.
>>
>> Then Michael does all the cherry picking stuff and usually sends a
>> patch round-up two weeks before the stable release, for people to
>> review.
> 
> Yes, I think I was partly thrown because in general patches
> don't go into the stable branches via pull requests.
> That said, my current filter/workflow is clearly broken
> so I'm open to any suggestions for easy-for-me-to-filter-for
> ways to flag up that a pull request isn't aimed at master.

Maybe simply filter out the requests that include qemu-stable in "To:" ?

 Thomas

Re: [Qemu-devel] [Qemu-stable] [Qemu-ppc] [PULL 0/4] ppc patches for qemu-2.7 stable branch

[Michael Roth]

Quoting Thomas Huth (2016-10-17 02:44:59)
> On 14.10.2016 19:38, Peter Maydell wrote:
> > On 14 October 2016 at 09:27, Greg Kurz <groug@kaod.org> wrote:
> >> On Fri, 14 Oct 2016 09:28:35 +1100
> >> David Gibson <david@gibson.dropbear.id.au> wrote:
> >>
> >>> On Thu, Oct 13, 2016 at 12:57:19PM +0100, Peter Maydell wrote:
> >>>> On 13 October 2016 at 12:54, Peter Maydell <peter.maydell@linaro.org> wrote:
> >>>> More generally, we need to come up with something for distinguishing
> >>>> PULL requests not for master, because my current workflow basically
> >>>> says "anything that says 'for you to fetch changes up to' will get
> >>>> merged into master...
> >>>
> >>> Um.. yes.. this was intended for merge to the 2.7 branch, not master.
> >>> Any ideas how I should express that?
> >>>
> >>
> >> I'm not aware of any formal process, other than sending a mail to
> >> qemu-stable and Cc: Michael Roth. This is often done by simply
> >> replying to selected messages in the pull requests for the master
> >> branch.
> >>
> >> Then Michael does all the cherry picking stuff and usually sends a
> >> patch round-up two weeks before the stable release, for people to
> >> review.
> > 
> > Yes, I think I was partly thrown because in general patches
> > don't go into the stable branches via pull requests.
> > That said, my current filter/workflow is clearly broken
> > so I'm open to any suggestions for easy-for-me-to-filter-for
> > ways to flag up that a pull request isn't aimed at master.
> 
> Maybe simply filter out the requests that include qemu-stable in "To:" ?

Maybe just a tag like [PULL for-stable], or [PULL for-2.7]?

The latter seems to mirror how we handle things for patches coming for
master during freeze. Others who've submitted patches they've
backported themselves for stable seem to naturally lean toward that
approach as well.

That said, this might get confusing immediately after a release, where
there are a lot of patches floating around with such tags, cc:'d for
stable, that aren't actually meant to be directly pulled into stable.
So I think I would lean toward "for-stable", or, even better,
"for-2.7.1", etc.

I don't do automated pulls so it's not a huge deal either way for me,
but "for-x" in general should hopefully be enough for Peter to filter
them out for master based on what whether "x" references the next
major release or not.

> 
>  Thomas
> 
> 

Re: [Qemu-devel] [Qemu-stable] [Qemu-ppc] [PULL 0/4] ppc patches for qemu-2.7 stable branch

[Peter Maydell]

On 17 October 2016 at 17:51, Michael Roth <mdroth@linux.vnet.ibm.com> wrote:
> Maybe just a tag like [PULL for-stable], or [PULL for-2.7]?
>
> The latter seems to mirror how we handle things for patches coming for
> master during freeze. Others who've submitted patches they've
> backported themselves for stable seem to naturally lean toward that
> approach as well.
>
> That said, this might get confusing immediately after a release, where
> there are a lot of patches floating around with such tags, cc:'d for
> stable, that aren't actually meant to be directly pulled into stable.
> So I think I would lean toward "for-stable", or, even better,
> "for-2.7.1", etc.
>
> I don't do automated pulls so it's not a huge deal either way for me,
> but "for-x" in general should hopefully be enough for Peter to filter
> them out for master based on what whether "x" references the next
> major release or not.

I don't really want to have to update my email filters every
time we do a release, though, and so "for-X.Y" doesn't work because
when we are in the runup to release pull requests targeting
master tend to be marked that way.

Maybe just having not-for-master pull requests say "not for master"
in the cover letter somewhere ?

thanks
-- PMM

Re: [Qemu-devel] [Qemu-stable] [Qemu-ppc] [PULL 0/4] ppc patches for qemu-2.7 stable branch

[Michael Roth]

Quoting Peter Maydell (2016-10-17 12:33:18)
> On 17 October 2016 at 17:51, Michael Roth <mdroth@linux.vnet.ibm.com> wrote:
> > Maybe just a tag like [PULL for-stable], or [PULL for-2.7]?
> >
> > The latter seems to mirror how we handle things for patches coming for
> > master during freeze. Others who've submitted patches they've
> > backported themselves for stable seem to naturally lean toward that
> > approach as well.
> >
> > That said, this might get confusing immediately after a release, where
> > there are a lot of patches floating around with such tags, cc:'d for
> > stable, that aren't actually meant to be directly pulled into stable.
> > So I think I would lean toward "for-stable", or, even better,
> > "for-2.7.1", etc.
> >
> > I don't do automated pulls so it's not a huge deal either way for me,
> > but "for-x" in general should hopefully be enough for Peter to filter
> > them out for master based on what whether "x" references the next
> > major release or not.
> 
> I don't really want to have to update my email filters every
> time we do a release, though, and so "for-X.Y" doesn't work because
> when we are in the runup to release pull requests targeting
> master tend to be marked that way.

What about just for-stable, for-stable-2.7, for-ppc-2.8, etc.?
Basically just adopt the for-* prefix for these sorts of pulls,
but reserve the for-x.y prefix for master, so that anything
that doesn't match for-\d\.\d can get filtered out based on
that single rule?

> 
> Maybe just having not-for-master pull requests say "not for master"
> in the cover letter somewhere ?

I tend to treat PULLs cc'd for stable as just having individual patches
marked for stable, so it's a bit easier to miss if it's not something
obvious like a subject line tag. 

It also kind of leaves it as an exercise for the reader what branch
other than master is actually the intended target for stuff like
sub-maintainer pulls (where there might actually be a bit more
automation).

We could do both though: use some ad-hoc way to tag for a particular
sub-maintainer tree/stable branch, as well as an explicit "not for
master" in the cover letter ensure it doesn't go into master. It's a bit
more redundant, but flexible in that people can use whatever tagging
format they want for a particular tree.

> 
> thanks
> -- PMM
> 

Re: [Qemu-devel] [Qemu-stable] [Qemu-ppc] [PULL 0/4] ppc patches for qemu-2.7 stable branch

[Peter Maydell]

On 17 October 2016 at 19:13, Michael Roth <mdroth@linux.vnet.ibm.com> wrote:
> We could do both though: use some ad-hoc way to tag for a particular
> sub-maintainer tree/stable branch, as well as an explicit "not for
> master" in the cover letter ensure it doesn't go into master. It's a bit
> more redundant, but flexible in that people can use whatever tagging
> format they want for a particular tree.

Yes, that would be my preference. Gmail's filtering is not
very good, and it doesn't seem to be able to support
multiple or complex matches on the subject line, but
it can deal with "doesn't include foo in body".
People who actively want to look for stuff not to go
into master can filter it however they like.

thanks
-- PMM

Re: [Qemu-devel] [Qemu-stable] [Qemu-ppc] [PULL 0/4] ppc patches for qemu-2.7 stable branch

[Michael Roth]

Quoting Peter Maydell (2016-10-17 13:45:21)
> On 17 October 2016 at 19:13, Michael Roth <mdroth@linux.vnet.ibm.com> wrote:
> > We could do both though: use some ad-hoc way to tag for a particular
> > sub-maintainer tree/stable branch, as well as an explicit "not for
> > master" in the cover letter ensure it doesn't go into master. It's a bit
> > more redundant, but flexible in that people can use whatever tagging
> > format they want for a particular tree.
> 
> Yes, that would be my preference. Gmail's filtering is not
> very good, and it doesn't seem to be able to support
> multiple or complex matches on the subject line, but
> it can deal with "doesn't include foo in body".
> People who actively want to look for stuff not to go
> into master can filter it however they like.

Sounds good to me. For my part I think "for-2.7.1" etc. would be
prefereable. No need to resend this patchset though.

I suppose MAINTAINERS would be the best place to document something
like this?

> 
> thanks
> -- PMM
> 

Re: [Qemu-devel] [Qemu-stable] [Qemu-ppc] [PULL 0/4] ppc patches for qemu-2.7 stable branch

[Peter Maydell]

On 17 October 2016 at 22:24, Michael Roth <mdroth@linux.vnet.ibm.com> wrote:
> Quoting Peter Maydell (2016-10-17 13:45:21)
>> On 17 October 2016 at 19:13, Michael Roth <mdroth@linux.vnet.ibm.com> wrote:
>> > We could do both though: use some ad-hoc way to tag for a particular
>> > sub-maintainer tree/stable branch, as well as an explicit "not for
>> > master" in the cover letter ensure it doesn't go into master. It's a bit
>> > more redundant, but flexible in that people can use whatever tagging
>> > format they want for a particular tree.
>>
>> Yes, that would be my preference. Gmail's filtering is not
>> very good, and it doesn't seem to be able to support
>> multiple or complex matches on the subject line, but
>> it can deal with "doesn't include foo in body".
>> People who actively want to look for stuff not to go
>> into master can filter it however they like.
>
> Sounds good to me. For my part I think "for-2.7.1" etc. would be
> prefereable. No need to resend this patchset though.
>
> I suppose MAINTAINERS would be the best place to document something
> like this?

We have http://wiki.qemu.org/Contribute/SubmitAPullRequest
and I've added a note to it.

thanks
-- PMM

Re: [Qemu-devel] [Qemu-stable] [Qemu-ppc] [PULL 0/4] ppc patches for qemu-2.7 stable branch

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 1469 bytes --]

On Mon, Oct 17, 2016 at 04:24:31PM -0500, Michael Roth wrote:
> Quoting Peter Maydell (2016-10-17 13:45:21)
> > On 17 October 2016 at 19:13, Michael Roth <mdroth@linux.vnet.ibm.com> wrote:
> > > We could do both though: use some ad-hoc way to tag for a particular
> > > sub-maintainer tree/stable branch, as well as an explicit "not for
> > > master" in the cover letter ensure it doesn't go into master. It's a bit
> > > more redundant, but flexible in that people can use whatever tagging
> > > format they want for a particular tree.
> > 
> > Yes, that would be my preference. Gmail's filtering is not
> > very good, and it doesn't seem to be able to support
> > multiple or complex matches on the subject line, but
> > it can deal with "doesn't include foo in body".
> > People who actively want to look for stuff not to go
> > into master can filter it however they like.
> 
> Sounds good to me. For my part I think "for-2.7.1" etc. would be
> prefereable. No need to resend this patchset though.
> 
> I suppose MAINTAINERS would be the best place to document something
> like this?

So.. regardless of the outcome in general for future stable merges..

Has this batch been merged for 2.7 stable?  Or do I need to resend it
in the new style?

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Qemu-devel] [Qemu-stable] [Qemu-ppc] [PULL 0/4] ppc patches for qemu-2.7 stable branch

[Michael Roth]

Quoting David Gibson (2016-10-24 20:41:29)
> On Mon, Oct 17, 2016 at 04:24:31PM -0500, Michael Roth wrote:
> > Quoting Peter Maydell (2016-10-17 13:45:21)
> > > On 17 October 2016 at 19:13, Michael Roth <mdroth@linux.vnet.ibm.com> wrote:
> > > > We could do both though: use some ad-hoc way to tag for a particular
> > > > sub-maintainer tree/stable branch, as well as an explicit "not for
> > > > master" in the cover letter ensure it doesn't go into master. It's a bit
> > > > more redundant, but flexible in that people can use whatever tagging
> > > > format they want for a particular tree.
> > > 
> > > Yes, that would be my preference. Gmail's filtering is not
> > > very good, and it doesn't seem to be able to support
> > > multiple or complex matches on the subject line, but
> > > it can deal with "doesn't include foo in body".
> > > People who actively want to look for stuff not to go
> > > into master can filter it however they like.
> > 
> > Sounds good to me. For my part I think "for-2.7.1" etc. would be
> > prefereable. No need to resend this patchset though.
> > 
> > I suppose MAINTAINERS would be the best place to document something
> > like this?
> 
> So.. regardless of the outcome in general for future stable merges..
> 
> Has this batch been merged for 2.7 stable?  Or do I need to resend it
> in the new style?

No need to resend. I should have the initial staging tree for 2.7 posted
by Monday and will have this included.

> 
> -- 
> David Gibson                    | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
>                                 | _way_ _around_!
> http://www.ozlabs.org/~dgibson

Re: [Qemu-devel] [Qemu-stable] [Qemu-ppc] [PULL 0/4] ppc patches for qemu-2.7 stable branch

[David Gibson]

[-- Attachment #1: Type: text/plain, Size: 1894 bytes --]

On Tue, Oct 25, 2016 at 06:57:33PM -0500, Michael Roth wrote:
> Quoting David Gibson (2016-10-24 20:41:29)
> > On Mon, Oct 17, 2016 at 04:24:31PM -0500, Michael Roth wrote:
> > > Quoting Peter Maydell (2016-10-17 13:45:21)
> > > > On 17 October 2016 at 19:13, Michael Roth <mdroth@linux.vnet.ibm.com> wrote:
> > > > > We could do both though: use some ad-hoc way to tag for a particular
> > > > > sub-maintainer tree/stable branch, as well as an explicit "not for
> > > > > master" in the cover letter ensure it doesn't go into master. It's a bit
> > > > > more redundant, but flexible in that people can use whatever tagging
> > > > > format they want for a particular tree.
> > > > 
> > > > Yes, that would be my preference. Gmail's filtering is not
> > > > very good, and it doesn't seem to be able to support
> > > > multiple or complex matches on the subject line, but
> > > > it can deal with "doesn't include foo in body".
> > > > People who actively want to look for stuff not to go
> > > > into master can filter it however they like.
> > > 
> > > Sounds good to me. For my part I think "for-2.7.1" etc. would be
> > > prefereable. No need to resend this patchset though.
> > > 
> > > I suppose MAINTAINERS would be the best place to document something
> > > like this?
> > 
> > So.. regardless of the outcome in general for future stable merges..
> > 
> > Has this batch been merged for 2.7 stable?  Or do I need to resend it
> > in the new style?
> 
> No need to resend. I should have the initial staging tree for 2.7 posted
> by Monday and will have this included.

I haven't spotted the 2.7 stable branch so far.  Maybe I don't have
the right remote?

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Qemu-devel] [Qemu-stable] [Qemu-ppc] [PULL 0/4] ppc patches for qemu-2.7 stable branch

[Michael Roth]

Quoting David Gibson (2016-10-31 21:26:39)
> On Tue, Oct 25, 2016 at 06:57:33PM -0500, Michael Roth wrote:
> > Quoting David Gibson (2016-10-24 20:41:29)
> > > On Mon, Oct 17, 2016 at 04:24:31PM -0500, Michael Roth wrote:
> > > > Quoting Peter Maydell (2016-10-17 13:45:21)
> > > > > On 17 October 2016 at 19:13, Michael Roth <mdroth@linux.vnet.ibm.com> wrote:
> > > > > > We could do both though: use some ad-hoc way to tag for a particular
> > > > > > sub-maintainer tree/stable branch, as well as an explicit "not for
> > > > > > master" in the cover letter ensure it doesn't go into master. It's a bit
> > > > > > more redundant, but flexible in that people can use whatever tagging
> > > > > > format they want for a particular tree.
> > > > > 
> > > > > Yes, that would be my preference. Gmail's filtering is not
> > > > > very good, and it doesn't seem to be able to support
> > > > > multiple or complex matches on the subject line, but
> > > > > it can deal with "doesn't include foo in body".
> > > > > People who actively want to look for stuff not to go
> > > > > into master can filter it however they like.
> > > > 
> > > > Sounds good to me. For my part I think "for-2.7.1" etc. would be
> > > > prefereable. No need to resend this patchset though.
> > > > 
> > > > I suppose MAINTAINERS would be the best place to document something
> > > > like this?
> > > 
> > > So.. regardless of the outcome in general for future stable merges..
> > > 
> > > Has this batch been merged for 2.7 stable?  Or do I need to resend it
> > > in the new style?
> > 
> > No need to resend. I should have the initial staging tree for 2.7 posted
> > by Monday and will have this included.
> 
> I haven't spotted the 2.7 stable branch so far.  Maybe I don't have
> the right remote?

Sorry, I was a bit behind getting it posted. I've put up a staging tree
here:

  https://github.com/mdroth/qemu/commits/stable-2.7-staging

I'm tentatively planning on posting the initial tree November 7th, setting
the freeze for November 11th, and the release for the 16th. I saw your
series regarding 2.6<->2.7 CPU migration and had also been hoping to get it
sorted for 2.7.1, so let me know if we should consider tweaking the
dates.

> 
> -- 
> David Gibson                    | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
>                                 | _way_ _around_!
> http://www.ozlabs.org/~dgibson