Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003

[Timur Tabi]

On 01/25/2017 09:52 AM, Christopher Covington wrote:

+   .desc = "Qualcomm Falkor erratum 1003",


FYI, this needs to say, "Qualcomm Technologies Falkor ...".  Same thing with 
the 1009 patch.


--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc.  Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v11 1/8] arm/arm64: vgic: Implement support for userspace access

[Auger Eric]

Hi,

On 26/01/2017 15:20, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K 
> 
> Read and write of some registers like ISPENDR and ICPENDR
> from userspace requires special handling when compared to
> guest access for these registers.
> 
> Refer to Documentation/virtual/kvm/devices/arm-vgic-v3.txt
> for handling of ISPENDR, ICPENDR registers handling.
> 
> Add infrastructure to support guest and userspace read
> and write for the required registers
> Also moved vgic_uaccess from vgic-mmio-v2.c to vgic-mmio.c
> 
> Signed-off-by: Vijaya Kumar K 
> Reviewed-by: Christoffer Dall 

Reviewed-by: Eric Auger 

Eric
> ---
>  virt/kvm/arm/vgic/vgic-mmio-v2.c | 25 ---
>  virt/kvm/arm/vgic/vgic-mmio-v3.c | 96 
> 
>  virt/kvm/arm/vgic/vgic-mmio.c| 78 +---
>  virt/kvm/arm/vgic/vgic-mmio.h| 19 
>  4 files changed, 169 insertions(+), 49 deletions(-)
> 
> diff --git a/virt/kvm/arm/vgic/vgic-mmio-v2.c 
> b/virt/kvm/arm/vgic/vgic-mmio-v2.c
> index 07e67f1..270eb4a 100644
> --- a/virt/kvm/arm/vgic/vgic-mmio-v2.c
> +++ b/virt/kvm/arm/vgic/vgic-mmio-v2.c
> @@ -407,31 +407,6 @@ int vgic_v2_has_attr_regs(struct kvm_device *dev, struct 
> kvm_device_attr *attr)
>   return -ENXIO;
>  }
>  
> -/*
> - * When userland tries to access the VGIC register handlers, we need to
> - * create a usable struct vgic_io_device to be passed to the handlers and we
> - * have to set up a buffer similar to what would have happened if a guest 
> MMIO
> - * access occurred, including doing endian conversions on BE systems.
> - */
> -static int vgic_uaccess(struct kvm_vcpu *vcpu, struct vgic_io_device *dev,
> - bool is_write, int offset, u32 *val)
> -{
> - unsigned int len = 4;
> - u8 buf[4];
> - int ret;
> -
> - if (is_write) {
> - vgic_data_host_to_mmio_bus(buf, len, *val);
> - ret = kvm_io_gic_ops.write(vcpu, >dev, offset, len, buf);
> - } else {
> - ret = kvm_io_gic_ops.read(vcpu, >dev, offset, len, buf);
> - if (!ret)
> - *val = vgic_data_mmio_bus_to_host(buf, len);
> - }
> -
> - return ret;
> -}
> -
>  int vgic_v2_cpuif_uaccess(struct kvm_vcpu *vcpu, bool is_write,
> int offset, u32 *val)
>  {
> diff --git a/virt/kvm/arm/vgic/vgic-mmio-v3.c 
> b/virt/kvm/arm/vgic/vgic-mmio-v3.c
> index 2aca52a..3548bb2 100644
> --- a/virt/kvm/arm/vgic/vgic-mmio-v3.c
> +++ b/virt/kvm/arm/vgic/vgic-mmio-v3.c
> @@ -207,6 +207,60 @@ static unsigned long vgic_mmio_read_v3_idregs(struct 
> kvm_vcpu *vcpu,
>   return 0;
>  }
>  
> +static unsigned long vgic_v3_uaccess_read_pending(struct kvm_vcpu *vcpu,
> +   gpa_t addr, unsigned int len)
> +{
> + u32 intid = VGIC_ADDR_TO_INTID(addr, 1);
> + u32 value = 0;
> + int i;
> +
> + /*
> +  * pending state of interrupt is latched in pending_latch variable.
> +  * Userspace will save and restore pending state and line_level
> +  * separately.
> +  * Refer to Documentation/virtual/kvm/devices/arm-vgic-v3.txt
> +  * for handling of ISPENDR and ICPENDR.
> +  */
> + for (i = 0; i < len * 8; i++) {
> + struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, intid + i);
> +
> + if (irq->pending_latch)
> + value |= (1U << i);
> +
> + vgic_put_irq(vcpu->kvm, irq);
> + }
> +
> + return value;
> +}
> +
> +static void vgic_v3_uaccess_write_pending(struct kvm_vcpu *vcpu,
> +   gpa_t addr, unsigned int len,
> +   unsigned long val)
> +{
> + u32 intid = VGIC_ADDR_TO_INTID(addr, 1);
> + int i;
> +
> + for (i = 0; i < len * 8; i++) {
> + struct vgic_irq *irq = vgic_get_irq(vcpu->kvm, vcpu, intid + i);
> +
> + spin_lock(>irq_lock);
> + if (test_bit(i, )) {
> + /*
> +  * pending_latch is set irrespective of irq type
> +  * (level or edge) to avoid dependency that VM should
> +  * restore irq config before pending info.
> +  */
> + irq->pending_latch = true;
> + vgic_queue_irq_unlock(vcpu->kvm, irq);
> + } else {
> + irq->pending_latch = false;
> + spin_unlock(>irq_lock);
> + }
> +
> + vgic_put_irq(vcpu->kvm, irq);
> + }
> +}
> +
>  /* We want to avoid outer shareable. */
>  u64 vgic_sanitise_shareability(u64 field)
>  {
> @@ -356,7 +410,7 @@ static void vgic_mmio_write_pendbase(struct kvm_vcpu 
> *vcpu,
>   * We take some special care here to fix the calculation of the register
>   * offset.
>   */
> -#define 

Re: [PATCH v11 2/8] arm/arm64: vgic: Add distributor and redistributor access

[Auger Eric]

Hi,

On 26/01/2017 15:20, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K 
> 
> VGICv3 Distributor and Redistributor registers are accessed using
> KVM_DEV_ARM_VGIC_GRP_DIST_REGS and KVM_DEV_ARM_VGIC_GRP_REDIST_REGS
> with KVM_SET_DEVICE_ATTR and KVM_GET_DEVICE_ATTR ioctls.
> These registers are accessed as 32-bit and cpu mpidr
> value passed along with register offset is used to identify the
> cpu for redistributor registers access.
> 
> The version of VGIC v3 specification is defined here
> Documentation/virtual/kvm/devices/arm-vgic-v3.txt
> 
> Also update arch/arm/include/uapi/asm/kvm.h to compile for
> AArch32 mode.
> 
> Signed-off-by: Vijaya Kumar K 
> Reviewed-by: Christoffer Dall 
Reviewed-by: Eric Auger 

Eric
> ---
>  arch/arm/include/uapi/asm/kvm.h |   4 +
>  arch/arm64/include/uapi/asm/kvm.h   |   4 +
>  virt/kvm/arm/vgic/vgic-kvm-device.c | 161 
> 
>  virt/kvm/arm/vgic/vgic-mmio-v2.c|  40 -
>  virt/kvm/arm/vgic/vgic-mmio-v3.c|  85 +++
>  virt/kvm/arm/vgic/vgic-mmio.c   |   2 +-
>  virt/kvm/arm/vgic/vgic.h|  40 -
>  7 files changed, 300 insertions(+), 36 deletions(-)
> 
> diff --git a/arch/arm/include/uapi/asm/kvm.h b/arch/arm/include/uapi/asm/kvm.h
> index af05f8e..0ae6035 100644
> --- a/arch/arm/include/uapi/asm/kvm.h
> +++ b/arch/arm/include/uapi/asm/kvm.h
> @@ -181,10 +181,14 @@ struct kvm_arch_memory_slot {
>  #define KVM_DEV_ARM_VGIC_GRP_CPU_REGS2
>  #define   KVM_DEV_ARM_VGIC_CPUID_SHIFT   32
>  #define   KVM_DEV_ARM_VGIC_CPUID_MASK(0xffULL << 
> KVM_DEV_ARM_VGIC_CPUID_SHIFT)
> +#define   KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT 32
> +#define   KVM_DEV_ARM_VGIC_V3_MPIDR_MASK \
> + (0xULL << KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT)
>  #define   KVM_DEV_ARM_VGIC_OFFSET_SHIFT  0
>  #define   KVM_DEV_ARM_VGIC_OFFSET_MASK   (0xULL << 
> KVM_DEV_ARM_VGIC_OFFSET_SHIFT)
>  #define KVM_DEV_ARM_VGIC_GRP_NR_IRQS 3
>  #define KVM_DEV_ARM_VGIC_GRP_CTRL   4
> +#define KVM_DEV_ARM_VGIC_GRP_REDIST_REGS 5
>  #define   KVM_DEV_ARM_VGIC_CTRL_INIT0
>  
>  /* KVM_IRQ_LINE irq field index values */
> diff --git a/arch/arm64/include/uapi/asm/kvm.h 
> b/arch/arm64/include/uapi/asm/kvm.h
> index 3051f86..56dc08d 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -201,10 +201,14 @@ struct kvm_arch_memory_slot {
>  #define KVM_DEV_ARM_VGIC_GRP_CPU_REGS2
>  #define   KVM_DEV_ARM_VGIC_CPUID_SHIFT   32
>  #define   KVM_DEV_ARM_VGIC_CPUID_MASK(0xffULL << 
> KVM_DEV_ARM_VGIC_CPUID_SHIFT)
> +#define   KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT 32
> +#define   KVM_DEV_ARM_VGIC_V3_MPIDR_MASK \
> + (0xULL << KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT)
>  #define   KVM_DEV_ARM_VGIC_OFFSET_SHIFT  0
>  #define   KVM_DEV_ARM_VGIC_OFFSET_MASK   (0xULL << 
> KVM_DEV_ARM_VGIC_OFFSET_SHIFT)
>  #define KVM_DEV_ARM_VGIC_GRP_NR_IRQS 3
>  #define KVM_DEV_ARM_VGIC_GRP_CTRL4
> +#define KVM_DEV_ARM_VGIC_GRP_REDIST_REGS 5
>  #define   KVM_DEV_ARM_VGIC_CTRL_INIT 0
>  
>  /* Device Control API on vcpu fd */
> diff --git a/virt/kvm/arm/vgic/vgic-kvm-device.c 
> b/virt/kvm/arm/vgic/vgic-kvm-device.c
> index fbe87a6..227337f 100644
> --- a/virt/kvm/arm/vgic/vgic-kvm-device.c
> +++ b/virt/kvm/arm/vgic/vgic-kvm-device.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "vgic.h"
>  
>  /* common helpers */
> @@ -230,14 +231,8 @@ int kvm_register_vgic_device(unsigned long type)
>   return ret;
>  }
>  
> -struct vgic_reg_attr {
> - struct kvm_vcpu *vcpu;
> - gpa_t addr;
> -};
> -
> -static int parse_vgic_v2_attr(struct kvm_device *dev,
> -   struct kvm_device_attr *attr,
> -   struct vgic_reg_attr *reg_attr)
> +int vgic_v2_parse_attr(struct kvm_device *dev, struct kvm_device_attr *attr,
> +struct vgic_reg_attr *reg_attr)
>  {
>   int cpuid;
>  
> @@ -292,14 +287,14 @@ static bool lock_all_vcpus(struct kvm *kvm)
>  }
>  
>  /**
> - * vgic_attr_regs_access_v2 - allows user space to access VGIC v2 state
> + * vgic_v2_attr_regs_access - allows user space to access VGIC v2 state
>   *
>   * @dev:  kvm device handle
>   * @attr: kvm device attribute
>   * @reg:  address the value is read or written
>   * @is_write: true if userspace is writing a register
>   */
> -static int vgic_attr_regs_access_v2(struct kvm_device *dev,
> +static int vgic_v2_attr_regs_access(struct kvm_device *dev,
>   struct kvm_device_attr *attr,
>   u32 *reg, bool is_write)
>  {
> @@ -308,7 +303,7 @@ static int vgic_attr_regs_access_v2(struct kvm_device 
> *dev,
>   struct kvm_vcpu *vcpu;
>   int ret;
>  
> - ret = 

Re: [PATCH v11 5/8] arm/arm64: vgic: Introduce VENG0 and VENG1 fields to vmcr struct

[Auger Eric]

Hi,

On 26/01/2017 15:20, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K 
> 
> ICC_VMCR_EL2 supports virtual access to ICC_IGRPEN1_EL1.Enable
> and ICC_IGRPEN0_EL1.Enable fields. Add grpen0 and grpen1 member
> variables to struct vmcr to support read and write of these fields.
> 
> Also refactor vgic_set_vmcr and vgic_get_vmcr() code.
> Drop ICH_VMCR_CTLR_SHIFT and ICH_VMCR_CTLR_MASK macros and instead
> use ICH_VMCR_EOI* and ICH_VMCR_CBPR* macros.
> 
> Signed-off-by: Vijaya Kumar K 
> Reviewed-by: Christoffer Dall 
Reviewed-by: Eric Auger 

Thanks

Eric
> ---
>  include/linux/irqchip/arm-gic-v3.h |  2 --
>  virt/kvm/arm/vgic/vgic-mmio-v2.c   | 16 
>  virt/kvm/arm/vgic/vgic-mmio.c  | 16 
>  virt/kvm/arm/vgic/vgic-v3.c| 20 ++--
>  virt/kvm/arm/vgic/vgic.h   |  5 +
>  5 files changed, 39 insertions(+), 20 deletions(-)
> 
> diff --git a/include/linux/irqchip/arm-gic-v3.h 
> b/include/linux/irqchip/arm-gic-v3.h
> index 7f6d904..170e00a 100644
> --- a/include/linux/irqchip/arm-gic-v3.h
> +++ b/include/linux/irqchip/arm-gic-v3.h
> @@ -404,8 +404,6 @@
>  #define ICH_HCR_EN   (1 << 0)
>  #define ICH_HCR_UIE  (1 << 1)
>  
> -#define ICH_VMCR_CTLR_SHIFT  0
> -#define ICH_VMCR_CTLR_MASK   (0x21f << ICH_VMCR_CTLR_SHIFT)
>  #define ICH_VMCR_CBPR_SHIFT  4
>  #define ICH_VMCR_CBPR_MASK   (1 << ICH_VMCR_CBPR_SHIFT)
>  #define ICH_VMCR_EOIM_SHIFT  9
> diff --git a/virt/kvm/arm/vgic/vgic-mmio-v2.c 
> b/virt/kvm/arm/vgic/vgic-mmio-v2.c
> index fa68dd4..a3ad7ff 100644
> --- a/virt/kvm/arm/vgic/vgic-mmio-v2.c
> +++ b/virt/kvm/arm/vgic/vgic-mmio-v2.c
> @@ -213,22 +213,6 @@ static void vgic_mmio_write_sgipends(struct kvm_vcpu 
> *vcpu,
>   }
>  }
>  
> -static void vgic_set_vmcr(struct kvm_vcpu *vcpu, struct vgic_vmcr *vmcr)
> -{
> - if (kvm_vgic_global_state.type == VGIC_V2)
> - vgic_v2_set_vmcr(vcpu, vmcr);
> - else
> - vgic_v3_set_vmcr(vcpu, vmcr);
> -}
> -
> -static void vgic_get_vmcr(struct kvm_vcpu *vcpu, struct vgic_vmcr *vmcr)
> -{
> - if (kvm_vgic_global_state.type == VGIC_V2)
> - vgic_v2_get_vmcr(vcpu, vmcr);
> - else
> - vgic_v3_get_vmcr(vcpu, vmcr);
> -}
> -
>  #define GICC_ARCH_VERSION_V2 0x2
>  
>  /* These are for userland accesses only, there is no guest-facing emulation. 
> */
> diff --git a/virt/kvm/arm/vgic/vgic-mmio.c b/virt/kvm/arm/vgic/vgic-mmio.c
> index 746c8af..1d1886e 100644
> --- a/virt/kvm/arm/vgic/vgic-mmio.c
> +++ b/virt/kvm/arm/vgic/vgic-mmio.c
> @@ -385,6 +385,22 @@ static int match_region(const void *key, const void *elt)
>  sizeof(region[0]), match_region);
>  }
>  
> +void vgic_set_vmcr(struct kvm_vcpu *vcpu, struct vgic_vmcr *vmcr)
> +{
> + if (kvm_vgic_global_state.type == VGIC_V2)
> + vgic_v2_set_vmcr(vcpu, vmcr);
> + else
> + vgic_v3_set_vmcr(vcpu, vmcr);
> +}
> +
> +void vgic_get_vmcr(struct kvm_vcpu *vcpu, struct vgic_vmcr *vmcr)
> +{
> + if (kvm_vgic_global_state.type == VGIC_V2)
> + vgic_v2_get_vmcr(vcpu, vmcr);
> + else
> + vgic_v3_get_vmcr(vcpu, vmcr);
> +}
> +
>  /*
>   * kvm_mmio_read_buf() returns a value in a format where it can be converted
>   * to a byte array and be directly observed as the guest wanted it to appear
> diff --git a/virt/kvm/arm/vgic/vgic-v3.c b/virt/kvm/arm/vgic/vgic-v3.c
> index 679ba93..42ff9c9 100644
> --- a/virt/kvm/arm/vgic/vgic-v3.c
> +++ b/virt/kvm/arm/vgic/vgic-v3.c
> @@ -175,10 +175,18 @@ void vgic_v3_set_vmcr(struct kvm_vcpu *vcpu, struct 
> vgic_vmcr *vmcrp)
>  {
>   u32 vmcr;
>  
> - vmcr  = (vmcrp->ctlr << ICH_VMCR_CTLR_SHIFT) & ICH_VMCR_CTLR_MASK;
> + /*
> +  * Ignore the FIQen bit, because GIC emulation always implies
> +  * SRE=1 which means the vFIQEn bit is also RES1.
> +  */
> + vmcr = ((vmcrp->ctlr >> ICC_CTLR_EL1_EOImode_SHIFT) <<
> +  ICH_VMCR_EOIM_SHIFT) & ICH_VMCR_EOIM_MASK;
> + vmcr |= (vmcrp->ctlr << ICH_VMCR_CBPR_SHIFT) & ICH_VMCR_CBPR_MASK;
>   vmcr |= (vmcrp->abpr << ICH_VMCR_BPR1_SHIFT) & ICH_VMCR_BPR1_MASK;
>   vmcr |= (vmcrp->bpr << ICH_VMCR_BPR0_SHIFT) & ICH_VMCR_BPR0_MASK;
>   vmcr |= (vmcrp->pmr << ICH_VMCR_PMR_SHIFT) & ICH_VMCR_PMR_MASK;
> + vmcr |= (vmcrp->grpen0 << ICH_VMCR_ENG0_SHIFT) & ICH_VMCR_ENG0_MASK;
> + vmcr |= (vmcrp->grpen1 << ICH_VMCR_ENG1_SHIFT) & ICH_VMCR_ENG1_MASK;
>  
>   vcpu->arch.vgic_cpu.vgic_v3.vgic_vmcr = vmcr;
>  }
> @@ -187,10 +195,18 @@ void vgic_v3_get_vmcr(struct kvm_vcpu *vcpu, struct 
> vgic_vmcr *vmcrp)
>  {
>   u32 vmcr = vcpu->arch.vgic_cpu.vgic_v3.vgic_vmcr;
>  
> - vmcrp->ctlr = (vmcr & ICH_VMCR_CTLR_MASK) >> ICH_VMCR_CTLR_SHIFT;
> + /*
> +  * Ignore the FIQen bit, because GIC emulation always implies
> +  * 

Re: [PATCH v11 6/8] arm/arm64: vgic: Implement VGICv3 CPU interface access

[Auger Eric]

Hi,

On 26/01/2017 15:20, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K 
> 
> VGICv3 CPU interface registers are accessed using
> KVM_DEV_ARM_VGIC_CPU_SYSREGS ioctl. These registers are accessed
> as 64-bit. The cpu MPIDR value is passed along with register id.
> It is used to identify the cpu for registers access.
> 
> The VM that supports SEIs expect it on destination machine to handle
> guest aborts and hence checked for ICC_CTLR_EL1.SEIS compatibility.
> Similarly, VM that supports Affinity Level 3 that is required for AArch64
> mode, is required to be supported on destination machine. Hence checked
> for ICC_CTLR_EL1.A3V compatibility.
> 
> The arch/arm64/kvm/vgic-sys-reg-v3.c handles read and write of VGIC
> CPU registers for AArch64.
> 
> For AArch32 mode, arch/arm/kvm/vgic-v3-coproc.c file is created but
> APIs are not implemented.
> 
> Updated arch/arm/include/uapi/asm/kvm.h with new definitions
> required to compile for AArch32.
> 
> The version of VGIC v3 specification is defined here
> Documentation/virtual/kvm/devices/arm-vgic-v3.txt
> 
> Signed-off-by: Pavel Fedin 
> Signed-off-by: Vijaya Kumar K 
Reviewed-by: Eric Auger 

Eric
> ---
>  arch/arm/include/uapi/asm/kvm.h |   3 +
>  arch/arm/kvm/Makefile   |   4 +-
>  arch/arm/kvm/vgic-v3-coproc.c   |  35 
>  arch/arm64/include/uapi/asm/kvm.h   |   3 +
>  arch/arm64/kvm/Makefile |   3 +-
>  arch/arm64/kvm/vgic-sys-reg-v3.c| 346 
> 
>  include/kvm/arm_vgic.h  |   8 +
>  virt/kvm/arm/vgic/vgic-kvm-device.c |  27 +++
>  virt/kvm/arm/vgic/vgic-mmio-v3.c|   6 +
>  virt/kvm/arm/vgic/vgic-v3.c |   8 +
>  virt/kvm/arm/vgic/vgic.h|  25 +++
>  11 files changed, 465 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/include/uapi/asm/kvm.h b/arch/arm/include/uapi/asm/kvm.h
> index 0ae6035..7a3e537 100644
> --- a/arch/arm/include/uapi/asm/kvm.h
> +++ b/arch/arm/include/uapi/asm/kvm.h
> @@ -186,9 +186,12 @@ struct kvm_arch_memory_slot {
>   (0xULL << KVM_DEV_ARM_VGIC_V3_MPIDR_SHIFT)
>  #define   KVM_DEV_ARM_VGIC_OFFSET_SHIFT  0
>  #define   KVM_DEV_ARM_VGIC_OFFSET_MASK   (0xULL << 
> KVM_DEV_ARM_VGIC_OFFSET_SHIFT)
> +#define   KVM_DEV_ARM_VGIC_SYSREG_INSTR_MASK (0x)
>  #define KVM_DEV_ARM_VGIC_GRP_NR_IRQS 3
>  #define KVM_DEV_ARM_VGIC_GRP_CTRL   4
>  #define KVM_DEV_ARM_VGIC_GRP_REDIST_REGS 5
> +#define KVM_DEV_ARM_VGIC_GRP_CPU_SYSREGS 6
> +
>  #define   KVM_DEV_ARM_VGIC_CTRL_INIT0
>  
>  /* KVM_IRQ_LINE irq field index values */
> diff --git a/arch/arm/kvm/Makefile b/arch/arm/kvm/Makefile
> index 12b6281..7b3670c 100644
> --- a/arch/arm/kvm/Makefile
> +++ b/arch/arm/kvm/Makefile
> @@ -7,7 +7,7 @@ ifeq ($(plus_virt),+virt)
>   plus_virt_def := -DREQUIRES_VIRT=1
>  endif
>  
> -ccflags-y += -Iarch/arm/kvm
> +ccflags-y += -Iarch/arm/kvm -Ivirt/kvm/arm/vgic
>  CFLAGS_arm.o := -I. $(plus_virt_def)
>  CFLAGS_mmu.o := -I.
>  
> @@ -20,7 +20,7 @@ kvm-arm-y = $(KVM)/kvm_main.o $(KVM)/coalesced_mmio.o 
> $(KVM)/eventfd.o $(KVM)/vf
>  obj-$(CONFIG_KVM_ARM_HOST) += hyp/
>  obj-y += kvm-arm.o init.o interrupts.o
>  obj-y += arm.o handle_exit.o guest.o mmu.o emulate.o reset.o
> -obj-y += coproc.o coproc_a15.o coproc_a7.o mmio.o psci.o perf.o
> +obj-y += coproc.o coproc_a15.o coproc_a7.o mmio.o psci.o perf.o 
> vgic-v3-coproc.o
>  obj-y += $(KVM)/arm/aarch32.o
>  
>  obj-y += $(KVM)/arm/vgic/vgic.o
> diff --git a/arch/arm/kvm/vgic-v3-coproc.c b/arch/arm/kvm/vgic-v3-coproc.c
> new file mode 100644
> index 000..f41abf7
> --- /dev/null
> +++ b/arch/arm/kvm/vgic-v3-coproc.c
> @@ -0,0 +1,35 @@
> +/*
> + * VGIC system registers handling functions for AArch32 mode
> + *
> + * 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.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include "vgic.h"
> +
> +int vgic_v3_has_cpu_sysregs_attr(struct kvm_vcpu *vcpu, bool is_write, u64 
> id,
> +  u64 *reg)
> +{
> + /*
> +  * TODO: Implement for AArch32
> +  */
> + return -ENXIO;
> +}
> +
> +int vgic_v3_cpu_sysregs_uaccess(struct kvm_vcpu *vcpu, bool is_write, u64 id,
> + u64 *reg)
> +{
> + /*
> +  * TODO: Implement for AArch32
> +  */
> + return -ENXIO;
> +}
> diff --git a/arch/arm64/include/uapi/asm/kvm.h 
> b/arch/arm64/include/uapi/asm/kvm.h
> index 56dc08d..be379d7 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ 

