linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Christoffer Dall <cdall@linaro.org>
To: Jintack Lim <jintack@cs.columbia.edu>
Cc: christoffer.dall@linaro.org, marc.zyngier@arm.com,
	pbonzini@redhat.com, rkrcmar@redhat.com, linux@armlinux.org.uk,
	catalin.marinas@arm.com, will.deacon@arm.com,
	vladimir.murzin@arm.com, suzuki.poulose@arm.com,
	mark.rutland@arm.com, james.morse@arm.com,
	lorenzo.pieralisi@arm.com, kevin.brodsky@arm.com,
	wcohen@redhat.com, shankerd@codeaurora.org, geoff@infradead.org,
	andre.przywara@arm.com, eric.auger@redhat.com,
	anna-maria@linutronix.de, shihwei@cs.columbia.edu,
	linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RFC 40/55] KVM: arm/arm64: Handle vttbr_el2 write operation from the guest hypervisor
Date: Wed, 22 Feb 2017 18:59:46 +0100	[thread overview]
Message-ID: <20170222175946.GV26976@cbox> (raw)
In-Reply-To: <1483943091-1364-41-git-send-email-jintack@cs.columbia.edu>

On Mon, Jan 09, 2017 at 01:24:36AM -0500, Jintack Lim wrote:
> Each nested VM is supposed to have a mmu (i.e. shadow stage-2 page

to have a 'struct kvm_mmu' ?

> table), and we create it when the guest hypervisor writes to vttbr_el2
> with a new vmid.

I think the commit message should also mention that you maintain a list
of seen nested stage 2 translation contexts and associated shadow page
tables.

> 
> In case the guest hypervisor writes to vttbr_el2 with existing vmid, we
> check if the base address is changed. If so, then what we have in the
> shadow page table is not valid any more. So ummap it.

unmap?  We clear the entire shadow stage 2 page table, right?

