From: Christoffer Dall <cdall@linaro.org>
To: Jintack Lim <jintack@cs.columbia.edu>
Cc: kvm@vger.kernel.org, catalin.marinas@arm.com,
will.deacon@arm.com, kvmarm@lists.cs.columbia.edu,
shihwei@cs.columbia.edu, lorenzo.pieralisi@arm.com,
linux@armlinux.org.uk, linux-arm-kernel@lists.infradead.org,
marc.zyngier@arm.com, andre.przywara@arm.com,
kevin.brodsky@arm.com, wcohen@redhat.com,
anna-maria@linutronix.de, geoff@infradead.org,
linux-kernel@vger.kernel.org, pbonzini@redhat.com
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
WARNING: multiple messages have this Message-ID (diff)
From: cdall@linaro.org (Christoffer Dall)
To: linux-arm-kernel@lists.infradead.org
Subject: [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
WARNING: multiple messages have this Message-ID (diff)
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 17:59 UTC|newest]
Thread overview: 322+ 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 ` Jintack Lim
2017-01-09 6:23 ` Jintack Lim
2017-01-09 6:23 ` [RFC 01/55] arm64: Add missing TCR hw defines Jintack Lim
2017-01-09 6:23 ` Jintack Lim
2017-01-09 6:23 ` Jintack Lim
2017-01-09 6:23 ` [RFC 02/55] KVM: arm64: Add nesting config option Jintack Lim
2017-01-09 6:23 ` Jintack Lim
2017-01-09 6:23 ` Jintack Lim
2017-01-09 6:23 ` [RFC 03/55] KVM: arm64: Add KVM nesting feature Jintack Lim
2017-01-09 6:23 ` Jintack Lim
2017-01-09 6:23 ` 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 ` Jintack Lim
2017-01-09 6:24 ` 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 ` Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-01-09 6:24 ` [RFC 06/55] KVM: arm64: Add EL2 execution context for nesting Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-02-22 11:10 ` Christoffer Dall
2017-02-22 11:10 ` Christoffer Dall
2017-02-22 11:10 ` Christoffer Dall
2017-06-26 14:33 ` Jintack Lim
2017-06-26 14:33 ` Jintack Lim
2017-06-26 14:33 ` Jintack Lim
2017-07-03 9:03 ` Christoffer Dall
2017-07-03 9:03 ` Christoffer Dall
2017-07-03 9:03 ` Christoffer Dall
2017-07-03 9:32 ` Marc Zyngier
2017-07-03 9:32 ` Marc Zyngier
2017-07-03 9:32 ` Marc Zyngier
2017-07-03 9:54 ` Christoffer Dall
2017-07-03 9:54 ` Christoffer Dall
2017-07-03 9:54 ` Christoffer Dall
2017-07-03 14:44 ` Jintack Lim
2017-07-03 14:44 ` Jintack Lim
2017-07-03 14:44 ` Jintack Lim
2017-07-03 15:30 ` Christoffer Dall
2017-07-03 15:30 ` Christoffer Dall
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-01-09 6:24 ` Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-02-22 11:12 ` Christoffer Dall
2017-02-22 11:12 ` Christoffer Dall
2017-02-22 11:12 ` Christoffer Dall
2017-06-01 20:05 ` Bandan Das
2017-06-01 20:05 ` Bandan Das
2017-06-02 11:51 ` Christoffer Dall
2017-06-02 11:51 ` Christoffer Dall
2017-06-02 11:51 ` Christoffer Dall
2017-06-02 17:36 ` Bandan Das
2017-06-02 17:36 ` Bandan Das
2017-06-02 17:36 ` Bandan Das
2017-06-02 19:06 ` Christoffer Dall
2017-06-02 19:06 ` Christoffer Dall
2017-06-02 19:06 ` Christoffer Dall
2017-06-02 19:25 ` Bandan Das
2017-06-02 19:25 ` Bandan Das
2017-06-02 19:25 ` Bandan Das
[not found] ` <20170602194353.GG397@cbox>
2017-06-02 20:18 ` Bandan Das
2017-06-02 21:15 ` Christoffer Dall
2017-06-02 23:49 ` 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-01-09 6:24 ` Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-02-22 11:14 ` Christoffer Dall
2017-02-22 11:14 ` Christoffer Dall
2017-02-22 11:14 ` Christoffer Dall
2017-06-01 20:22 ` Bandan Das
2017-06-01 20:22 ` Bandan Das
2017-06-02 8:48 ` Marc Zyngier
2017-06-02 8:48 ` Marc Zyngier
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-01-09 6:24 ` Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-02-22 11:19 ` Christoffer Dall
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-01-09 6:24 ` Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-06-06 20:16 ` Bandan Das
2017-06-06 20:16 ` Bandan Das
2017-06-06 20:16 ` Bandan Das
2017-06-07 4:26 ` Jintack Lim
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-01-09 6:24 ` Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-02-22 11:28 ` Christoffer Dall
2017-02-22 11:28 ` Christoffer Dall
2017-02-22 11:28 ` Christoffer Dall
2017-06-06 20:21 ` Bandan Das
2017-06-06 20:21 ` Bandan Das
2017-06-06 20:21 ` Bandan Das
2017-06-06 20:38 ` Jintack Lim
2017-06-06 20:38 ` Jintack Lim
2017-06-06 22:07 ` Bandan Das
2017-06-06 22:07 ` Bandan Das
2017-06-06 23:16 ` Jintack Lim
2017-06-06 23:16 ` Jintack Lim
2017-06-06 23:16 ` Jintack Lim
2017-06-07 17:21 ` Bandan Das
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-01-09 6:24 ` Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-02-22 11:30 ` Christoffer Dall
2017-02-22 11:30 ` Christoffer Dall
2017-02-22 11:31 ` Christoffer Dall
2017-02-22 11:31 ` 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 ` Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-01-09 6:24 ` [RFC 14/55] KVM: arm64: Take account of system " Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-02-22 11:34 ` Christoffer Dall
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 ` Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-01-09 6:24 ` [RFC 16/55] KVM: arm64: Forward VM reg traps to the guest hypervisor Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-02-22 11:39 ` Christoffer Dall
2017-02-22 11:39 ` Christoffer Dall
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-01-09 6:24 ` Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-02-22 11:40 ` Christoffer Dall
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-01-09 6:24 ` Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-02-22 11:41 ` Christoffer Dall
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 ` Jintack Lim
2017-01-09 6:24 ` 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 ` Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-01-09 6:24 ` [RFC 21/55] KVM: arm64: Forward HVC instruction " Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-02-22 11:47 ` Christoffer Dall
2017-02-22 11:47 ` Christoffer Dall
2017-02-22 11:47 ` Christoffer Dall
2017-06-26 15:21 ` Jintack Lim
2017-06-26 15:21 ` Jintack Lim
2017-06-26 15:21 ` Jintack Lim
2017-07-03 9:08 ` Christoffer Dall
2017-07-03 9:08 ` Christoffer Dall
2017-07-03 9:08 ` Christoffer Dall
2017-07-03 9:31 ` Andrew Jones
2017-07-03 9:31 ` Andrew Jones
2017-07-03 9:31 ` Andrew Jones
2017-07-03 9:51 ` Christoffer Dall
2017-07-03 9:51 ` Christoffer Dall
2017-07-03 9:51 ` Christoffer Dall
2017-07-03 12:03 ` Will Deacon
2017-07-03 12:03 ` Will Deacon
2017-07-03 12:03 ` Will Deacon
2017-07-03 12:35 ` Marc Zyngier
2017-07-03 12:35 ` Marc Zyngier
2017-07-03 12:35 ` Marc Zyngier
2017-07-03 13:29 ` Jintack Lim
2017-07-03 13:29 ` Jintack Lim
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 ` Jintack Lim
2017-01-09 6:24 ` 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 ` Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-01-09 6:24 ` [RFC 24/55] KVM: arm64: Forward FP exceptions " Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-01-09 6:24 ` [RFC 25/55] KVM: arm/arm64: Let vcpu thread modify its own active state Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-02-22 12:27 ` Christoffer Dall
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 ` Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-01-09 6:24 ` [RFC 27/55] KVM: arm/arm64: Emulate GICH interface on GICv2 Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-02-22 13:06 ` Christoffer Dall
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-01-09 6:24 ` Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-02-22 13:12 ` Christoffer Dall
2017-02-22 13:12 ` Christoffer Dall
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 ` Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-01-09 6:24 ` [RFC 30/55] KVM: arm/arm64: Inject irqs to the guest hypervisor Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-02-22 13:16 ` Christoffer Dall
2017-02-22 13:16 ` Christoffer Dall
2017-01-09 6:24 ` [RFC 31/55] KVM: arm/arm64: Inject maintenance interrupts " Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-02-22 13:19 ` Christoffer Dall
2017-02-22 13:19 ` Christoffer Dall
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-01-09 6:24 ` Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-02-22 13:21 ` Christoffer Dall
2017-02-22 13:21 ` Christoffer Dall
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 ` Jintack Lim
2017-01-09 6:24 ` 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 ` Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-01-09 6:24 ` [RFC 35/55] KVM: arm/arm64: Support mmu for the virtual EL2 execution Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-02-22 13:38 ` Christoffer Dall
2017-02-22 13:38 ` Christoffer Dall
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 ` Jintack Lim
2017-01-09 6:24 ` 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 ` Jintack Lim
2017-01-09 6:24 ` 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 ` Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-01-09 6:24 ` [RFC 39/55] KVM: arm/arm64: Add mmu context for the nesting Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-02-22 13:34 ` Christoffer Dall
2017-02-22 13:34 ` Christoffer Dall
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-01-09 6:24 ` Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-02-22 17:59 ` Christoffer Dall [this message]
2017-02-22 17:59 ` Christoffer Dall
2017-02-22 17:59 ` Christoffer Dall
2017-01-09 6:24 ` [RFC 41/55] KVM: arm/arm64: Unmap/flush shadow stage 2 page tables Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-02-22 18:09 ` Christoffer Dall
2017-02-22 18:09 ` Christoffer Dall
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 ` Jintack Lim
2017-01-09 6:24 ` 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 ` Jintack Lim
2017-01-09 6:24 ` 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 ` Jintack Lim
2017-01-09 6:24 ` 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 ` Jintack Lim
2017-01-09 6:24 ` 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 ` Jintack Lim
2017-01-09 6:24 ` 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-01-09 6:24 ` Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-02-22 18:15 ` Christoffer Dall
2017-02-22 18:15 ` Christoffer Dall
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 ` Jintack Lim
2017-01-09 6:24 ` 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 ` Jintack Lim
2017-01-09 6:24 ` 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 ` Jintack Lim
2017-01-09 6:24 ` 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 ` Jintack Lim
2017-01-09 6:24 ` 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 ` Jintack Lim
2017-01-09 6:24 ` 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 ` Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-01-09 6:24 ` [RFC 54/55] KVM: arm/arm64: Adjust virtual offset considering nesting Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-02-22 19:28 ` Christoffer Dall
2017-02-22 19:28 ` Christoffer Dall
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 6:24 ` Jintack Lim
2017-01-09 6:24 ` Jintack Lim
2017-01-09 15:05 ` [RFC 00/55] Nested Virtualization on KVM/ARM David Hildenbrand
2017-01-09 15:05 ` David Hildenbrand
2017-01-10 16:18 ` Jintack Lim
2017-01-10 16:18 ` Jintack Lim
2017-01-10 16:18 ` Jintack Lim
2017-02-22 18:23 ` Christoffer Dall
2017-02-22 18:23 ` Christoffer Dall
2017-02-22 18:23 ` Christoffer Dall
2017-02-24 10:08 ` Jintack Lim
2017-02-24 10:28 ` Jintack Lim
2017-02-24 10:28 ` Jintack Lim
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=geoff@infradead.org \
--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=pbonzini@redhat.com \
--cc=shihwei@cs.columbia.edu \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.