Re: [PATCH v11 7/8] arm/arm64: vgic: Implement KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO ioctl

[Auger Eric]

Hi,

On 26/01/2017 15:20, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K 
> 
> Userspace requires to store and restore of line_level for
> level triggered interrupts using ioctl KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO.
> 
> Signed-off-by: Vijaya Kumar K 
> ---
>  arch/arm/include/uapi/asm/kvm.h |  6 +
>  arch/arm64/include/uapi/asm/kvm.h   |  6 +
>  virt/kvm/arm/vgic/vgic-kvm-device.c | 45 ++-
>  virt/kvm/arm/vgic/vgic-mmio-v3.c| 14 ++
>  virt/kvm/arm/vgic/vgic-mmio.c   | 54 
> +
>  virt/kvm/arm/vgic/vgic-mmio.h   |  5 
>  virt/kvm/arm/vgic/vgic.h|  2 ++
>  7 files changed, 131 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/include/uapi/asm/kvm.h b/arch/arm/include/uapi/asm/kvm.h
> index 7a3e537..6ebd3e6 100644
> --- a/arch/arm/include/uapi/asm/kvm.h
> +++ b/arch/arm/include/uapi/asm/kvm.h
> @@ -191,6 +191,12 @@ struct kvm_arch_memory_slot {
>  #define KVM_DEV_ARM_VGIC_GRP_CTRL   4
>  #define KVM_DEV_ARM_VGIC_GRP_REDIST_REGS 5
>  #define KVM_DEV_ARM_VGIC_GRP_CPU_SYSREGS 6
> +#define KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO  7
> +#define KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT   10
> +#define KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_MASK \
> + (0x3fULL << KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT)
> +#define KVM_DEV_ARM_VGIC_LINE_LEVEL_INTID_MASK 0x3ff
> +#define VGIC_LEVEL_INFO_LINE_LEVEL   0
>  
>  #define   KVM_DEV_ARM_VGIC_CTRL_INIT0
>  
> diff --git a/arch/arm64/include/uapi/asm/kvm.h 
> b/arch/arm64/include/uapi/asm/kvm.h
> index be379d7..c286035 100644
> --- a/arch/arm64/include/uapi/asm/kvm.h
> +++ b/arch/arm64/include/uapi/asm/kvm.h
> @@ -211,6 +211,12 @@ struct kvm_arch_memory_slot {
>  #define KVM_DEV_ARM_VGIC_GRP_CTRL4
>  #define KVM_DEV_ARM_VGIC_GRP_REDIST_REGS 5
>  #define KVM_DEV_ARM_VGIC_GRP_CPU_SYSREGS 6
> +#define KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO  7
> +#define KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT   10
> +#define KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_MASK \
> + (0x3fULL << KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT)
> +#define KVM_DEV_ARM_VGIC_LINE_LEVEL_INTID_MASK   0x3ff
> +#define VGIC_LEVEL_INFO_LINE_LEVEL   0
>  
>  #define   KVM_DEV_ARM_VGIC_CTRL_INIT 0
>  
> diff --git a/virt/kvm/arm/vgic/vgic-kvm-device.c 
> b/virt/kvm/arm/vgic/vgic-kvm-device.c
> index b30372b..d181d2b 100644
> --- a/virt/kvm/arm/vgic/vgic-kvm-device.c
> +++ b/virt/kvm/arm/vgic/vgic-kvm-device.c
> @@ -512,6 +512,21 @@ static int vgic_v3_attr_regs_access(struct kvm_device 
> *dev,
> regid, reg);
>   break;
>   }
> + case KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO: {
> + unsigned int info, intid;
> +
> + info = (attr->attr & KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_MASK) >>
> + KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT;
> + if (info == VGIC_LEVEL_INFO_LINE_LEVEL) {
> + intid = attr->attr &
> + KVM_DEV_ARM_VGIC_LINE_LEVEL_INTID_MASK;
> + ret = vgic_v3_line_level_info_uaccess(vcpu, is_write,
> +   intid, reg);
> + } else {
> + ret = -EINVAL;
> + }
> + break;
> + }
>   default:
>   ret = -EINVAL;
>   break;
> @@ -554,6 +569,17 @@ static int vgic_v3_set_attr(struct kvm_device *dev,
>  
>   return vgic_v3_attr_regs_access(dev, attr, , true);
>   }
> + case KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO: {
> + u32 __user *uaddr = (u32 __user *)(long)attr->addr;
> + u64 reg;
> + u32 tmp32;
> +
> + if (get_user(tmp32, uaddr))
> + return -EFAULT;
> +
> + reg = tmp32;
> + return vgic_v3_attr_regs_access(dev, attr, , true);
> + }
>   }
>   return -ENXIO;
>  }
> @@ -589,8 +615,18 @@ static int vgic_v3_get_attr(struct kvm_device *dev,
>   return ret;
>   return put_user(reg, uaddr);
>   }
> - }
> + case KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO: {
> + u32 __user *uaddr = (u32 __user *)(long)attr->addr;
> + u64 reg;
> + u32 tmp32;
>  
> + ret = vgic_v3_attr_regs_access(dev, attr, , false);
> + if (ret)
> + return ret;
> + tmp32 = reg;
> + return put_user(tmp32, uaddr);
> + }
> + }
>   return -ENXIO;
>  }
>  
> @@ -611,6 +647,13 @@ static int vgic_v3_has_attr(struct kvm_device *dev,
>   return vgic_v3_has_attr_regs(dev, attr);
>   case KVM_DEV_ARM_VGIC_GRP_NR_IRQS:
>   return 0;
> + case KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO: {
> + if (((attr->attr & KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_MASK) >>
> +   

Re: [PATCH v11 7/8] arm/arm64: vgic: Implement KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO ioctl

[Auger Eric]

Hi,

On 27/01/2017 09:32, Auger Eric wrote:
> Hi,
> 
> On 26/01/2017 15:20, vijay.kil...@gmail.com wrote:
>> From: Vijaya Kumar K 
>>
>> Userspace requires to store and restore of line_level for
>> level triggered interrupts using ioctl KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO.
>>
>> Signed-off-by: Vijaya Kumar K 
>> ---
>>  arch/arm/include/uapi/asm/kvm.h |  6 +
>>  arch/arm64/include/uapi/asm/kvm.h   |  6 +
>>  virt/kvm/arm/vgic/vgic-kvm-device.c | 45 ++-
>>  virt/kvm/arm/vgic/vgic-mmio-v3.c| 14 ++
>>  virt/kvm/arm/vgic/vgic-mmio.c   | 54 
>> +
>>  virt/kvm/arm/vgic/vgic-mmio.h   |  5 
>>  virt/kvm/arm/vgic/vgic.h|  2 ++
>>  7 files changed, 131 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/include/uapi/asm/kvm.h 
>> b/arch/arm/include/uapi/asm/kvm.h
>> index 7a3e537..6ebd3e6 100644
>> --- a/arch/arm/include/uapi/asm/kvm.h
>> +++ b/arch/arm/include/uapi/asm/kvm.h
>> @@ -191,6 +191,12 @@ struct kvm_arch_memory_slot {
>>  #define KVM_DEV_ARM_VGIC_GRP_CTRL   4
>>  #define KVM_DEV_ARM_VGIC_GRP_REDIST_REGS 5
>>  #define KVM_DEV_ARM_VGIC_GRP_CPU_SYSREGS 6
>> +#define KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO  7
>> +#define KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT  10
>> +#define KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_MASK \
>> +(0x3fULL << KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT)
>> +#define KVM_DEV_ARM_VGIC_LINE_LEVEL_INTID_MASK 0x3ff
>> +#define VGIC_LEVEL_INFO_LINE_LEVEL  0
>>  
>>  #define   KVM_DEV_ARM_VGIC_CTRL_INIT0
>>  
>> diff --git a/arch/arm64/include/uapi/asm/kvm.h 
>> b/arch/arm64/include/uapi/asm/kvm.h
>> index be379d7..c286035 100644
>> --- a/arch/arm64/include/uapi/asm/kvm.h
>> +++ b/arch/arm64/include/uapi/asm/kvm.h
>> @@ -211,6 +211,12 @@ struct kvm_arch_memory_slot {
>>  #define KVM_DEV_ARM_VGIC_GRP_CTRL   4
>>  #define KVM_DEV_ARM_VGIC_GRP_REDIST_REGS 5
>>  #define KVM_DEV_ARM_VGIC_GRP_CPU_SYSREGS 6
>> +#define KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO  7
>> +#define KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT  10
>> +#define KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_MASK \
>> +(0x3fULL << KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT)
>> +#define KVM_DEV_ARM_VGIC_LINE_LEVEL_INTID_MASK  0x3ff
>> +#define VGIC_LEVEL_INFO_LINE_LEVEL  0
>>  
>>  #define   KVM_DEV_ARM_VGIC_CTRL_INIT0
>>  
>> diff --git a/virt/kvm/arm/vgic/vgic-kvm-device.c 
>> b/virt/kvm/arm/vgic/vgic-kvm-device.c
>> index b30372b..d181d2b 100644
>> --- a/virt/kvm/arm/vgic/vgic-kvm-device.c
>> +++ b/virt/kvm/arm/vgic/vgic-kvm-device.c
>> @@ -512,6 +512,21 @@ static int vgic_v3_attr_regs_access(struct kvm_device 
>> *dev,
>>regid, reg);
>>  break;
>>  }
>> +case KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO: {
>> +unsigned int info, intid;
>> +
>> +info = (attr->attr & KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_MASK) >>
>> +KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_SHIFT;
>> +if (info == VGIC_LEVEL_INFO_LINE_LEVEL) {
>> +intid = attr->attr &
>> +KVM_DEV_ARM_VGIC_LINE_LEVEL_INTID_MASK;
>> +ret = vgic_v3_line_level_info_uaccess(vcpu, is_write,
>> +  intid, reg);
>> +} else {
>> +ret = -EINVAL;
>> +}
>> +break;
>> +}
>>  default:
>>  ret = -EINVAL;
>>  break;
>> @@ -554,6 +569,17 @@ static int vgic_v3_set_attr(struct kvm_device *dev,
>>  
>>  return vgic_v3_attr_regs_access(dev, attr, , true);
>>  }
>> +case KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO: {
>> +u32 __user *uaddr = (u32 __user *)(long)attr->addr;
>> +u64 reg;
>> +u32 tmp32;
>> +
>> +if (get_user(tmp32, uaddr))
>> +return -EFAULT;
>> +
>> +reg = tmp32;
>> +return vgic_v3_attr_regs_access(dev, attr, , true);
>> +}
>>  }
>>  return -ENXIO;
>>  }
>> @@ -589,8 +615,18 @@ static int vgic_v3_get_attr(struct kvm_device *dev,
>>  return ret;
>>  return put_user(reg, uaddr);
>>  }
>> -}
>> +case KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO: {
>> +u32 __user *uaddr = (u32 __user *)(long)attr->addr;
>> +u64 reg;
>> +u32 tmp32;
>>  
>> +ret = vgic_v3_attr_regs_access(dev, attr, , false);
>> +if (ret)
>> +return ret;
>> +tmp32 = reg;
>> +return put_user(tmp32, uaddr);
>> +}
>> +}
>>  return -ENXIO;
>>  }
>>  
>> @@ -611,6 +647,13 @@ static int vgic_v3_has_attr(struct kvm_device *dev,
>>  return vgic_v3_has_attr_regs(dev, attr);
>>  case KVM_DEV_ARM_VGIC_GRP_NR_IRQS:
>>  return 0;
>> +case 

Re: [PATCH v11 8/8] arm/arm64: Documentation: Update arm-vgic-v3.txt

[Auger Eric]

Hi Vijaya,

On 26/01/2017 15:20, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K 
> 
> Update error code returned for Invalid CPU interface register
> value and access in AArch32 mode.
> 
> Signed-off-by: Vijaya Kumar K 
Reviewed-by: Eric Auger 

Thanks

Eric
> ---
>  Documentation/virtual/kvm/devices/arm-vgic-v3.txt | 11 ---
>  1 file changed, 8 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/virtual/kvm/devices/arm-vgic-v3.txt 
> b/Documentation/virtual/kvm/devices/arm-vgic-v3.txt
> index 9348b3c..c1a2461 100644
> --- a/Documentation/virtual/kvm/devices/arm-vgic-v3.txt
> +++ b/Documentation/virtual/kvm/devices/arm-vgic-v3.txt
> @@ -118,7 +118,7 @@ Groups:
>  -EBUSY: One or more VCPUs are running
>  
>  
> -  KVM_DEV_ARM_VGIC_CPU_SYSREGS
> +  KVM_DEV_ARM_VGIC_GRP_CPU_SYSREGS
>Attributes:
>  The attr field of kvm_device_attr encodes two values:
>  bits: | 63     32 | 31    16 | 15    0 |
> @@ -139,13 +139,15 @@ Groups:
>  All system regs accessed through this API are (rw, 64-bit) and
>  kvm_device_attr.addr points to a __u64 value.
>  
> -KVM_DEV_ARM_VGIC_CPU_SYSREGS accesses the CPU interface registers for the
> +KVM_DEV_ARM_VGIC_GRP_CPU_SYSREGS accesses the CPU interface registers 
> for the
>  CPU specified by the mpidr field.
>  
> +CPU interface registers access is not implemented for AArch32 mode.
> +Error -ENXIO is returned when accessed in AArch32 mode.
>Errors:
>  -ENXIO: Getting or setting this register is not yet supported
>  -EBUSY: VCPU is running
> --EINVAL: Invalid mpidr supplied
> +-EINVAL: Invalid mpidr or register value supplied
>  
>  
>KVM_DEV_ARM_VGIC_GRP_NR_IRQS
> @@ -204,3 +206,6 @@ Groups:
>  architecture defined MPIDR, and the field is encoded as follows:
>| 63  56 | 55  48 | 47  40 | 39  32 |
>|Aff3|Aff2|Aff1|Aff0|
> +  Errors:
> +-EINVAL: vINTID is not multiple of 32 or
> + info field is not VGIC_LEVEL_INFO_LINE_LEVEL
> 
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v11 0/8] arm/arm64: vgic: Implement API for vGICv3 live migration