> 
> Signed-off-by: Jintack Lim <jintack@cs.columbia.edu>
> ---
>  arch/arm/include/asm/kvm_host.h   |  1 +
>  arch/arm/kvm/arm.c                |  1 +
>  arch/arm64/include/asm/kvm_host.h |  1 +
>  arch/arm64/include/asm/kvm_mmu.h  |  6 ++++
>  arch/arm64/kvm/mmu-nested.c       | 71 +++++++++++++++++++++++++++++++++++++++
>  arch/arm64/kvm/sys_regs.c         | 15 ++++++++-
>  6 files changed, 94 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
> index fbde48d..ebf2810 100644
> --- a/arch/arm/include/asm/kvm_host.h
> +++ b/arch/arm/include/asm/kvm_host.h
> @@ -84,6 +84,7 @@ struct kvm_arch {
>  
>  	/* Never used on arm but added to be compatible with arm64 */
>  	struct list_head nested_mmu_list;
> +	spinlock_t mmu_list_lock;
>  
>  	/* Interrupt controller */
>  	struct vgic_dist	vgic;
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index 147df97..6fa5754 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -147,6 +147,7 @@ int kvm_arch_init_vm(struct kvm *kvm, unsigned long type)
>  	kvm->arch.mmu.vmid.vmid_gen = 0;
>  	kvm->arch.mmu.el2_vmid.vmid_gen = 0;
>  	INIT_LIST_HEAD(&kvm->arch.nested_mmu_list);
> +	spin_lock_init(&kvm->arch.mmu_list_lock);
>  
>  	/* The maximum number of VCPUs is limited by the host's GIC model */
>  	kvm->arch.max_vcpus = vgic_present ?
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 23e2267..52eea76 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -99,6 +99,7 @@ struct kvm_arch {
>  
>  	/* Stage 2 shadow paging contexts for nested L2 VM */
>  	struct list_head nested_mmu_list;
> +	spinlock_t mmu_list_lock;

I'm wondering if we really need the separate spin lock or if we could
just grab the KVM mutex?

>  };
>  
>  #define KVM_NR_MEM_OBJS     40
> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
> index d1ef650..fdc9327 100644
> --- a/arch/arm64/include/asm/kvm_mmu.h
> +++ b/arch/arm64/include/asm/kvm_mmu.h
> @@ -327,6 +327,7 @@ static inline unsigned int kvm_get_vmid_bits(void)
>  #ifdef CONFIG_KVM_ARM_NESTED_HYP
>  struct kvm_nested_s2_mmu *get_nested_mmu(struct kvm_vcpu *vcpu, u64 vttbr);
>  struct kvm_s2_mmu *vcpu_get_active_s2_mmu(struct kvm_vcpu *vcpu);
> +bool handle_vttbr_update(struct kvm_vcpu *vcpu, u64 vttbr);
>  #else
>  static inline struct kvm_nested_s2_mmu *get_nested_mmu(struct kvm_vcpu *vcpu,
>  						       u64 vttbr)
> @@ -337,6 +338,11 @@ static inline struct kvm_s2_mmu *vcpu_get_active_s2_mmu(struct kvm_vcpu *vcpu)
>  {
>  	return &vcpu->kvm->arch.mmu;
>  }
> +
> +static inline bool handle_vttbr_update(struct kvm_vcpu *vcpu, u64 vttbr)
> +{
> +	return false;
> +}
>  #endif
>  
>  static inline u64 kvm_get_vttbr(struct kvm_s2_vmid *vmid,
> diff --git a/arch/arm64/kvm/mmu-nested.c b/arch/arm64/kvm/mmu-nested.c
> index d52078f..0811d94 100644
> --- a/arch/arm64/kvm/mmu-nested.c
> +++ b/arch/arm64/kvm/mmu-nested.c
> @@ -53,3 +53,74 @@ struct kvm_s2_mmu *vcpu_get_active_s2_mmu(struct kvm_vcpu *vcpu)
>  
>  	return &nested_mmu->mmu;
>  }
> +
> +static struct kvm_nested_s2_mmu *create_nested_mmu(struct kvm_vcpu *vcpu,
> +						   u64 vttbr)
> +{
> +	struct kvm_nested_s2_mmu *nested_mmu, *tmp_mmu;
> +	struct list_head *nested_mmu_list = &vcpu->kvm->arch.nested_mmu_list;
> +	bool need_free = false;
> +	int ret;
> +
> +	nested_mmu = kzalloc(sizeof(struct kvm_nested_s2_mmu), GFP_KERNEL);
> +	if (!nested_mmu)
> +		return NULL;
> +
> +	ret = __kvm_alloc_stage2_pgd(&nested_mmu->mmu);
> +	if (ret) {
> +		kfree(nested_mmu);
> +		return NULL;
> +	}
> +
> +	spin_lock(&vcpu->kvm->arch.mmu_list_lock);
> +	tmp_mmu = get_nested_mmu(vcpu, vttbr);
> +	if (!tmp_mmu)
> +		list_add_rcu(&nested_mmu->list, nested_mmu_list);
> +	else /* Somebody already created and put a new nested_mmu to the list */
> +		need_free = true;
> +	spin_unlock(&vcpu->kvm->arch.mmu_list_lock);
> +
> +	if (need_free) {
> +		__kvm_free_stage2_pgd(&nested_mmu->mmu);
> +		kfree(nested_mmu);
> +		nested_mmu = tmp_mmu;
> +	}
> +
> +	return nested_mmu;
> +}
> +
> +static void kvm_nested_s2_unmap(struct kvm_vcpu *vcpu)
> +{
> +	struct kvm_nested_s2_mmu *nested_mmu;
> +	struct list_head *nested_mmu_list = &vcpu->kvm->arch.nested_mmu_list;
> +
> +	list_for_each_entry_rcu(nested_mmu, nested_mmu_list, list)
> +		kvm_unmap_stage2_range(&nested_mmu->mmu, 0, KVM_PHYS_SIZE);
> +}
> +
> +bool handle_vttbr_update(struct kvm_vcpu *vcpu, u64 vttbr)
> +{
> +	struct kvm_nested_s2_mmu *nested_mmu;
> +
> +	/* See if we can relax this */

huh?

> +	if (!vttbr)

why is this a special case?

Theoretically an IPA of zero and VMID zero could be a valid page table
base pointer, right?

I'm gussing because the guest hypervisor occasionally writes zero into
VTTBR_EL2, for example when not using stage 2 translation, so perhaps
what you need to do is to defer creating a new nested mmu structure
until you actually enter the VM with stage 2 paging enabled?

> +		return true;
> +
> +	nested_mmu = (struct kvm_nested_s2_mmu *)get_nested_mmu(vcpu, vttbr);
> +	if (!nested_mmu) {
> +		nested_mmu = create_nested_mmu(vcpu, vttbr);
> +		if (!nested_mmu)
> +			return false;

I'm wondering if this can be simplified by having get_nested_mmu lookup
and allocate the struct and renaming the get_nested_mmu funtion to
lookup_nested_mmu?  This caller looks racy, even though it isn't, which
would be improved by my suggestion as well.

> +	} else {
> +		/*
> +		 * unmap the shadow page table if vttbr_el2 is

While the function is called unmap, what we really do is
clearing/flushing the shadow stage 2 page table.

> +		 * changed to different value
> +		 */
> +		if (vttbr != nested_mmu->virtual_vttbr)
> +			kvm_nested_s2_unmap(vcpu);
> +	}
> +
> +	nested_mmu->virtual_vttbr = vttbr;
> +
> +	return true;
> +}
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index e66f40d..ddb641c 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -960,6 +960,19 @@ static bool access_cpacr(struct kvm_vcpu *vcpu,
>  	return true;
>  }
>  
> +static bool access_vttbr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
> +			 const struct sys_reg_desc *r)
> +{
> +	u64 vttbr = p->regval;
> +
> +	if (!p->is_write) {
> +		p->regval = vcpu_el2_reg(vcpu, r->reg);
> +		return true;
> +	}
> +
> +	return handle_vttbr_update(vcpu, vttbr);
> +}
> +
>  static bool trap_el2_reg(struct kvm_vcpu *vcpu,
>  			 struct sys_reg_params *p,
>  			 const struct sys_reg_desc *r)
> @@ -1306,7 +1319,7 @@ static bool trap_el2_reg(struct kvm_vcpu *vcpu,
>  	  trap_el2_reg, reset_el2_val, TCR_EL2, 0 },
>  	/* VTTBR_EL2 */
>  	{ Op0(0b11), Op1(0b100), CRn(0b0010), CRm(0b0001), Op2(0b000),
> -	  trap_el2_reg, reset_el2_val, VTTBR_EL2, 0 },
> +	  access_vttbr, reset_el2_val, VTTBR_EL2, 0 },
>  	/* VTCR_EL2 */
>  	{ Op0(0b11), Op1(0b100), CRn(0b0010), CRm(0b0001), Op2(0b010),
>  	  trap_el2_reg, reset_el2_val, VTCR_EL2, 0 },
> -- 
> 1.9.1
> 
> 

