* [Qemu-devel] [PATCH] linux-headers: update to 3.11
@ 2013-09-03 8:27 Alexey Kardashevskiy
2013-09-03 9:29 ` Peter Maydell
2013-09-12 16:31 ` Paolo Bonzini
0 siblings, 2 replies; 17+ messages in thread
From: Alexey Kardashevskiy @ 2013-09-03 8:27 UTC (permalink / raw)
To: qemu-devel; +Cc: Alexey Kardashevskiy, qemu-trivial, Michael Tokarev
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
I need this update as VFIO on PPC64/pseries got in upstream kernel
and this is required by VFIO-SPAPR bits in QEMU. Others may find this
update useful too :)
---
| 168 ++++++++++++++++++++++++++++++++++++
| 1 +
| 81 +++++++++--------
| 3 +
| 42 ++++++++-
| 3 +
6 files changed, 254 insertions(+), 44 deletions(-)
create mode 100644 linux-headers/asm-arm64/kvm.h
create mode 100644 linux-headers/asm-arm64/kvm_para.h
--git a/linux-headers/asm-arm64/kvm.h b/linux-headers/asm-arm64/kvm.h
new file mode 100644
index 0000000..5031f42
--- /dev/null
+++ b/linux-headers/asm-arm64/kvm.h
@@ -0,0 +1,168 @@
+/*
+ * Copyright (C) 2012,2013 - ARM Ltd
+ * Author: Marc Zyngier <marc.zyngier@arm.com>
+ *
+ * Derived from arch/arm/include/uapi/asm/kvm.h:
+ * Copyright (C) 2012 - Virtual Open Systems and Columbia University
+ * Author: Christoffer Dall <c.dall@virtualopensystems.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#ifndef __ARM_KVM_H__
+#define __ARM_KVM_H__
+
+#define KVM_SPSR_EL1 0
+#define KVM_SPSR_SVC KVM_SPSR_EL1
+#define KVM_SPSR_ABT 1
+#define KVM_SPSR_UND 2
+#define KVM_SPSR_IRQ 3
+#define KVM_SPSR_FIQ 4
+#define KVM_NR_SPSR 5
+
+#ifndef __ASSEMBLY__
+#include <asm/types.h>
+#include <asm/ptrace.h>
+
+#define __KVM_HAVE_GUEST_DEBUG
+#define __KVM_HAVE_IRQ_LINE
+
+#define KVM_REG_SIZE(id) \
+ (1U << (((id) & KVM_REG_SIZE_MASK) >> KVM_REG_SIZE_SHIFT))
+
+struct kvm_regs {
+ struct user_pt_regs regs; /* sp = sp_el0 */
+
+ __u64 sp_el1;
+ __u64 elr_el1;
+
+ __u64 spsr[KVM_NR_SPSR];
+
+ struct user_fpsimd_state fp_regs;
+};
+
+/* Supported Processor Types */
+#define KVM_ARM_TARGET_AEM_V8 0
+#define KVM_ARM_TARGET_FOUNDATION_V8 1
+#define KVM_ARM_TARGET_CORTEX_A57 2
+
+#define KVM_ARM_NUM_TARGETS 3
+
+/* KVM_ARM_SET_DEVICE_ADDR ioctl id encoding */
+#define KVM_ARM_DEVICE_TYPE_SHIFT 0
+#define KVM_ARM_DEVICE_TYPE_MASK (0xffff << KVM_ARM_DEVICE_TYPE_SHIFT)
+#define KVM_ARM_DEVICE_ID_SHIFT 16
+#define KVM_ARM_DEVICE_ID_MASK (0xffff << KVM_ARM_DEVICE_ID_SHIFT)
+
+/* Supported device IDs */
+#define KVM_ARM_DEVICE_VGIC_V2 0
+
+/* Supported VGIC address types */
+#define KVM_VGIC_V2_ADDR_TYPE_DIST 0
+#define KVM_VGIC_V2_ADDR_TYPE_CPU 1
+
+#define KVM_VGIC_V2_DIST_SIZE 0x1000
+#define KVM_VGIC_V2_CPU_SIZE 0x2000
+
+#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 */
+
+struct kvm_vcpu_init {
+ __u32 target;
+ __u32 features[7];
+};
+
+struct kvm_sregs {
+};
+
+struct kvm_fpu {
+};
+
+struct kvm_guest_debug_arch {
+};
+
+struct kvm_debug_exit_arch {
+};
+
+struct kvm_sync_regs {
+};
+
+struct kvm_arch_memory_slot {
+};
+
+/* If you need to interpret the index values, here is the key: */
+#define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000
+#define KVM_REG_ARM_COPROC_SHIFT 16
+
+/* Normal registers are mapped as coprocessor 16. */
+#define KVM_REG_ARM_CORE (0x0010 << KVM_REG_ARM_COPROC_SHIFT)
+#define KVM_REG_ARM_CORE_REG(name) (offsetof(struct kvm_regs, name) / sizeof(__u32))
+
+/* Some registers need more space to represent values. */
+#define KVM_REG_ARM_DEMUX (0x0011 << KVM_REG_ARM_COPROC_SHIFT)
+#define KVM_REG_ARM_DEMUX_ID_MASK 0x000000000000FF00
+#define KVM_REG_ARM_DEMUX_ID_SHIFT 8
+#define KVM_REG_ARM_DEMUX_ID_CCSIDR (0x00 << KVM_REG_ARM_DEMUX_ID_SHIFT)
+#define KVM_REG_ARM_DEMUX_VAL_MASK 0x00000000000000FF
+#define KVM_REG_ARM_DEMUX_VAL_SHIFT 0
+
+/* AArch64 system registers */
+#define KVM_REG_ARM64_SYSREG (0x0013 << KVM_REG_ARM_COPROC_SHIFT)
+#define KVM_REG_ARM64_SYSREG_OP0_MASK 0x000000000000c000
+#define KVM_REG_ARM64_SYSREG_OP0_SHIFT 14
+#define KVM_REG_ARM64_SYSREG_OP1_MASK 0x0000000000003800
+#define KVM_REG_ARM64_SYSREG_OP1_SHIFT 11
+#define KVM_REG_ARM64_SYSREG_CRN_MASK 0x0000000000000780
+#define KVM_REG_ARM64_SYSREG_CRN_SHIFT 7
+#define KVM_REG_ARM64_SYSREG_CRM_MASK 0x0000000000000078
+#define KVM_REG_ARM64_SYSREG_CRM_SHIFT 3
+#define KVM_REG_ARM64_SYSREG_OP2_MASK 0x0000000000000007
+#define KVM_REG_ARM64_SYSREG_OP2_SHIFT 0
+
+/* KVM_IRQ_LINE irq field index values */
+#define KVM_ARM_IRQ_TYPE_SHIFT 24
+#define KVM_ARM_IRQ_TYPE_MASK 0xff
+#define KVM_ARM_IRQ_VCPU_SHIFT 16
+#define KVM_ARM_IRQ_VCPU_MASK 0xff
+#define KVM_ARM_IRQ_NUM_SHIFT 0
+#define KVM_ARM_IRQ_NUM_MASK 0xffff
+
+/* irq_type field */
+#define KVM_ARM_IRQ_TYPE_CPU 0
+#define KVM_ARM_IRQ_TYPE_SPI 1
+#define KVM_ARM_IRQ_TYPE_PPI 2
+
+/* out-of-kernel GIC cpu interrupt injection irq_number field */
+#define KVM_ARM_IRQ_CPU_IRQ 0
+#define KVM_ARM_IRQ_CPU_FIQ 1
+
+/* Highest supported SPI, from VGIC_NR_IRQS */
+#define KVM_ARM_IRQ_GIC_MAX 127
+
+/* PSCI interface */
+#define KVM_PSCI_FN_BASE 0x95c1ba5e
+#define KVM_PSCI_FN(n) (KVM_PSCI_FN_BASE + (n))
+
+#define KVM_PSCI_FN_CPU_SUSPEND KVM_PSCI_FN(0)
+#define KVM_PSCI_FN_CPU_OFF KVM_PSCI_FN(1)
+#define KVM_PSCI_FN_CPU_ON KVM_PSCI_FN(2)
+#define KVM_PSCI_FN_MIGRATE KVM_PSCI_FN(3)
+
+#define KVM_PSCI_RET_SUCCESS 0
+#define KVM_PSCI_RET_NI ((unsigned long)-1)
+#define KVM_PSCI_RET_INVAL ((unsigned long)-2)
+#define KVM_PSCI_RET_DENIED ((unsigned long)-3)
+
+#endif
+
+#endif /* __ARM_KVM_H__ */
--git a/linux-headers/asm-arm64/kvm_para.h b/linux-headers/asm-arm64/kvm_para.h
new file mode 100644
index 0000000..14fab8f
--- /dev/null
+++ b/linux-headers/asm-arm64/kvm_para.h
@@ -0,0 +1 @@
+#include <asm-generic/kvm_para.h>
--git a/linux-headers/asm-mips/kvm.h b/linux-headers/asm-mips/kvm.h
index 3f424f5..f09ff5a 100644
--- a/linux-headers/asm-mips/kvm.h
+++ b/linux-headers/asm-mips/kvm.h
@@ -58,56 +58,53 @@ struct kvm_fpu {
* bits[2..0] - Register 'sel' index.
* bits[7..3] - Register 'rd' index.
* bits[15..8] - Must be zero.
- * bits[63..16] - 1 -> CP0 registers.
+ * bits[31..16] - 1 -> CP0 registers.
+ * bits[51..32] - Must be zero.
+ * bits[63..52] - As per linux/kvm.h
*
* Other sets registers may be added in the future. Each set would
- * have its own identifier in bits[63..16].
- *
- * The addr field of struct kvm_one_reg must point to an aligned
- * 64-bit wide location. For registers that are narrower than
- * 64-bits, the value is stored in the low order bits of the location,
- * and sign extended to 64-bits.
+ * have its own identifier in bits[31..16].
*
* The registers defined in struct kvm_regs are also accessible, the
* id values for these are below.
*/
-#define KVM_REG_MIPS_R0 0
-#define KVM_REG_MIPS_R1 1
-#define KVM_REG_MIPS_R2 2
-#define KVM_REG_MIPS_R3 3
-#define KVM_REG_MIPS_R4 4
-#define KVM_REG_MIPS_R5 5
-#define KVM_REG_MIPS_R6 6
-#define KVM_REG_MIPS_R7 7
-#define KVM_REG_MIPS_R8 8
-#define KVM_REG_MIPS_R9 9
-#define KVM_REG_MIPS_R10 10
-#define KVM_REG_MIPS_R11 11
-#define KVM_REG_MIPS_R12 12
-#define KVM_REG_MIPS_R13 13
-#define KVM_REG_MIPS_R14 14
-#define KVM_REG_MIPS_R15 15
-#define KVM_REG_MIPS_R16 16
-#define KVM_REG_MIPS_R17 17
-#define KVM_REG_MIPS_R18 18
-#define KVM_REG_MIPS_R19 19
-#define KVM_REG_MIPS_R20 20
-#define KVM_REG_MIPS_R21 21
-#define KVM_REG_MIPS_R22 22
-#define KVM_REG_MIPS_R23 23
-#define KVM_REG_MIPS_R24 24
-#define KVM_REG_MIPS_R25 25
-#define KVM_REG_MIPS_R26 26
-#define KVM_REG_MIPS_R27 27
-#define KVM_REG_MIPS_R28 28
-#define KVM_REG_MIPS_R29 29
-#define KVM_REG_MIPS_R30 30
-#define KVM_REG_MIPS_R31 31
+#define KVM_REG_MIPS_R0 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 0)
+#define KVM_REG_MIPS_R1 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 1)
+#define KVM_REG_MIPS_R2 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 2)
+#define KVM_REG_MIPS_R3 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 3)
+#define KVM_REG_MIPS_R4 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 4)
+#define KVM_REG_MIPS_R5 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 5)
+#define KVM_REG_MIPS_R6 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 6)
+#define KVM_REG_MIPS_R7 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 7)
+#define KVM_REG_MIPS_R8 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 8)
+#define KVM_REG_MIPS_R9 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 9)
+#define KVM_REG_MIPS_R10 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 10)
+#define KVM_REG_MIPS_R11 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 11)
+#define KVM_REG_MIPS_R12 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 12)
+#define KVM_REG_MIPS_R13 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 13)
+#define KVM_REG_MIPS_R14 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 14)
+#define KVM_REG_MIPS_R15 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 15)
+#define KVM_REG_MIPS_R16 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 16)
+#define KVM_REG_MIPS_R17 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 17)
+#define KVM_REG_MIPS_R18 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 18)
+#define KVM_REG_MIPS_R19 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 19)
+#define KVM_REG_MIPS_R20 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 20)
+#define KVM_REG_MIPS_R21 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 21)
+#define KVM_REG_MIPS_R22 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 22)
+#define KVM_REG_MIPS_R23 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 23)
+#define KVM_REG_MIPS_R24 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 24)
+#define KVM_REG_MIPS_R25 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 25)
+#define KVM_REG_MIPS_R26 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 26)
+#define KVM_REG_MIPS_R27 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 27)
+#define KVM_REG_MIPS_R28 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 28)
+#define KVM_REG_MIPS_R29 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 29)
+#define KVM_REG_MIPS_R30 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 30)
+#define KVM_REG_MIPS_R31 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 31)
-#define KVM_REG_MIPS_HI 32
-#define KVM_REG_MIPS_LO 33
-#define KVM_REG_MIPS_PC 34
+#define KVM_REG_MIPS_HI (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 32)
+#define KVM_REG_MIPS_LO (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 33)
+#define KVM_REG_MIPS_PC (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 34)
/*
* KVM MIPS specific structures and definitions
--git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
index c614070..56fce1c 100644
--- a/linux-headers/linux/kvm.h
+++ b/linux-headers/linux/kvm.h
@@ -666,6 +666,7 @@ struct kvm_ppc_smmu_info {
#define KVM_CAP_IRQ_MPIC 90
#define KVM_CAP_PPC_RTAS 91
#define KVM_CAP_IRQ_XICS 92
+#define KVM_CAP_ARM_EL1_32BIT 93
#ifdef KVM_CAP_IRQ_ROUTING
@@ -783,6 +784,8 @@ struct kvm_dirty_tlb {
#define KVM_REG_IA64 0x3000000000000000ULL
#define KVM_REG_ARM 0x4000000000000000ULL
#define KVM_REG_S390 0x5000000000000000ULL
+#define KVM_REG_ARM64 0x6000000000000000ULL
+#define KVM_REG_MIPS 0x7000000000000000ULL
#define KVM_REG_SIZE_SHIFT 52
#define KVM_REG_SIZE_MASK 0x00f0000000000000ULL
--git a/linux-headers/linux/vfio.h b/linux-headers/linux/vfio.h
index 7ec1864..b42b9ab 100644
--- a/linux-headers/linux/vfio.h
+++ b/linux-headers/linux/vfio.h
@@ -22,6 +22,7 @@
/* Extensions */
#define VFIO_TYPE1_IOMMU 1
+#define VFIO_SPAPR_TCE_IOMMU 2
/*
* The IOCTL interface is designed for extensibility by embedding the
@@ -361,10 +362,14 @@ struct vfio_iommu_type1_dma_map {
#define VFIO_IOMMU_MAP_DMA _IO(VFIO_TYPE, VFIO_BASE + 13)
/**
- * VFIO_IOMMU_UNMAP_DMA - _IOW(VFIO_TYPE, VFIO_BASE + 14, struct vfio_dma_unmap)
+ * VFIO_IOMMU_UNMAP_DMA - _IOWR(VFIO_TYPE, VFIO_BASE + 14,
+ * struct vfio_dma_unmap)
*
* Unmap IO virtual addresses using the provided struct vfio_dma_unmap.
- * Caller sets argsz.
+ * Caller sets argsz. The actual unmapped size is returned in the size
+ * field. No guarantee is made to the user that arbitrary unmaps of iova
+ * or size different from those used in the original mapping call will
+ * succeed.
*/
struct vfio_iommu_type1_dma_unmap {
__u32 argsz;
@@ -375,4 +380,37 @@ struct vfio_iommu_type1_dma_unmap {
#define VFIO_IOMMU_UNMAP_DMA _IO(VFIO_TYPE, VFIO_BASE + 14)
+/*
+ * IOCTLs to enable/disable IOMMU container usage.
+ * No parameters are supported.
+ */
+#define VFIO_IOMMU_ENABLE _IO(VFIO_TYPE, VFIO_BASE + 15)
+#define VFIO_IOMMU_DISABLE _IO(VFIO_TYPE, VFIO_BASE + 16)
+
+/* -------- Additional API for SPAPR TCE (Server POWERPC) IOMMU -------- */
+
+/*
+ * The SPAPR TCE info struct provides the information about the PCI bus
+ * address ranges available for DMA, these values are programmed into
+ * the hardware so the guest has to know that information.
+ *
+ * The DMA 32 bit window start is an absolute PCI bus address.
+ * The IOVA address passed via map/unmap ioctls are absolute PCI bus
+ * addresses too so the window works as a filter rather than an offset
+ * for IOVA addresses.
+ *
+ * A flag will need to be added if other page sizes are supported,
+ * so as defined here, it is always 4k.
+ */
+struct vfio_iommu_spapr_tce_info {
+ __u32 argsz;
+ __u32 flags; /* reserved for future use */
+ __u32 dma32_window_start; /* 32 bit window start (bytes) */
+ __u32 dma32_window_size; /* 32 bit window size (bytes) */
+};
+
+#define VFIO_IOMMU_SPAPR_TCE_GET_INFO _IO(VFIO_TYPE, VFIO_BASE + 12)
+
+/* ***************************************************************** */
+
#endif /* VFIO_H */
--git a/linux-headers/linux/virtio_config.h b/linux-headers/linux/virtio_config.h
index 4f51d8f..75dc20b 100644
--- a/linux-headers/linux/virtio_config.h
+++ b/linux-headers/linux/virtio_config.h
@@ -51,4 +51,7 @@
* suppressed them? */
#define VIRTIO_F_NOTIFY_ON_EMPTY 24
+/* Can the device handle any descriptor layout? */
+#define VIRTIO_F_ANY_LAYOUT 27
+
#endif /* _LINUX_VIRTIO_CONFIG_H */
--
1.8.4.rc4
^ permalink raw reply related [flat|nested] 17+ messages in thread* Re: [Qemu-devel] [PATCH] linux-headers: update to 3.11
2013-09-03 8:27 [Qemu-devel] [PATCH] linux-headers: update to 3.11 Alexey Kardashevskiy
@ 2013-09-03 9:29 ` Peter Maydell
2013-09-03 9:32 ` Alexey Kardashevskiy
2013-09-12 16:31 ` Paolo Bonzini
1 sibling, 1 reply; 17+ messages in thread
From: Peter Maydell @ 2013-09-03 9:29 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: kvm-devel, Gleb Natapov, QEMU Trivial, Michael Tokarev,
QEMU Developers, Paolo Bonzini
On 3 September 2013 09:27, Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
>
> I need this update as VFIO on PPC64/pseries got in upstream kernel
> and this is required by VFIO-SPAPR bits in QEMU. Others may find this
> update useful too :)
> ---
> linux-headers/asm-arm64/kvm.h | 168 ++++++++++++++++++++++++++++++++++++
> linux-headers/asm-arm64/kvm_para.h | 1 +
> linux-headers/asm-mips/kvm.h | 81 +++++++++--------
> linux-headers/linux/kvm.h | 3 +
> linux-headers/linux/vfio.h | 42 ++++++++-
> linux-headers/linux/virtio_config.h | 3 +
> 6 files changed, 254 insertions(+), 44 deletions(-)
> create mode 100644 linux-headers/asm-arm64/kvm.h
> create mode 100644 linux-headers/asm-arm64/kvm_para.h
I think this should go in via the KVM tree, not trivial.
thanks
-- PMM
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Qemu-devel] [PATCH] linux-headers: update to 3.11
2013-09-03 9:29 ` Peter Maydell
@ 2013-09-03 9:32 ` Alexey Kardashevskiy
2013-09-03 10:42 ` Jan Kiszka
0 siblings, 1 reply; 17+ messages in thread
From: Alexey Kardashevskiy @ 2013-09-03 9:32 UTC (permalink / raw)
To: Peter Maydell
Cc: kvm-devel, Gleb Natapov, QEMU Trivial, Michael Tokarev,
QEMU Developers, Paolo Bonzini
On 09/03/2013 07:29 PM, Peter Maydell wrote:
> On 3 September 2013 09:27, Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>> ---
>>
>> I need this update as VFIO on PPC64/pseries got in upstream kernel
>> and this is required by VFIO-SPAPR bits in QEMU. Others may find this
>> update useful too :)
>> ---
>> linux-headers/asm-arm64/kvm.h | 168 ++++++++++++++++++++++++++++++++++++
>> linux-headers/asm-arm64/kvm_para.h | 1 +
>> linux-headers/asm-mips/kvm.h | 81 +++++++++--------
>> linux-headers/linux/kvm.h | 3 +
>> linux-headers/linux/vfio.h | 42 ++++++++-
>> linux-headers/linux/virtio_config.h | 3 +
>> 6 files changed, 254 insertions(+), 44 deletions(-)
>> create mode 100644 linux-headers/asm-arm64/kvm.h
>> create mode 100644 linux-headers/asm-arm64/kvm_para.h
>
> I think this should go in via the KVM tree, not trivial.
I do not mind, it just went through the trivial tree last time, that's it.
--
Alexey
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Qemu-devel] [PATCH] linux-headers: update to 3.11
2013-09-03 9:32 ` Alexey Kardashevskiy
@ 2013-09-03 10:42 ` Jan Kiszka
2013-09-03 15:28 ` Alexey Kardashevskiy
0 siblings, 1 reply; 17+ messages in thread
From: Jan Kiszka @ 2013-09-03 10:42 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: Peter Maydell, kvm-devel, Gleb Natapov, QEMU Trivial,
Michael Tokarev, QEMU Developers, Paolo Bonzini
On 2013-09-03 11:32, Alexey Kardashevskiy wrote:
> On 09/03/2013 07:29 PM, Peter Maydell wrote:
>> On 3 September 2013 09:27, Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>>> ---
>>>
>>> I need this update as VFIO on PPC64/pseries got in upstream kernel
>>> and this is required by VFIO-SPAPR bits in QEMU. Others may find this
>>> update useful too :)
>>> ---
>>> linux-headers/asm-arm64/kvm.h | 168 ++++++++++++++++++++++++++++++++++++
>>> linux-headers/asm-arm64/kvm_para.h | 1 +
>>> linux-headers/asm-mips/kvm.h | 81 +++++++++--------
>>> linux-headers/linux/kvm.h | 3 +
>>> linux-headers/linux/vfio.h | 42 ++++++++-
>>> linux-headers/linux/virtio_config.h | 3 +
>>> 6 files changed, 254 insertions(+), 44 deletions(-)
>>> create mode 100644 linux-headers/asm-arm64/kvm.h
>>> create mode 100644 linux-headers/asm-arm64/kvm_para.h
>>
>> I think this should go in via the KVM tree, not trivial.
>
> I do not mind, it just went through the trivial tree last time, that's it.
This shouldn't be routed through trivial in general as things broke too
often in this area.
Jan
--
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Qemu-devel] [PATCH] linux-headers: update to 3.11
2013-09-03 10:42 ` Jan Kiszka
@ 2013-09-03 15:28 ` Alexey Kardashevskiy
2013-09-03 15:34 ` Peter Maydell
2013-09-03 15:35 ` Paolo Bonzini
0 siblings, 2 replies; 17+ messages in thread
From: Alexey Kardashevskiy @ 2013-09-03 15:28 UTC (permalink / raw)
To: Jan Kiszka
Cc: Peter Maydell, kvm-devel, Gleb Natapov, QEMU Trivial,
Michael Tokarev, QEMU Developers, Paolo Bonzini
On 09/03/2013 08:42 PM, Jan Kiszka wrote:
> On 2013-09-03 11:32, Alexey Kardashevskiy wrote:
>> On 09/03/2013 07:29 PM, Peter Maydell wrote:
>>> On 3 September 2013 09:27, Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>>>> ---
>>>>
>>>> I need this update as VFIO on PPC64/pseries got in upstream kernel
>>>> and this is required by VFIO-SPAPR bits in QEMU. Others may find this
>>>> update useful too :)
>>>> ---
>>>> linux-headers/asm-arm64/kvm.h | 168 ++++++++++++++++++++++++++++++++++++
>>>> linux-headers/asm-arm64/kvm_para.h | 1 +
>>>> linux-headers/asm-mips/kvm.h | 81 +++++++++--------
>>>> linux-headers/linux/kvm.h | 3 +
>>>> linux-headers/linux/vfio.h | 42 ++++++++-
>>>> linux-headers/linux/virtio_config.h | 3 +
>>>> 6 files changed, 254 insertions(+), 44 deletions(-)
>>>> create mode 100644 linux-headers/asm-arm64/kvm.h
>>>> create mode 100644 linux-headers/asm-arm64/kvm_para.h
>>>
>>> I think this should go in via the KVM tree, not trivial.
>>
>> I do not mind, it just went through the trivial tree last time, that's it.
>
> This shouldn't be routed through trivial in general as things broke too
> often in this area.
Sorry for my ignorance, but this is The Kernel, it is already there, broken
or not, even if it is broken, qemu cannot stay isolated, no?
This is a mechanical change, no more.
--
Alexey
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Qemu-devel] [PATCH] linux-headers: update to 3.11
2013-09-03 15:28 ` Alexey Kardashevskiy
@ 2013-09-03 15:34 ` Peter Maydell
2013-09-03 15:47 ` Alexey Kardashevskiy
2013-09-03 15:35 ` Paolo Bonzini
1 sibling, 1 reply; 17+ messages in thread
From: Peter Maydell @ 2013-09-03 15:34 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: kvm-devel, Gleb Natapov, QEMU Trivial, Jan Kiszka,
Michael Tokarev, QEMU Developers, Paolo Bonzini
On 3 September 2013 16:28, Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> On 09/03/2013 08:42 PM, Jan Kiszka wrote:
>> This shouldn't be routed through trivial in general as things broke too
>> often in this area.
>
>
> Sorry for my ignorance, but this is The Kernel, it is already there, broken
> or not, even if it is broken, qemu cannot stay isolated, no?
> This is a mechanical change, no more.
The classic way for things to break is that a header
update accidentally reverts something (because a
previous update was from kvm-next and this one is
from mainline, for example). Accidental updates against
a kernel which is neither kvm-next nor mainline are
the other common "broken" version of a header update
patch.
-- PMM
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Qemu-devel] [PATCH] linux-headers: update to 3.11
2013-09-03 15:34 ` Peter Maydell
@ 2013-09-03 15:47 ` Alexey Kardashevskiy
2013-09-03 15:55 ` Peter Maydell
2013-09-03 15:58 ` Alex Williamson
0 siblings, 2 replies; 17+ messages in thread
From: Alexey Kardashevskiy @ 2013-09-03 15:47 UTC (permalink / raw)
To: Peter Maydell
Cc: kvm-devel, Gleb Natapov, QEMU Trivial, Jan Kiszka,
Michael Tokarev, QEMU Developers, Paolo Bonzini
On 09/04/2013 01:34 AM, Peter Maydell wrote:
> On 3 September 2013 16:28, Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>> On 09/03/2013 08:42 PM, Jan Kiszka wrote:
>>> This shouldn't be routed through trivial in general as things broke too
>>> often in this area.
>>
>>
>> Sorry for my ignorance, but this is The Kernel, it is already there, broken
>> or not, even if it is broken, qemu cannot stay isolated, no?
>> This is a mechanical change, no more.
>
> The classic way for things to break is that a header
> update accidentally reverts something (because a
> previous update was from kvm-next and this one is
> from mainline, for example). Accidental updates against
> a kernel which is neither kvm-next nor mainline are
> the other common "broken" version of a header update
> patch.
I can understand that but this update is a mainline kernel update and it is
not an accidental one but very specific :-/
--
Alexey
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Qemu-devel] [PATCH] linux-headers: update to 3.11
2013-09-03 15:47 ` Alexey Kardashevskiy
@ 2013-09-03 15:55 ` Peter Maydell
2013-09-03 15:58 ` Alex Williamson
1 sibling, 0 replies; 17+ messages in thread
From: Peter Maydell @ 2013-09-03 15:55 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: kvm-devel, Gleb Natapov, QEMU Trivial, Jan Kiszka,
Michael Tokarev, QEMU Developers, Paolo Bonzini
On 3 September 2013 16:47, Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> On 09/04/2013 01:34 AM, Peter Maydell wrote:
>> The classic way for things to break is that a header
>> update accidentally reverts something (because a
>> previous update was from kvm-next and this one is
>> from mainline, for example). Accidental updates against
>> a kernel which is neither kvm-next nor mainline are
>> the other common "broken" version of a header update
>> patch.
>
> I can understand that but this update is a mainline kernel
> update and it is not an accidental one but very specific :-/
Nobody has been saying there is a problem with this
patch. We're just saying it should go via the kvm
tree rather than the trivial patches tree.
-- PMM
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Qemu-devel] [PATCH] linux-headers: update to 3.11
2013-09-03 15:47 ` Alexey Kardashevskiy
2013-09-03 15:55 ` Peter Maydell
@ 2013-09-03 15:58 ` Alex Williamson
2013-09-03 16:03 ` Peter Maydell
1 sibling, 1 reply; 17+ messages in thread
From: Alex Williamson @ 2013-09-03 15:58 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: Peter Maydell, kvm-devel, Gleb Natapov, QEMU Trivial, Jan Kiszka,
Michael Tokarev, QEMU Developers, Paolo Bonzini
On Wed, 2013-09-04 at 01:47 +1000, Alexey Kardashevskiy wrote:
> On 09/04/2013 01:34 AM, Peter Maydell wrote:
> > On 3 September 2013 16:28, Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
> >> On 09/03/2013 08:42 PM, Jan Kiszka wrote:
> >>> This shouldn't be routed through trivial in general as things broke too
> >>> often in this area.
> >>
> >>
> >> Sorry for my ignorance, but this is The Kernel, it is already there, broken
> >> or not, even if it is broken, qemu cannot stay isolated, no?
> >> This is a mechanical change, no more.
> >
> > The classic way for things to break is that a header
> > update accidentally reverts something (because a
> > previous update was from kvm-next and this one is
> > from mainline, for example). Accidental updates against
> > a kernel which is neither kvm-next nor mainline are
> > the other common "broken" version of a header update
> > patch.
>
> I can understand that but this update is a mainline kernel update and it is
> not an accidental one but very specific :-/
I was under the impression that we were only ever updating linux-headers
from mainline, never from kvm-next. Therefore any mainline tag should
be a reasonable re-base target. Thanks,
Alex
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Qemu-devel] [PATCH] linux-headers: update to 3.11
2013-09-03 15:58 ` Alex Williamson
@ 2013-09-03 16:03 ` Peter Maydell
2013-09-03 16:12 ` Alex Williamson
0 siblings, 1 reply; 17+ messages in thread
From: Peter Maydell @ 2013-09-03 16:03 UTC (permalink / raw)
To: Alex Williamson
Cc: kvm-devel, Gleb Natapov, Alexey Kardashevskiy, Jan Kiszka,
Michael Tokarev, QEMU Developers, QEMU Trivial, Paolo Bonzini
On 3 September 2013 16:58, Alex Williamson <alex.williamson@redhat.com> wrote:
> I was under the impression that we were only ever updating linux-headers
> from mainline, never from kvm-next.
Looking at the git history, it's variable. Four of the
last 10 updates were from somewhere other than mainline.
In any case this is the kind of policy decision that
means updates should go via the QEMU KVM maintainers :-)
-- PMM
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Qemu-devel] [PATCH] linux-headers: update to 3.11
2013-09-03 16:03 ` Peter Maydell
@ 2013-09-03 16:12 ` Alex Williamson
0 siblings, 0 replies; 17+ messages in thread
From: Alex Williamson @ 2013-09-03 16:12 UTC (permalink / raw)
To: Peter Maydell
Cc: kvm-devel, Gleb Natapov, Alexey Kardashevskiy, Jan Kiszka,
Michael Tokarev, QEMU Developers, QEMU Trivial, Paolo Bonzini
On Tue, 2013-09-03 at 17:03 +0100, Peter Maydell wrote:
> On 3 September 2013 16:58, Alex Williamson <alex.williamson@redhat.com> wrote:
> > I was under the impression that we were only ever updating linux-headers
> > from mainline, never from kvm-next.
>
> Looking at the git history, it's variable. Four of the
> last 10 updates were from somewhere other than mainline.
> In any case this is the kind of policy decision that
> means updates should go via the QEMU KVM maintainers :-)
Seems like every update except ppc has come from mainline. Personally,
I don't think it makes sense anymore. QEMU has scope beyond KVM and it
makes about as much sense to snapshot kvm.git as it does to snapshot my
vfio next branch or Michael's virtio queue. If we only pull from
mainline we never have to worry about regressing something that isn't
actually upstream yet. Thanks,
Alex
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Qemu-devel] [PATCH] linux-headers: update to 3.11
2013-09-03 15:28 ` Alexey Kardashevskiy
2013-09-03 15:34 ` Peter Maydell
@ 2013-09-03 15:35 ` Paolo Bonzini
2013-09-05 3:16 ` Alexey Kardashevskiy
1 sibling, 1 reply; 17+ messages in thread
From: Paolo Bonzini @ 2013-09-03 15:35 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: Peter Maydell, kvm-devel, Gleb Natapov, QEMU Trivial, Jan Kiszka,
Michael Tokarev, QEMU Developers
Il 03/09/2013 17:28, Alexey Kardashevskiy ha scritto:
> On 09/03/2013 08:42 PM, Jan Kiszka wrote:
>> On 2013-09-03 11:32, Alexey Kardashevskiy wrote:
>>> On 09/03/2013 07:29 PM, Peter Maydell wrote:
>>>> On 3 September 2013 09:27, Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>>>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>>>>> ---
>>>>>
>>>>> I need this update as VFIO on PPC64/pseries got in upstream kernel
>>>>> and this is required by VFIO-SPAPR bits in QEMU. Others may find this
>>>>> update useful too :)
>>>>> ---
>>>>> linux-headers/asm-arm64/kvm.h | 168 ++++++++++++++++++++++++++++++++++++
>>>>> linux-headers/asm-arm64/kvm_para.h | 1 +
>>>>> linux-headers/asm-mips/kvm.h | 81 +++++++++--------
>>>>> linux-headers/linux/kvm.h | 3 +
>>>>> linux-headers/linux/vfio.h | 42 ++++++++-
>>>>> linux-headers/linux/virtio_config.h | 3 +
>>>>> 6 files changed, 254 insertions(+), 44 deletions(-)
>>>>> create mode 100644 linux-headers/asm-arm64/kvm.h
>>>>> create mode 100644 linux-headers/asm-arm64/kvm_para.h
>>>>
>>>> I think this should go in via the KVM tree, not trivial.
>>>
>>> I do not mind, it just went through the trivial tree last time, that's it.
>>
>> This shouldn't be routed through trivial in general as things broke too
>> often in this area.
>
> Sorry for my ignorance, but this is The Kernel, it is already there, broken
> or not, even if it is broken, qemu cannot stay isolated, no?
> This is a mechanical change, no more.
It's a matter of keeping things bisectable. If we can detect a
breakage, we can first work around it, and then apply the header update.
And if we don't detect it, maintainers usually send pull requests when
they have time to work on breakage caused by their patches.
Paolo
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Qemu-devel] [PATCH] linux-headers: update to 3.11
2013-09-03 15:35 ` Paolo Bonzini
@ 2013-09-05 3:16 ` Alexey Kardashevskiy
2013-09-05 6:07 ` Paolo Bonzini
0 siblings, 1 reply; 17+ messages in thread
From: Alexey Kardashevskiy @ 2013-09-05 3:16 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Peter Maydell, kvm-devel, Gleb Natapov, QEMU Trivial, Jan Kiszka,
Michael Tokarev, QEMU Developers
On 09/04/2013 01:35 AM, Paolo Bonzini wrote:
> Il 03/09/2013 17:28, Alexey Kardashevskiy ha scritto:
>> On 09/03/2013 08:42 PM, Jan Kiszka wrote:
>>> On 2013-09-03 11:32, Alexey Kardashevskiy wrote:
>>>> On 09/03/2013 07:29 PM, Peter Maydell wrote:
>>>>> On 3 September 2013 09:27, Alexey Kardashevskiy <aik@ozlabs.ru> wrote:
>>>>>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>>>>>> ---
>>>>>>
>>>>>> I need this update as VFIO on PPC64/pseries got in upstream kernel
>>>>>> and this is required by VFIO-SPAPR bits in QEMU. Others may find this
>>>>>> update useful too :)
>>>>>> ---
>>>>>> linux-headers/asm-arm64/kvm.h | 168 ++++++++++++++++++++++++++++++++++++
>>>>>> linux-headers/asm-arm64/kvm_para.h | 1 +
>>>>>> linux-headers/asm-mips/kvm.h | 81 +++++++++--------
>>>>>> linux-headers/linux/kvm.h | 3 +
>>>>>> linux-headers/linux/vfio.h | 42 ++++++++-
>>>>>> linux-headers/linux/virtio_config.h | 3 +
>>>>>> 6 files changed, 254 insertions(+), 44 deletions(-)
>>>>>> create mode 100644 linux-headers/asm-arm64/kvm.h
>>>>>> create mode 100644 linux-headers/asm-arm64/kvm_para.h
>>>>>
>>>>> I think this should go in via the KVM tree, not trivial.
>>>>
>>>> I do not mind, it just went through the trivial tree last time, that's it.
>>>
>>> This shouldn't be routed through trivial in general as things broke too
>>> often in this area.
>>
>> Sorry for my ignorance, but this is The Kernel, it is already there, broken
>> or not, even if it is broken, qemu cannot stay isolated, no?
>> This is a mechanical change, no more.
>
> It's a matter of keeping things bisectable. If we can detect a
> breakage, we can first work around it, and then apply the header update.
> And if we don't detect it, maintainers usually send pull requests when
> they have time to work on breakage caused by their patches.
I can see the discussion but I do not see if anyone is going to pull this
through any tree. Please, somebody, pull. Thanks.
--
Alexey
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Qemu-devel] [PATCH] linux-headers: update to 3.11
2013-09-05 3:16 ` Alexey Kardashevskiy
@ 2013-09-05 6:07 ` Paolo Bonzini
2013-09-18 3:04 ` Alexey Kardashevskiy
0 siblings, 1 reply; 17+ messages in thread
From: Paolo Bonzini @ 2013-09-05 6:07 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: Peter Maydell, kvm-devel, Gleb Natapov, QEMU Trivial, Jan Kiszka,
Michael Tokarev, QEMU Developers
Il 05/09/2013 05:16, Alexey Kardashevskiy ha scritto:
>>> >> Sorry for my ignorance, but this is The Kernel, it is already there, broken
>>> >> or not, even if it is broken, qemu cannot stay isolated, no?
>>> >> This is a mechanical change, no more.
>> >
>> > It's a matter of keeping things bisectable. If we can detect a
>> > breakage, we can first work around it, and then apply the header update.
>> > And if we don't detect it, maintainers usually send pull requests when
>> > they have time to work on breakage caused by their patches.
>
> I can see the discussion but I do not see if anyone is going to pull this
> through any tree. Please, somebody, pull. Thanks.
It will go in through the KVM tree, probably sometime next week.
Paolo
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Qemu-devel] [PATCH] linux-headers: update to 3.11
2013-09-05 6:07 ` Paolo Bonzini
@ 2013-09-18 3:04 ` Alexey Kardashevskiy
2013-09-18 4:51 ` Gleb Natapov
0 siblings, 1 reply; 17+ messages in thread
From: Alexey Kardashevskiy @ 2013-09-18 3:04 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Peter Maydell, kvm-devel, Gleb Natapov, QEMU Trivial, Jan Kiszka,
Michael Tokarev, QEMU Developers
On 09/05/2013 04:07 PM, Paolo Bonzini wrote:
> Il 05/09/2013 05:16, Alexey Kardashevskiy ha scritto:
>>>>>> Sorry for my ignorance, but this is The Kernel, it is already there, broken
>>>>>> or not, even if it is broken, qemu cannot stay isolated, no?
>>>>>> This is a mechanical change, no more.
>>>>
>>>> It's a matter of keeping things bisectable. If we can detect a
>>>> breakage, we can first work around it, and then apply the header update.
>>>> And if we don't detect it, maintainers usually send pull requests when
>>>> they have time to work on breakage caused by their patches.
>>
>> I can see the discussion but I do not see if anyone is going to pull this
>> through any tree. Please, somebody, pull. Thanks.
>
> It will go in through the KVM tree, probably sometime next week.
It is pretty impressive how such a trivial patch is still on its way to the
upstream :)
--
Alexey
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Qemu-devel] [PATCH] linux-headers: update to 3.11
2013-09-18 3:04 ` Alexey Kardashevskiy
@ 2013-09-18 4:51 ` Gleb Natapov
0 siblings, 0 replies; 17+ messages in thread
From: Gleb Natapov @ 2013-09-18 4:51 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: Peter Maydell, kvm-devel, QEMU Trivial, Jan Kiszka,
Michael Tokarev, QEMU Developers, Paolo Bonzini
On Wed, Sep 18, 2013 at 01:04:01PM +1000, Alexey Kardashevskiy wrote:
> On 09/05/2013 04:07 PM, Paolo Bonzini wrote:
> > Il 05/09/2013 05:16, Alexey Kardashevskiy ha scritto:
> >>>>>> Sorry for my ignorance, but this is The Kernel, it is already there, broken
> >>>>>> or not, even if it is broken, qemu cannot stay isolated, no?
> >>>>>> This is a mechanical change, no more.
> >>>>
> >>>> It's a matter of keeping things bisectable. If we can detect a
> >>>> breakage, we can first work around it, and then apply the header update.
> >>>> And if we don't detect it, maintainers usually send pull requests when
> >>>> they have time to work on breakage caused by their patches.
> >>
> >> I can see the discussion but I do not see if anyone is going to pull this
> >> through any tree. Please, somebody, pull. Thanks.
> >
> > It will go in through the KVM tree, probably sometime next week.
>
>
> It is pretty impressive how such a trivial patch is still on its way to the
> upstream :)
>
It was applied long time ago
https://git.kernel.org/cgit/virt/kvm/qemu-kvm.git/commit/?h=uq/master&id=8c409e659bc1373fab49a277bb5dc71babb73551
Sync with qemu.git does not happen after every patch though. If you are
working on kvm parts using qemu-kvm.git uq/master branch will make sure
that you are working on most up to date kvm bits. If you work depends on
something that is not in qemu-kvm.git then let kvm maintainers know and
we will send pull request to Anthony earlier.
--
Gleb.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [Qemu-devel] [PATCH] linux-headers: update to 3.11
2013-09-03 8:27 [Qemu-devel] [PATCH] linux-headers: update to 3.11 Alexey Kardashevskiy
2013-09-03 9:29 ` Peter Maydell
@ 2013-09-12 16:31 ` Paolo Bonzini
1 sibling, 0 replies; 17+ messages in thread
From: Paolo Bonzini @ 2013-09-12 16:31 UTC (permalink / raw)
To: Alexey Kardashevskiy; +Cc: qemu-trivial, Michael Tokarev, qemu-devel
Il 03/09/2013 10:27, Alexey Kardashevskiy ha scritto:
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
>
> I need this update as VFIO on PPC64/pseries got in upstream kernel
> and this is required by VFIO-SPAPR bits in QEMU. Others may find this
> update useful too :)
>
> ---
> linux-headers/asm-arm64/kvm.h | 168 ++++++++++++++++++++++++++++++++++++
> linux-headers/asm-arm64/kvm_para.h | 1 +
> linux-headers/asm-mips/kvm.h | 81 +++++++++--------
> linux-headers/linux/kvm.h | 3 +
> linux-headers/linux/vfio.h | 42 ++++++++-
> linux-headers/linux/virtio_config.h | 3 +
> 6 files changed, 254 insertions(+), 44 deletions(-)
> create mode 100644 linux-headers/asm-arm64/kvm.h
> create mode 100644 linux-headers/asm-arm64/kvm_para.h
>
> diff --git a/linux-headers/asm-arm64/kvm.h b/linux-headers/asm-arm64/kvm.h
> new file mode 100644
> index 0000000..5031f42
> --- /dev/null
> +++ b/linux-headers/asm-arm64/kvm.h
> @@ -0,0 +1,168 @@
> +/*
> + * Copyright (C) 2012,2013 - ARM Ltd
> + * Author: Marc Zyngier <marc.zyngier@arm.com>
> + *
> + * Derived from arch/arm/include/uapi/asm/kvm.h:
> + * Copyright (C) 2012 - Virtual Open Systems and Columbia University
> + * Author: Christoffer Dall <c.dall@virtualopensystems.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program. If not, see <http://www.gnu.org/licenses/>.
> + */
> +
> +#ifndef __ARM_KVM_H__
> +#define __ARM_KVM_H__
> +
> +#define KVM_SPSR_EL1 0
> +#define KVM_SPSR_SVC KVM_SPSR_EL1
> +#define KVM_SPSR_ABT 1
> +#define KVM_SPSR_UND 2
> +#define KVM_SPSR_IRQ 3
> +#define KVM_SPSR_FIQ 4
> +#define KVM_NR_SPSR 5
> +
> +#ifndef __ASSEMBLY__
> +#include <asm/types.h>
> +#include <asm/ptrace.h>
> +
> +#define __KVM_HAVE_GUEST_DEBUG
> +#define __KVM_HAVE_IRQ_LINE
> +
> +#define KVM_REG_SIZE(id) \
> + (1U << (((id) & KVM_REG_SIZE_MASK) >> KVM_REG_SIZE_SHIFT))
> +
> +struct kvm_regs {
> + struct user_pt_regs regs; /* sp = sp_el0 */
> +
> + __u64 sp_el1;
> + __u64 elr_el1;
> +
> + __u64 spsr[KVM_NR_SPSR];
> +
> + struct user_fpsimd_state fp_regs;
> +};
> +
> +/* Supported Processor Types */
> +#define KVM_ARM_TARGET_AEM_V8 0
> +#define KVM_ARM_TARGET_FOUNDATION_V8 1
> +#define KVM_ARM_TARGET_CORTEX_A57 2
> +
> +#define KVM_ARM_NUM_TARGETS 3
> +
> +/* KVM_ARM_SET_DEVICE_ADDR ioctl id encoding */
> +#define KVM_ARM_DEVICE_TYPE_SHIFT 0
> +#define KVM_ARM_DEVICE_TYPE_MASK (0xffff << KVM_ARM_DEVICE_TYPE_SHIFT)
> +#define KVM_ARM_DEVICE_ID_SHIFT 16
> +#define KVM_ARM_DEVICE_ID_MASK (0xffff << KVM_ARM_DEVICE_ID_SHIFT)
> +
> +/* Supported device IDs */
> +#define KVM_ARM_DEVICE_VGIC_V2 0
> +
> +/* Supported VGIC address types */
> +#define KVM_VGIC_V2_ADDR_TYPE_DIST 0
> +#define KVM_VGIC_V2_ADDR_TYPE_CPU 1
> +
> +#define KVM_VGIC_V2_DIST_SIZE 0x1000
> +#define KVM_VGIC_V2_CPU_SIZE 0x2000
> +
> +#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 */
> +
> +struct kvm_vcpu_init {
> + __u32 target;
> + __u32 features[7];
> +};
> +
> +struct kvm_sregs {
> +};
> +
> +struct kvm_fpu {
> +};
> +
> +struct kvm_guest_debug_arch {
> +};
> +
> +struct kvm_debug_exit_arch {
> +};
> +
> +struct kvm_sync_regs {
> +};
> +
> +struct kvm_arch_memory_slot {
> +};
> +
> +/* If you need to interpret the index values, here is the key: */
> +#define KVM_REG_ARM_COPROC_MASK 0x000000000FFF0000
> +#define KVM_REG_ARM_COPROC_SHIFT 16
> +
> +/* Normal registers are mapped as coprocessor 16. */
> +#define KVM_REG_ARM_CORE (0x0010 << KVM_REG_ARM_COPROC_SHIFT)
> +#define KVM_REG_ARM_CORE_REG(name) (offsetof(struct kvm_regs, name) / sizeof(__u32))
> +
> +/* Some registers need more space to represent values. */
> +#define KVM_REG_ARM_DEMUX (0x0011 << KVM_REG_ARM_COPROC_SHIFT)
> +#define KVM_REG_ARM_DEMUX_ID_MASK 0x000000000000FF00
> +#define KVM_REG_ARM_DEMUX_ID_SHIFT 8
> +#define KVM_REG_ARM_DEMUX_ID_CCSIDR (0x00 << KVM_REG_ARM_DEMUX_ID_SHIFT)
> +#define KVM_REG_ARM_DEMUX_VAL_MASK 0x00000000000000FF
> +#define KVM_REG_ARM_DEMUX_VAL_SHIFT 0
> +
> +/* AArch64 system registers */
> +#define KVM_REG_ARM64_SYSREG (0x0013 << KVM_REG_ARM_COPROC_SHIFT)
> +#define KVM_REG_ARM64_SYSREG_OP0_MASK 0x000000000000c000
> +#define KVM_REG_ARM64_SYSREG_OP0_SHIFT 14
> +#define KVM_REG_ARM64_SYSREG_OP1_MASK 0x0000000000003800
> +#define KVM_REG_ARM64_SYSREG_OP1_SHIFT 11
> +#define KVM_REG_ARM64_SYSREG_CRN_MASK 0x0000000000000780
> +#define KVM_REG_ARM64_SYSREG_CRN_SHIFT 7
> +#define KVM_REG_ARM64_SYSREG_CRM_MASK 0x0000000000000078
> +#define KVM_REG_ARM64_SYSREG_CRM_SHIFT 3
> +#define KVM_REG_ARM64_SYSREG_OP2_MASK 0x0000000000000007
> +#define KVM_REG_ARM64_SYSREG_OP2_SHIFT 0
> +
> +/* KVM_IRQ_LINE irq field index values */
> +#define KVM_ARM_IRQ_TYPE_SHIFT 24
> +#define KVM_ARM_IRQ_TYPE_MASK 0xff
> +#define KVM_ARM_IRQ_VCPU_SHIFT 16
> +#define KVM_ARM_IRQ_VCPU_MASK 0xff
> +#define KVM_ARM_IRQ_NUM_SHIFT 0
> +#define KVM_ARM_IRQ_NUM_MASK 0xffff
> +
> +/* irq_type field */
> +#define KVM_ARM_IRQ_TYPE_CPU 0
> +#define KVM_ARM_IRQ_TYPE_SPI 1
> +#define KVM_ARM_IRQ_TYPE_PPI 2
> +
> +/* out-of-kernel GIC cpu interrupt injection irq_number field */
> +#define KVM_ARM_IRQ_CPU_IRQ 0
> +#define KVM_ARM_IRQ_CPU_FIQ 1
> +
> +/* Highest supported SPI, from VGIC_NR_IRQS */
> +#define KVM_ARM_IRQ_GIC_MAX 127
> +
> +/* PSCI interface */
> +#define KVM_PSCI_FN_BASE 0x95c1ba5e
> +#define KVM_PSCI_FN(n) (KVM_PSCI_FN_BASE + (n))
> +
> +#define KVM_PSCI_FN_CPU_SUSPEND KVM_PSCI_FN(0)
> +#define KVM_PSCI_FN_CPU_OFF KVM_PSCI_FN(1)
> +#define KVM_PSCI_FN_CPU_ON KVM_PSCI_FN(2)
> +#define KVM_PSCI_FN_MIGRATE KVM_PSCI_FN(3)
> +
> +#define KVM_PSCI_RET_SUCCESS 0
> +#define KVM_PSCI_RET_NI ((unsigned long)-1)
> +#define KVM_PSCI_RET_INVAL ((unsigned long)-2)
> +#define KVM_PSCI_RET_DENIED ((unsigned long)-3)
> +
> +#endif
> +
> +#endif /* __ARM_KVM_H__ */
> diff --git a/linux-headers/asm-arm64/kvm_para.h b/linux-headers/asm-arm64/kvm_para.h
> new file mode 100644
> index 0000000..14fab8f
> --- /dev/null
> +++ b/linux-headers/asm-arm64/kvm_para.h
> @@ -0,0 +1 @@
> +#include <asm-generic/kvm_para.h>
> diff --git a/linux-headers/asm-mips/kvm.h b/linux-headers/asm-mips/kvm.h
> index 3f424f5..f09ff5a 100644
> --- a/linux-headers/asm-mips/kvm.h
> +++ b/linux-headers/asm-mips/kvm.h
> @@ -58,56 +58,53 @@ struct kvm_fpu {
> * bits[2..0] - Register 'sel' index.
> * bits[7..3] - Register 'rd' index.
> * bits[15..8] - Must be zero.
> - * bits[63..16] - 1 -> CP0 registers.
> + * bits[31..16] - 1 -> CP0 registers.
> + * bits[51..32] - Must be zero.
> + * bits[63..52] - As per linux/kvm.h
> *
> * Other sets registers may be added in the future. Each set would
> - * have its own identifier in bits[63..16].
> - *
> - * The addr field of struct kvm_one_reg must point to an aligned
> - * 64-bit wide location. For registers that are narrower than
> - * 64-bits, the value is stored in the low order bits of the location,
> - * and sign extended to 64-bits.
> + * have its own identifier in bits[31..16].
> *
> * The registers defined in struct kvm_regs are also accessible, the
> * id values for these are below.
> */
>
> -#define KVM_REG_MIPS_R0 0
> -#define KVM_REG_MIPS_R1 1
> -#define KVM_REG_MIPS_R2 2
> -#define KVM_REG_MIPS_R3 3
> -#define KVM_REG_MIPS_R4 4
> -#define KVM_REG_MIPS_R5 5
> -#define KVM_REG_MIPS_R6 6
> -#define KVM_REG_MIPS_R7 7
> -#define KVM_REG_MIPS_R8 8
> -#define KVM_REG_MIPS_R9 9
> -#define KVM_REG_MIPS_R10 10
> -#define KVM_REG_MIPS_R11 11
> -#define KVM_REG_MIPS_R12 12
> -#define KVM_REG_MIPS_R13 13
> -#define KVM_REG_MIPS_R14 14
> -#define KVM_REG_MIPS_R15 15
> -#define KVM_REG_MIPS_R16 16
> -#define KVM_REG_MIPS_R17 17
> -#define KVM_REG_MIPS_R18 18
> -#define KVM_REG_MIPS_R19 19
> -#define KVM_REG_MIPS_R20 20
> -#define KVM_REG_MIPS_R21 21
> -#define KVM_REG_MIPS_R22 22
> -#define KVM_REG_MIPS_R23 23
> -#define KVM_REG_MIPS_R24 24
> -#define KVM_REG_MIPS_R25 25
> -#define KVM_REG_MIPS_R26 26
> -#define KVM_REG_MIPS_R27 27
> -#define KVM_REG_MIPS_R28 28
> -#define KVM_REG_MIPS_R29 29
> -#define KVM_REG_MIPS_R30 30
> -#define KVM_REG_MIPS_R31 31
> +#define KVM_REG_MIPS_R0 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 0)
> +#define KVM_REG_MIPS_R1 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 1)
> +#define KVM_REG_MIPS_R2 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 2)
> +#define KVM_REG_MIPS_R3 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 3)
> +#define KVM_REG_MIPS_R4 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 4)
> +#define KVM_REG_MIPS_R5 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 5)
> +#define KVM_REG_MIPS_R6 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 6)
> +#define KVM_REG_MIPS_R7 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 7)
> +#define KVM_REG_MIPS_R8 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 8)
> +#define KVM_REG_MIPS_R9 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 9)
> +#define KVM_REG_MIPS_R10 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 10)
> +#define KVM_REG_MIPS_R11 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 11)
> +#define KVM_REG_MIPS_R12 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 12)
> +#define KVM_REG_MIPS_R13 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 13)
> +#define KVM_REG_MIPS_R14 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 14)
> +#define KVM_REG_MIPS_R15 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 15)
> +#define KVM_REG_MIPS_R16 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 16)
> +#define KVM_REG_MIPS_R17 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 17)
> +#define KVM_REG_MIPS_R18 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 18)
> +#define KVM_REG_MIPS_R19 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 19)
> +#define KVM_REG_MIPS_R20 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 20)
> +#define KVM_REG_MIPS_R21 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 21)
> +#define KVM_REG_MIPS_R22 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 22)
> +#define KVM_REG_MIPS_R23 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 23)
> +#define KVM_REG_MIPS_R24 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 24)
> +#define KVM_REG_MIPS_R25 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 25)
> +#define KVM_REG_MIPS_R26 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 26)
> +#define KVM_REG_MIPS_R27 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 27)
> +#define KVM_REG_MIPS_R28 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 28)
> +#define KVM_REG_MIPS_R29 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 29)
> +#define KVM_REG_MIPS_R30 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 30)
> +#define KVM_REG_MIPS_R31 (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 31)
>
> -#define KVM_REG_MIPS_HI 32
> -#define KVM_REG_MIPS_LO 33
> -#define KVM_REG_MIPS_PC 34
> +#define KVM_REG_MIPS_HI (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 32)
> +#define KVM_REG_MIPS_LO (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 33)
> +#define KVM_REG_MIPS_PC (KVM_REG_MIPS | KVM_REG_SIZE_U64 | 34)
>
> /*
> * KVM MIPS specific structures and definitions
> diff --git a/linux-headers/linux/kvm.h b/linux-headers/linux/kvm.h
> index c614070..56fce1c 100644
> --- a/linux-headers/linux/kvm.h
> +++ b/linux-headers/linux/kvm.h
> @@ -666,6 +666,7 @@ struct kvm_ppc_smmu_info {
> #define KVM_CAP_IRQ_MPIC 90
> #define KVM_CAP_PPC_RTAS 91
> #define KVM_CAP_IRQ_XICS 92
> +#define KVM_CAP_ARM_EL1_32BIT 93
>
> #ifdef KVM_CAP_IRQ_ROUTING
>
> @@ -783,6 +784,8 @@ struct kvm_dirty_tlb {
> #define KVM_REG_IA64 0x3000000000000000ULL
> #define KVM_REG_ARM 0x4000000000000000ULL
> #define KVM_REG_S390 0x5000000000000000ULL
> +#define KVM_REG_ARM64 0x6000000000000000ULL
> +#define KVM_REG_MIPS 0x7000000000000000ULL
>
> #define KVM_REG_SIZE_SHIFT 52
> #define KVM_REG_SIZE_MASK 0x00f0000000000000ULL
> diff --git a/linux-headers/linux/vfio.h b/linux-headers/linux/vfio.h
> index 7ec1864..b42b9ab 100644
> --- a/linux-headers/linux/vfio.h
> +++ b/linux-headers/linux/vfio.h
> @@ -22,6 +22,7 @@
> /* Extensions */
>
> #define VFIO_TYPE1_IOMMU 1
> +#define VFIO_SPAPR_TCE_IOMMU 2
>
> /*
> * The IOCTL interface is designed for extensibility by embedding the
> @@ -361,10 +362,14 @@ struct vfio_iommu_type1_dma_map {
> #define VFIO_IOMMU_MAP_DMA _IO(VFIO_TYPE, VFIO_BASE + 13)
>
> /**
> - * VFIO_IOMMU_UNMAP_DMA - _IOW(VFIO_TYPE, VFIO_BASE + 14, struct vfio_dma_unmap)
> + * VFIO_IOMMU_UNMAP_DMA - _IOWR(VFIO_TYPE, VFIO_BASE + 14,
> + * struct vfio_dma_unmap)
> *
> * Unmap IO virtual addresses using the provided struct vfio_dma_unmap.
> - * Caller sets argsz.
> + * Caller sets argsz. The actual unmapped size is returned in the size
> + * field. No guarantee is made to the user that arbitrary unmaps of iova
> + * or size different from those used in the original mapping call will
> + * succeed.
> */
> struct vfio_iommu_type1_dma_unmap {
> __u32 argsz;
> @@ -375,4 +380,37 @@ struct vfio_iommu_type1_dma_unmap {
>
> #define VFIO_IOMMU_UNMAP_DMA _IO(VFIO_TYPE, VFIO_BASE + 14)
>
> +/*
> + * IOCTLs to enable/disable IOMMU container usage.
> + * No parameters are supported.
> + */
> +#define VFIO_IOMMU_ENABLE _IO(VFIO_TYPE, VFIO_BASE + 15)
> +#define VFIO_IOMMU_DISABLE _IO(VFIO_TYPE, VFIO_BASE + 16)
> +
> +/* -------- Additional API for SPAPR TCE (Server POWERPC) IOMMU -------- */
> +
> +/*
> + * The SPAPR TCE info struct provides the information about the PCI bus
> + * address ranges available for DMA, these values are programmed into
> + * the hardware so the guest has to know that information.
> + *
> + * The DMA 32 bit window start is an absolute PCI bus address.
> + * The IOVA address passed via map/unmap ioctls are absolute PCI bus
> + * addresses too so the window works as a filter rather than an offset
> + * for IOVA addresses.
> + *
> + * A flag will need to be added if other page sizes are supported,
> + * so as defined here, it is always 4k.
> + */
> +struct vfio_iommu_spapr_tce_info {
> + __u32 argsz;
> + __u32 flags; /* reserved for future use */
> + __u32 dma32_window_start; /* 32 bit window start (bytes) */
> + __u32 dma32_window_size; /* 32 bit window size (bytes) */
> +};
> +
> +#define VFIO_IOMMU_SPAPR_TCE_GET_INFO _IO(VFIO_TYPE, VFIO_BASE + 12)
> +
> +/* ***************************************************************** */
> +
> #endif /* VFIO_H */
> diff --git a/linux-headers/linux/virtio_config.h b/linux-headers/linux/virtio_config.h
> index 4f51d8f..75dc20b 100644
> --- a/linux-headers/linux/virtio_config.h
> +++ b/linux-headers/linux/virtio_config.h
> @@ -51,4 +51,7 @@
> * suppressed them? */
> #define VIRTIO_F_NOTIFY_ON_EMPTY 24
>
> +/* Can the device handle any descriptor layout? */
> +#define VIRTIO_F_ANY_LAYOUT 27
> +
> #endif /* _LINUX_VIRTIO_CONFIG_H */
>
Applied to uq/master, thanks.
Paolo
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2013-09-18 4:52 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-03 8:27 [Qemu-devel] [PATCH] linux-headers: update to 3.11 Alexey Kardashevskiy
2013-09-03 9:29 ` Peter Maydell
2013-09-03 9:32 ` Alexey Kardashevskiy
2013-09-03 10:42 ` Jan Kiszka
2013-09-03 15:28 ` Alexey Kardashevskiy
2013-09-03 15:34 ` Peter Maydell
2013-09-03 15:47 ` Alexey Kardashevskiy
2013-09-03 15:55 ` Peter Maydell
2013-09-03 15:58 ` Alex Williamson
2013-09-03 16:03 ` Peter Maydell
2013-09-03 16:12 ` Alex Williamson
2013-09-03 15:35 ` Paolo Bonzini
2013-09-05 3:16 ` Alexey Kardashevskiy
2013-09-05 6:07 ` Paolo Bonzini
2013-09-18 3:04 ` Alexey Kardashevskiy
2013-09-18 4:51 ` Gleb Natapov
2013-09-12 16:31 ` Paolo Bonzini
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).