[Auger Eric]

Hi Vijaya,

On 26/01/2017 15:20, vijay.kil...@gmail.com wrote:
> From: Vijaya Kumar K 
> 
> This patchset adds API for saving and restoring
> of VGICv3 registers to support live migration with new vgic feature.
> This API definition is as per version of VGICv3 specification
> Documentation/virtual/kvm/devices/arm-vgic-v3.txt
> 
> The patch 3 & 4 are picked from the Pavel's previous implementation.
> http://www.spinics.net/lists/kvm/msg122040.html
> 
> NOTE: Only compilation tested for AArch32. No hardware available to test.
> 
> v10 => v11:
>  - Rebased on top of kvmarm queue branch
>  - Renamed KVM_DEV_ARM_VGIC_CPU_SYSREGS to KVM_DEV_ARM_VGIC_GRP_CPU_SYSREGS
>  - Used vcpu0 for KVM_DEV_ARM_VGIC_GRP_DIST_REGS access
>  - Exported vgic_v{2,3}_has_attr_regs()
>  - Used vgic_get_mmio_region() in vgic_v{2,3}_has_attr_regs() for checking
>validity of regs address in patch 2.
>  - Moved macros KVM_REG_ARM_VGIC_SYSREG_* from patch 2 to patch 6
>  - Fixed comments from Eric Auger
>  - Updated document.