Thanks,
-Christoffer

  reply	other threads:[~2017-02-22 18:07 UTC|newest]

Thread overview: 111+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-09  6:23 [RFC 00/55] Nested Virtualization on KVM/ARM Jintack Lim
2017-01-09  6:23 ` [RFC 01/55] arm64: Add missing TCR hw defines Jintack Lim
2017-01-09  6:23 ` [RFC 02/55] KVM: arm64: Add nesting config option Jintack Lim
2017-01-09  6:23 ` [RFC 03/55] KVM: arm64: Add KVM nesting feature Jintack Lim
2017-01-09  6:24 ` [RFC 04/55] KVM: arm64: Allow userspace to set PSR_MODE_EL2x Jintack Lim
2017-01-09  6:24 ` [RFC 05/55] KVM: arm64: Add vcpu_mode_el2 primitive to support nesting Jintack Lim
2017-01-09  6:24 ` [RFC 06/55] KVM: arm64: Add EL2 execution context for nesting Jintack Lim
2017-02-22 11:10   ` Christoffer Dall
2017-06-26 14:33     ` Jintack Lim
2017-07-03  9:03       ` Christoffer Dall
2017-07-03  9:32         ` Marc Zyngier
2017-07-03  9:54           ` Christoffer Dall
2017-07-03 14:44             ` Jintack Lim
2017-07-03 15:30               ` Christoffer Dall
2017-01-09  6:24 ` [RFC 07/55] KVM: arm/arm64: Add virtual EL2 state emulation framework Jintack Lim
2017-02-22 11:12   ` Christoffer Dall
2017-06-01 20:05   ` Bandan Das
2017-06-02 11:51     ` Christoffer Dall
2017-06-02 17:36       ` Bandan Das
2017-06-02 19:06         ` Christoffer Dall
2017-06-02 19:25           ` Bandan Das
2017-01-09  6:24 ` [RFC 08/55] KVM: arm64: Set virtual EL2 context depending on the guest exception level Jintack Lim
2017-02-22 11:14   ` Christoffer Dall
2017-06-01 20:22   ` Bandan Das
2017-06-02  8:48     ` Marc Zyngier
2017-01-09  6:24 ` [RFC 09/55] KVM: arm64: Set shadow EL1 registers for virtual EL2 execution Jintack Lim
2017-02-22 11:19   ` Christoffer Dall
2017-01-09  6:24 ` [RFC 10/55] KVM: arm64: Synchronize EL1 system registers on virtual EL2 entry and exit Jintack Lim
2017-06-06 20:16   ` Bandan Das
2017-06-07  4:26     ` Jintack Lim
2017-01-09  6:24 ` [RFC 11/55] KVM: arm64: Emulate taking an exception to the guest hypervisor Jintack Lim
2017-02-22 11:28   ` Christoffer Dall
2017-06-06 20:21   ` Bandan Das
2017-06-06 20:38     ` Jintack Lim
2017-06-06 22:07       ` Bandan Das
2017-06-06 23:16         ` Jintack Lim
2017-06-07 17:21           ` Bandan Das
2017-01-09  6:24 ` [RFC 12/55] KVM: arm64: Handle EL2 register access traps Jintack Lim
2017-02-22 11:30   ` Christoffer Dall
2017-02-22 11:31   ` Christoffer Dall
2017-01-09  6:24 ` [RFC 13/55] KVM: arm64: Handle eret instruction traps Jintack Lim
2017-01-09  6:24 ` [RFC 14/55] KVM: arm64: Take account of system " Jintack Lim
2017-02-22 11:34   ` Christoffer Dall
2017-01-09  6:24 ` [RFC 15/55] KVM: arm64: Trap EL1 VM register accesses in virtual EL2 Jintack Lim
2017-01-09  6:24 ` [RFC 16/55] KVM: arm64: Forward VM reg traps to the guest hypervisor Jintack Lim
2017-02-22 11:39   ` Christoffer Dall
2017-01-09  6:24 ` [RFC 17/55] KVM: arm64: Trap SPSR_EL1, ELR_EL1 and VBAR_EL1 in virtual EL2 Jintack Lim
2017-02-22 11:40   ` Christoffer Dall
2017-01-09  6:24 ` [RFC 18/55] KVM: arm64: Forward traps due to HCR_EL2.NV1 bit to the guest hypervisor Jintack Lim
2017-02-22 11:41   ` Christoffer Dall
2017-01-09  6:24 ` [RFC 19/55] KVM: arm64: Trap CPACR_EL1 access in virtual EL2 Jintack Lim
2017-01-09  6:24 ` [RFC 20/55] KVM: arm64: Forward CPACR_EL1 traps to the guest hypervisor Jintack Lim
2017-01-09  6:24 ` [RFC 21/55] KVM: arm64: Forward HVC instruction " Jintack Lim
2017-02-22 11:47   ` Christoffer Dall
2017-06-26 15:21     ` Jintack Lim
2017-07-03  9:08       ` Christoffer Dall
2017-07-03  9:31         ` Andrew Jones
2017-07-03  9:51           ` Christoffer Dall
2017-07-03 12:03             ` Will Deacon
2017-07-03 12:35               ` Marc Zyngier
2017-07-03 13:29         ` Jintack Lim
2017-01-09  6:24 ` [RFC 22/55] KVM: arm64: Handle PSCI call from the guest Jintack Lim
2017-01-09  6:24 ` [RFC 23/55] KVM: arm64: Forward WFX to the guest hypervisor Jintack Lim
2017-01-09  6:24 ` [RFC 24/55] KVM: arm64: Forward FP exceptions " Jintack Lim
2017-01-09  6:24 ` [RFC 25/55] KVM: arm/arm64: Let vcpu thread modify its own active state Jintack Lim
2017-02-22 12:27   ` Christoffer Dall
2017-01-09  6:24 ` [RFC 26/55] KVM: arm/arm64: Add VGIC data structures for the nesting Jintack Lim
2017-01-09  6:24 ` [RFC 27/55] KVM: arm/arm64: Emulate GICH interface on GICv2 Jintack Lim
2017-02-22 13:06   ` Christoffer Dall
2017-01-09  6:24 ` [RFC 28/55] KVM: arm/arm64: Prepare vgic state for the nested VM Jintack Lim
2017-02-22 13:12   ` Christoffer Dall
2017-01-09  6:24 ` [RFC 29/55] KVM: arm/arm64: Set up the prepared vgic state Jintack Lim
2017-01-09  6:24 ` [RFC 30/55] KVM: arm/arm64: Inject irqs to the guest hypervisor Jintack Lim
2017-02-22 13:16   ` Christoffer Dall
2017-01-09  6:24 ` [RFC 31/55] KVM: arm/arm64: Inject maintenance interrupts " Jintack Lim
2017-02-22 13:19   ` Christoffer Dall
2017-01-09  6:24 ` [RFC 32/55] KVM: arm/arm64: register GICH iodev for " Jintack Lim
2017-02-22 13:21   ` Christoffer Dall
2017-01-09  6:24 ` [RFC 33/55] KVM: arm/arm64: Remove unused params in mmu functions Jintack Lim
2017-01-09  6:24 ` [RFC 34/55] KVM: arm/arm64: Abstract stage-2 MMU state into a separate structure Jintack Lim
2017-01-09  6:24 ` [RFC 35/55] KVM: arm/arm64: Support mmu for the virtual EL2 execution Jintack Lim
2017-02-22 13:38   ` Christoffer Dall
2017-01-09  6:24 ` [RFC 36/55] KVM: arm64: Invalidate virtual EL2 TLB entries when needed Jintack Lim
2017-01-09  6:24 ` [RFC 37/55] KVM: arm64: Setup vttbr_el2 on each VM entry Jintack Lim
2017-01-09  6:24 ` [RFC 38/55] KVM: arm/arm64: Make mmu functions non-static Jintack Lim
2017-01-09  6:24 ` [RFC 39/55] KVM: arm/arm64: Add mmu context for the nesting Jintack Lim
2017-02-22 13:34   ` Christoffer Dall
2017-01-09  6:24 ` [RFC 40/55] KVM: arm/arm64: Handle vttbr_el2 write operation from the guest hypervisor Jintack Lim
2017-02-22 17:59   ` Christoffer Dall [this message]
2017-01-09  6:24 ` [RFC 41/55] KVM: arm/arm64: Unmap/flush shadow stage 2 page tables Jintack Lim
2017-02-22 18:09   ` Christoffer Dall
2017-01-09  6:24 ` [RFC 42/55] KVM: arm64: Implement nested Stage-2 page table walk logic Jintack Lim
2017-01-09  6:24 ` [RFC 43/55] KVM: arm/arm64: Handle shadow stage 2 page faults Jintack Lim
2017-01-09  6:24 ` [RFC 44/55] KVM: arm/arm64: Move kvm_is_write_fault to header file Jintack Lim
2017-01-09  6:24 ` [RFC 45/55] KVM: arm64: KVM: Inject stage-2 page faults Jintack Lim
2017-01-09  6:24 ` [RFC 46/55] KVM: arm64: Add more info to the S2 translation result Jintack Lim
2017-01-09  6:24 ` [RFC 47/55] KVM: arm/arm64: Forward the guest hypervisor's stage 2 permission faults Jintack Lim
2017-02-22 18:15   ` Christoffer Dall
2017-01-09  6:24 ` [RFC 48/55] KVM: arm64: Emulate TLBI instruction Jintack Lim
2017-01-09  6:24 ` [RFC 49/55] KVM: arm64: Fixes to toggle_cache for nesting Jintack Lim
2017-01-09  6:24 ` [RFC 50/55] KVM: arm/arm64: Abstract kvm_phys_addr_ioremap() function Jintack Lim
2017-01-09  6:24 ` [RFC 51/55] KVM: arm64: Expose physical address of vcpu interface Jintack Lim
2017-01-09  6:24 ` [RFC 52/55] KVM: arm/arm64: Create a vcpu mapping for the nested VM Jintack Lim
2017-01-09  6:24 ` [RFC 53/55] KVM: arm64: Reflect shadow VMPIDR_EL2 value to MPIDR_EL1 Jintack Lim
2017-01-09  6:24 ` [RFC 54/55] KVM: arm/arm64: Adjust virtual offset considering nesting Jintack Lim
2017-02-22 19:28   ` Christoffer Dall
2017-01-09  6:24 ` [RFC 55/55] KVM: arm64: Enable nested virtualization Jintack Lim
2017-01-09 15:05 ` [RFC 00/55] Nested Virtualization on KVM/ARM David Hildenbrand
2017-01-10 16:18   ` Jintack Lim
2017-02-22 18:23 ` Christoffer Dall
2017-02-24 10:28   ` Jintack Lim

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170222175946.GV26976@cbox \
    --to=cdall@linaro.org \
    --cc=andre.przywara@arm.com \
    --cc=anna-maria@linutronix.de \
    --cc=catalin.marinas@arm.com \
    --cc=christoffer.dall@linaro.org \
    --cc=eric.auger@redhat.com \
    --cc=geoff@infradead.org \
    --cc=james.morse@arm.com \
    --cc=jintack@cs.columbia.edu \
    --cc=kevin.brodsky@arm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=marc.zyngier@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=pbonzini@redhat.com \
    --cc=rkrcmar@redhat.com \
    --cc=shankerd@codeaurora.org \
    --cc=shihwei@cs.columbia.edu \
    --cc=suzuki.poulose@arm.com \
    --cc=vladimir.murzin@arm.com \
    --cc=wcohen@redhat.com \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).