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
next prev parent 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).