I tested this new version along with ITS migration on Cavium ThunderX
(virtio-pci net guest) with virsh save/restore.

Tested-by: Eric Auger 

Thanks

Eric

> 
> v9 => v10:
>  - Dropped support for AArch32 mode.
>  - Fixed line level update
>  - Updated documentation
>  - Moved vgic-sys-reg-v3.c to arch/arm64/kvm/ and
>added vgic-v3-coproc.c to arch/arm/kvm for AArch32
>  - Fixed nits
> 
> v8 => v9:
>  - Rebased to kvmarm/next branch
>  - Introduce support for save and restore of CPU interface
>registers for AArch32 mode (9,10 and 11 patches).
>Only compilation tested.
>  - Fixed vmcr.ctlr format
>  - Updated error code for invalid CPU REG value in Documentation
>  - Updated commit messages and added comments required
>  - Queued IRQ when irq_line is set.
>  - Compatibility check on ICC_CTLR_EL1.SEIS and A3V
> 
> v7 => v8:
>  - Rebased to 4.9-rc3
>  - Fixed wrong parameter to VGIC_TO_MPIDR
> v6 => v7:
>  - Rename all patches heading from vgic-new to vgic
>  - Moved caching of priority and ID bits from vgic global struct
>to vgic_cpu struct.
> 
> v5 => v6:
>  - Collated all register definitions to single patch (4)
>  - Introduce macro to convert userspace MPIDR format to MPIDR reg format
>  - Check on ICC_CTLR_EL1.CBPR value is made while accessing ICC_BPR1_EL1
>  - Cached ich_vtr_el2 and guests priority and ID bits
>  - Check on number of priority and ID bits when ICC_CTRL_EL1 write is made
>  - Check is made on SRE bit for ICC_SRE_EL1 write
> 
> v4 => v5:
>  - ICC_CTLR_EL1 access is updated to reflect HW values
>  - Updated ICC reg access mask and shift macros
>  - Introduced patch 4 for VMCR changes
>  - Other minor fixes.
> v3 => v4:
>  - Rebased to latest code base
>  - Moved vgic_uaccess() from vgic-mmio-v2.c to vgic-mmio.c
>  - Dropped macro REGISTER_DESC_WITH_BITS_PER_IRQ_SHARED_UACCESS
>  - Dropped LE conversion for userspace access
>  - Introduced vgic_uaccess_write_pending() for ISPENDR write
>  - Change macro KVM_DEV_ARM_VGIC_V3_CPUID_MASK to 
> KVM_DEV_ARM_VGIC_V3_MIDR_MASK
>  - Refactored some code as common code.
>  - Changed handing of ICC_* registers
>  - Allowed ICC_SRE_EL1 read by userspace
>  - Fixed KVM_DEV_ARM_VGIC_LINE_LEVEL_INFO_* macros
> 
> v2 => v3:
>  - Implemented separate API for ISPENDR and ICPENDR to
>read soft_pending instead of pending for level triggerred interrupts
>  - Implemented ioctl KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO to access line level
>  - Rebased on top of Christoffer's patch set
>http://www.spinics.net/lists/kvm/msg136840.html
> 
>  NOTE: GICD_STATUSR and GICR_STATUSR are implemented as RAZ/WI.
> 
> v1 => v2:
>  - The init sequence change patch is no more required.
>Fixed in patch 2 by using static vgic_io_dev regions structure instead
>of using dynamic allocation pointer.
>  - Updated commit message of patch 4.
>  - Dropped usage of union to manage 32-bit and 64-bit access in patch 1.
>Used local variable for 32-bit access.
>  - Updated macro __ARM64_SYS_REG and ARM64_SYS_REG in
>arch/arm64/include/uapi/asm/kvm.h as per qemu requirements.
> 
> Vijaya Kumar K (8):
>   arm/arm64: vgic: Implement support for userspace access
>   arm/arm64: vgic: Add distributor and redistributor access
>   arm/arm64: vgic: Introduce find_reg_by_id()
>   irqchip/gic-v3: Add missing system register definitions
>   arm/arm64: vgic: Introduce VENG0 and VENG1 fields to vmcr struct
>   arm/arm64: vgic: Implement VGICv3 CPU interface access
>   arm/arm64: vgic: Implement KVM_DEV_ARM_VGIC_GRP_LEVEL_INFO ioctl
>   arm/arm64: Documentation: Update arm-vgic-v3.txt
> 
>  Documentation/virtual/kvm/devices/arm-vgic-v3.txt |  11 +-
>  arch/arm/include/uapi/asm/kvm.h   |  13 +
>  arch/arm/kvm/Makefile |   4 +-
>  arch/arm/kvm/vgic-v3-coproc.c |  35 +++
>  arch/arm64/include/uapi/asm/kvm.h |  13 +
>  arch/arm64/kvm/Makefile 

Re: [PATCH v11 0/8] arm/arm64: vgic: Implement API for vGICv3 live migration

[Marc Zyngier]

On 26/01/17 20:26, Christoffer Dall wrote:
> Hi Vijaya,
> 
> On Thu, Jan 26, 2017 at 07:50:45PM +0530, vijay.kil...@gmail.com wrote:
>> From: Vijaya Kumar K 
>>
>> This patchset adds API for saving and restoring
>> of VGICv3 registers to support live migration with new vgic feature.
>> This API definition is as per version of VGICv3 specification
>> Documentation/virtual/kvm/devices/arm-vgic-v3.txt
>>
>> The patch 3 & 4 are picked from the Pavel's previous implementation.
>> http://www.spinics.net/lists/kvm/msg122040.html
>>
>> NOTE: Only compilation tested for AArch32. No hardware available to test.
> 
> Thanks for the respin.  I've given this a once-over and tested on GICv2
> against migrations and on GICv3 for this functionality, and it looks
> good.
> 
> It would be good to see a soon respin of the QEMU series as well.
> 
> Marc, unless others have objections to this series, I think we can queue
> this series.

Yup, I'll queue it on top. Thanks everyone for sticking with this series.

M.
-- 
Jazz is not dead. It just smells funny...
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v11 0/8] arm/arm64: vgic: Implement API for vGICv3 live migration

[Christoffer Dall]

On Fri, Jan 27, 2017 at 09:45:06AM +, Marc Zyngier wrote:
> On 26/01/17 20:26, Christoffer Dall wrote:
> > Hi Vijaya,
> > 
> > On Thu, Jan 26, 2017 at 07:50:45PM +0530, vijay.kil...@gmail.com wrote:
> >> From: Vijaya Kumar K 
> >>
> >> This patchset adds API for saving and restoring
> >> of VGICv3 registers to support live migration with new vgic feature.
> >> This API definition is as per version of VGICv3 specification
> >> Documentation/virtual/kvm/devices/arm-vgic-v3.txt
> >>
> >> The patch 3 & 4 are picked from the Pavel's previous implementation.
> >> http://www.spinics.net/lists/kvm/msg122040.html
> >>
> >> NOTE: Only compilation tested for AArch32. No hardware available to test.
> > 
> > Thanks for the respin.  I've given this a once-over and tested on GICv2
> > against migrations and on GICv3 for this functionality, and it looks

haha, just noticed this.  That's against *regressions* obviously.


> > good.
> > 
> > It would be good to see a soon respin of the QEMU series as well.
> > 
> > Marc, unless others have objections to this series, I think we can queue
> > this series.
> 
> Yup, I'll queue it on top. Thanks everyone for sticking with this series.
> 

Thanks,
-Christoffer
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v4 3/4] arm64: Use __tlbi() macros in KVM code

[Will Deacon]

On Wed, Jan 25, 2017 at 08:39:43PM +0100, Christoffer Dall wrote:
> On Wed, Jan 25, 2017 at 10:52:31AM -0500, Christopher Covington wrote:
> > Refactor the KVM code to use the __tlbi macros, which will allow an errata
> > workaround that repeats tlbi dsb sequences to only change one location.
> > This is not intended to change the generated assembly and comparing before
> > and after vmlinux objdump shows no functional changes.
> > 
> > Signed-off-by: Christopher Covington 
> 
> Acked-by: Christoffer Dall 

Thanks, I'll queue this one via arm64.

Will
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003

[Mark Rutland]

On Wed, Jan 25, 2017 at 10:52:30AM -0500, Christopher Covington wrote:
> The Qualcomm Datacenter Technologies Falkor v1 CPU may allocate TLB entries
> using an incorrect ASID when TTBRx_EL1 is being updated. When the erratum
> is triggered, page table entries using the new translation table base
> address (BADDR) will be allocated into the TLB using the old ASID. All
> circumstances leading to the incorrect ASID being cached in the TLB arise
> when software writes TTBRx_EL1[ASID] and TTBRx_EL1[BADDR], a memory
> operation is in the process of performing a translation using the specific
> TTBRx_EL1 being written, and the memory operation uses a translation table
> descriptor designated as non-global. EL2 and EL3 code changing the EL1&0
> ASID is not subject to this erratum because hardware is prohibited from
> performing translations from an out-of-context translation regime.
>
> Consider the following pseudo code.
>
>   write new BADDR and ASID values to TTBRx_EL1
>
> Replacing the above sequence with the one below will ensure that no TLB
> entries with an incorrect ASID are used by software.
>
>   write reserved value to TTBRx_EL1[ASID]
>   ISB
>   write new value to TTBRx_EL1[BADDR]
>   ISB
>   write new value to TTBRx_EL1[ASID]
>   ISB
>
> When the above sequence is used, page table entries using the new BADDR
> value may still be incorrectly allocated into the TLB using the reserved
> ASID. Yet this will not reduce functionality, since TLB entries incorrectly
> tagged with the reserved ASID will never be hit by a later instruction.

I agree that there should be no explicit accesses to the VAs for these
entries. So tasks should not see erroneous VAs, and we shouldn't see
synchronous TLB conflict aborts.

Regardless, can this allow conflicting TLB entries to be allocated to
the reserved ASID? e.g. if one task has a 4K mapping at a given VA, and
another has a 2M mapping which covers that VA, can both be allocated
into the TLBs under the reserved ASID?

Can that have any effect on asynchronous TLB lookups or page table
walks, e.g. for speculated accesses?

Thanks,
Mark.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH] KVM: arm64: Increase number of memslots to 512

[Prakash B]

> Can you shed some light on your test process?
Hi Linu / Marc Zyngier,

I tested this patch on top of latest VFIO MSI supported version 9
patches on ThunderX with internal 10G VNIC and Intel IXGBE NIC.
Please feel free to add my:
Tested-by: Prakash, Brahmajyosyula 

Thanks,
 prakash B
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003

[Mark Rutland]

On Fri, Jan 27, 2017 at 02:38:49PM +, Mark Rutland wrote:

> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose
> the contents to any other person, use it for any purpose, or store or
> copy the information in any medium. Thank you.

Urrgh; I used the wrong mail configuration.

Please ignore the above from the prior email.

Mark.
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v4 3/4] arm64: Use __tlbi() macros in KVM code

[Will Deacon]

On Wed, Jan 25, 2017 at 10:52:31AM -0500, Christopher Covington wrote:
> Refactor the KVM code to use the __tlbi macros, which will allow an errata
> workaround that repeats tlbi dsb sequences to only change one location.
> This is not intended to change the generated assembly and comparing before
> and after vmlinux objdump shows no functional changes.
> 
> Signed-off-by: Christopher Covington 
> ---
>  arch/arm64/kvm/hyp/tlb.c | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)

[...]

> @@ -82,7 +83,7 @@ void __hyp_text __kvm_tlb_flush_local_vmid(struct kvm_vcpu 
> *vcpu)
>  void __hyp_text __kvm_flush_vm_context(void)
>  {
>   dsb(ishst);
> - asm volatile("tlbi alle1is  \n"
> -  "ic ialluis  ": : );
> + __tlbi(alle1is);
> + asm volatile("ic ialluis" : : );
>   dsb(ish);

Should be a separate patch, but this can now be a __flush_icache_all instead
of the open-coded asm.

Will
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v4 4/4] arm64: Work around Falkor erratum 1009

[Will Deacon]

On Wed, Jan 25, 2017 at 10:52:32AM -0500, Christopher Covington wrote:
> During a TLB invalidate sequence targeting the inner shareable domain,
> Falkor may prematurely complete the DSB before all loads and stores using
> the old translation are observed. Instruction fetches are not subject to
> the conditions of this erratum. If the original code sequence includes
> multiple TLB invalidate instructions followed by a single DSB, onle one of
> the TLB instructions needs to be repeated to work around this erratum.
> While the erratum only applies to cases in which the TLBI specifies the
> inner-shareable domain (*IS form of TLBI) and the DSB is ISH form or
> stronger (OSH, SYS), this changes applies the workaround overabundantly--
> to local TLBI, DSB NSH sequences as well--for simplicity.
> 
> Based on work by Shanker Donthineni 
> 
> Signed-off-by: Christopher Covington 
> ---
>  Documentation/arm64/silicon-errata.txt |  1 +
>  arch/arm64/Kconfig | 10 ++
>  arch/arm64/include/asm/cpucaps.h   |  3 ++-
>  arch/arm64/include/asm/tlbflush.h  | 18 +++---
>  arch/arm64/kernel/cpu_errata.c |  7 +++
>  5 files changed, 35 insertions(+), 4 deletions(-)

Thanks, this one looks good to me. It doesn't apply without the other
erratum workaround (due to conflicts), so I'll have to wait for the
discussion with Mark to each a conclusion before I can queue it.

One minor comment inline...

> diff --git a/arch/arm64/include/asm/tlbflush.h 
> b/arch/arm64/include/asm/tlbflush.h
> index deab52374119..fc434f421c7b 100644
> --- a/arch/arm64/include/asm/tlbflush.h
> +++ b/arch/arm64/include/asm/tlbflush.h
> @@ -36,9 +36,21 @@
>   * not. The macros handles invoking the asm with or without the
>   * register argument as appropriate.
>   */
> -#define __TLBI_0(op, arg)asm ("tlbi " #op)
> -#define __TLBI_1(op, arg)asm ("tlbi " #op ", %0" : : "r" (arg))
> -#define __TLBI_N(op, arg, n, ...)__TLBI_##n(op, arg)
> +#define __TLBI_0(op, arg) asm volatile ("tlbi " #op "\n"\
> + ALTERNATIVE("nop\n  nop",  \
> + "dsb ish\n  tlbi " #op,\
> + ARM64_WORKAROUND_REPEAT_TLBI,  \
> + CONFIG_QCOM_FALKOR_ERRATUM_1009)   \
> + : : )
> +
> +#define __TLBI_1(op, arg) asm volatile ("tlbi " #op ", %0\n"\
> + ALTERNATIVE("nop\n  nop",  \
> + "dsb ish\n  tlbi " #op ", %0", \
> + ARM64_WORKAROUND_REPEAT_TLBI,  \
> + CONFIG_QCOM_FALKOR_ERRATUM_1009)   \
> + : : "r" (arg))

I don't think you need to make these volatile.

Will
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

Re: [PATCH v4 2/4] arm64: Work around Falkor erratum 1003

[Christopher Covington]

Hi Mark,

On 01/27/2017 09:38 AM, Mark Rutland wrote:
> On Wed, Jan 25, 2017 at 10:52:30AM -0500, Christopher Covington wrote:
>> The Qualcomm Datacenter Technologies Falkor v1 CPU may allocate TLB entries
>> using an incorrect ASID when TTBRx_EL1 is being updated. When the erratum
>> is triggered, page table entries using the new translation table base
>> address (BADDR) will be allocated into the TLB using the old ASID. All
>> circumstances leading to the incorrect ASID being cached in the TLB arise
>> when software writes TTBRx_EL1[ASID] and TTBRx_EL1[BADDR], a memory
>> operation is in the process of performing a translation using the specific
>> TTBRx_EL1 being written, and the memory operation uses a translation table
>> descriptor designated as non-global. EL2 and EL3 code changing the EL1&0
>> ASID is not subject to this erratum because hardware is prohibited from
>> performing translations from an out-of-context translation regime.
>>
>> Consider the following pseudo code.
>>
>>   write new BADDR and ASID values to TTBRx_EL1
>>
>> Replacing the above sequence with the one below will ensure that no TLB
>> entries with an incorrect ASID are used by software.
>>
>>   write reserved value to TTBRx_EL1[ASID]
>>   ISB
>>   write new value to TTBRx_EL1[BADDR]
>>   ISB
>>   write new value to TTBRx_EL1[ASID]
>>   ISB
>>
>> When the above sequence is used, page table entries using the new BADDR
>> value may still be incorrectly allocated into the TLB using the reserved
>> ASID. Yet this will not reduce functionality, since TLB entries incorrectly
>> tagged with the reserved ASID will never be hit by a later instruction.
> 
> I agree that there should be no explicit accesses to the VAs for these
> entries. So tasks should not see erroneous VAs, and we shouldn't see
> synchronous TLB conflict aborts.
> 
> Regardless, can this allow conflicting TLB entries to be allocated to
> the reserved ASID? e.g. if one task has a 4K mapping at a given VA, and
> another has a 2M mapping which covers that VA, can both be allocated
> into the TLBs under the reserved ASID?
> 
> Can that have any effect on asynchronous TLB lookups or page table
> walks, e.g. for speculated accesses?

A speculative access that inserts an entry into the TLB could
possibly find the conflict but will not signal it. Does that answer
your question?

Thanks,
Cov

-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code
Aurora Forum, a Linux Foundation Collaborative Project.
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm