From: Andre Przywara <andre.przywara@arm.com>
To: Marc Zyngier <maz@kernel.org>
Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Alexandru Elisei <alexandru.elisei@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Christoffer Dall <christoffer.dall@arm.com>,
Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com>,
Russell King <rmk+kernel@armlinux.org.uk>,
James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Oliver Upton <oliver.upton@linux.dev>,
Zenghui Yu <yuzenghui@huawei.com>
Subject: Re: [PATCH 02/18] KVM: arm64: Use the S2 MMU context to iterate over S2 table
Date: Sat, 11 Feb 2023 01:00:19 +0000 [thread overview]
Message-ID: <20230211010019.1ccb6855@slackpad.lan> (raw)
In-Reply-To: <20230209175820.1939006-3-maz@kernel.org>
On Thu, 9 Feb 2023 17:58:04 +0000
Marc Zyngier <maz@kernel.org> wrote:
> Most of our S2 helpers take a kvm_s2_mmu pointer, but quickly
> revert back to using the kvm structure. By doing so, we lose
> track of which S2 MMU context we were initially using, and fallback
> to the "canonical" context.
>
> If we were trying to unmap a S2 context managed by a guest hypervisor,
> we end-up parsing the wrong set of page tables, and bad stuff happens
> (as this is often happening on the back of a trapped TLBI from the
> guest hypervisor).
>
> Instead, make sure we always use the provided MMU context all the way.
> This has no impact on non-NV, as we always pass the canonical MMU
> context.
Indeed this just changes stage2_apply_range() and all its callers, in
a manner that shouldn't change the current behaviour, but preserves the
S2 MMU passed in:
> Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Cheers,
Andre
> ---
> arch/arm64/kvm/mmu.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index a3ee3b605c9b..892d6a5fb2f5 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -46,16 +46,17 @@ static phys_addr_t stage2_range_addr_end(phys_addr_t addr, phys_addr_t end)
> * long will also starve other vCPUs. We have to also make sure that the page
> * tables are not freed while we released the lock.
> */
> -static int stage2_apply_range(struct kvm *kvm, phys_addr_t addr,
> +static int stage2_apply_range(struct kvm_s2_mmu *mmu, phys_addr_t addr,
> phys_addr_t end,
> int (*fn)(struct kvm_pgtable *, u64, u64),
> bool resched)
> {
> + struct kvm *kvm = kvm_s2_mmu_to_kvm(mmu);
> int ret;
> u64 next;
>
> do {
> - struct kvm_pgtable *pgt = kvm->arch.mmu.pgt;
> + struct kvm_pgtable *pgt = mmu->pgt;
> if (!pgt)
> return -EINVAL;
>
> @@ -71,8 +72,8 @@ static int stage2_apply_range(struct kvm *kvm, phys_addr_t addr,
> return ret;
> }
>
> -#define stage2_apply_range_resched(kvm, addr, end, fn) \
> - stage2_apply_range(kvm, addr, end, fn, true)
> +#define stage2_apply_range_resched(mmu, addr, end, fn) \
> + stage2_apply_range(mmu, addr, end, fn, true)
>
> static bool memslot_is_logging(struct kvm_memory_slot *memslot)
> {
> @@ -235,7 +236,7 @@ static void __unmap_stage2_range(struct kvm_s2_mmu *mmu, phys_addr_t start, u64
>
> lockdep_assert_held_write(&kvm->mmu_lock);
> WARN_ON(size & ~PAGE_MASK);
> - WARN_ON(stage2_apply_range(kvm, start, end, kvm_pgtable_stage2_unmap,
> + WARN_ON(stage2_apply_range(mmu, start, end, kvm_pgtable_stage2_unmap,
> may_block));
> }
>
> @@ -250,7 +251,7 @@ static void stage2_flush_memslot(struct kvm *kvm,
> phys_addr_t addr = memslot->base_gfn << PAGE_SHIFT;
> phys_addr_t end = addr + PAGE_SIZE * memslot->npages;
>
> - stage2_apply_range_resched(kvm, addr, end, kvm_pgtable_stage2_flush);
> + stage2_apply_range_resched(&kvm->arch.mmu, addr, end, kvm_pgtable_stage2_flush);
> }
>
> /**
> @@ -934,8 +935,7 @@ int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa,
> */
> static void stage2_wp_range(struct kvm_s2_mmu *mmu, phys_addr_t addr, phys_addr_t end)
> {
> - struct kvm *kvm = kvm_s2_mmu_to_kvm(mmu);
> - stage2_apply_range_resched(kvm, addr, end, kvm_pgtable_stage2_wrprotect);
> + stage2_apply_range_resched(mmu, addr, end, kvm_pgtable_stage2_wrprotect);
> }
>
> /**
WARNING: multiple messages have this Message-ID (diff)
From: Andre Przywara <andre.przywara@arm.com>
To: Marc Zyngier <maz@kernel.org>
Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Alexandru Elisei <alexandru.elisei@arm.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Christoffer Dall <christoffer.dall@arm.com>,
Ganapatrao Kulkarni <gankulkarni@os.amperecomputing.com>,
Russell King <rmk+kernel@armlinux.org.uk>,
James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Oliver Upton <oliver.upton@linux.dev>,
Zenghui Yu <yuzenghui@huawei.com>
Subject: Re: [PATCH 02/18] KVM: arm64: Use the S2 MMU context to iterate over S2 table
Date: Sat, 11 Feb 2023 01:00:19 +0000 [thread overview]
Message-ID: <20230211010019.1ccb6855@slackpad.lan> (raw)
In-Reply-To: <20230209175820.1939006-3-maz@kernel.org>
On Thu, 9 Feb 2023 17:58:04 +0000
Marc Zyngier <maz@kernel.org> wrote:
> Most of our S2 helpers take a kvm_s2_mmu pointer, but quickly
> revert back to using the kvm structure. By doing so, we lose
> track of which S2 MMU context we were initially using, and fallback
> to the "canonical" context.
>
> If we were trying to unmap a S2 context managed by a guest hypervisor,
> we end-up parsing the wrong set of page tables, and bad stuff happens
> (as this is often happening on the back of a trapped TLBI from the
> guest hypervisor).
>
> Instead, make sure we always use the provided MMU context all the way.
> This has no impact on non-NV, as we always pass the canonical MMU
> context.
Indeed this just changes stage2_apply_range() and all its callers, in
a manner that shouldn't change the current behaviour, but preserves the
S2 MMU passed in:
> Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Cheers,
Andre
> ---
> arch/arm64/kvm/mmu.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index a3ee3b605c9b..892d6a5fb2f5 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -46,16 +46,17 @@ static phys_addr_t stage2_range_addr_end(phys_addr_t addr, phys_addr_t end)
> * long will also starve other vCPUs. We have to also make sure that the page
> * tables are not freed while we released the lock.
> */
> -static int stage2_apply_range(struct kvm *kvm, phys_addr_t addr,
> +static int stage2_apply_range(struct kvm_s2_mmu *mmu, phys_addr_t addr,
> phys_addr_t end,
> int (*fn)(struct kvm_pgtable *, u64, u64),
> bool resched)
> {
> + struct kvm *kvm = kvm_s2_mmu_to_kvm(mmu);
> int ret;
> u64 next;
>
> do {
> - struct kvm_pgtable *pgt = kvm->arch.mmu.pgt;
> + struct kvm_pgtable *pgt = mmu->pgt;
> if (!pgt)
> return -EINVAL;
>
> @@ -71,8 +72,8 @@ static int stage2_apply_range(struct kvm *kvm, phys_addr_t addr,
> return ret;
> }
>
> -#define stage2_apply_range_resched(kvm, addr, end, fn) \
> - stage2_apply_range(kvm, addr, end, fn, true)
> +#define stage2_apply_range_resched(mmu, addr, end, fn) \
> + stage2_apply_range(mmu, addr, end, fn, true)
>
> static bool memslot_is_logging(struct kvm_memory_slot *memslot)
> {
> @@ -235,7 +236,7 @@ static void __unmap_stage2_range(struct kvm_s2_mmu *mmu, phys_addr_t start, u64
>
> lockdep_assert_held_write(&kvm->mmu_lock);
> WARN_ON(size & ~PAGE_MASK);
> - WARN_ON(stage2_apply_range(kvm, start, end, kvm_pgtable_stage2_unmap,
> + WARN_ON(stage2_apply_range(mmu, start, end, kvm_pgtable_stage2_unmap,
> may_block));
> }
>
> @@ -250,7 +251,7 @@ static void stage2_flush_memslot(struct kvm *kvm,
> phys_addr_t addr = memslot->base_gfn << PAGE_SHIFT;
> phys_addr_t end = addr + PAGE_SIZE * memslot->npages;
>
> - stage2_apply_range_resched(kvm, addr, end, kvm_pgtable_stage2_flush);
> + stage2_apply_range_resched(&kvm->arch.mmu, addr, end, kvm_pgtable_stage2_flush);
> }
>
> /**
> @@ -934,8 +935,7 @@ int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa,
> */
> static void stage2_wp_range(struct kvm_s2_mmu *mmu, phys_addr_t addr, phys_addr_t end)
> {
> - struct kvm *kvm = kvm_s2_mmu_to_kvm(mmu);
> - stage2_apply_range_resched(kvm, addr, end, kvm_pgtable_stage2_wrprotect);
> + stage2_apply_range_resched(mmu, addr, end, kvm_pgtable_stage2_wrprotect);
> }
>
> /**
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2023-02-11 1:02 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-09 17:58 [PATCH 00/18] KVM: arm64: Prefix patches for NV support Marc Zyngier
2023-02-09 17:58 ` Marc Zyngier
2023-02-09 17:58 ` [PATCH 01/18] arm64: Add ARM64_HAS_NESTED_VIRT cpufeature Marc Zyngier
2023-02-09 17:58 ` Marc Zyngier
2023-02-09 17:58 ` [PATCH 02/18] KVM: arm64: Use the S2 MMU context to iterate over S2 table Marc Zyngier
2023-02-09 17:58 ` Marc Zyngier
2023-02-11 1:00 ` Andre Przywara [this message]
2023-02-11 1:00 ` Andre Przywara
2023-02-09 17:58 ` [PATCH 03/18] KVM: arm64: nv: Introduce nested virtualization VCPU feature Marc Zyngier
2023-02-09 17:58 ` Marc Zyngier
2023-02-09 17:58 ` [PATCH 04/18] KVM: arm64: nv: Reset VCPU to EL2 registers if VCPU nested virt is set Marc Zyngier
2023-02-09 17:58 ` Marc Zyngier
2023-02-09 17:58 ` [PATCH 05/18] KVM: arm64: nv: Allow userspace to set PSR_MODE_EL2x Marc Zyngier
2023-02-09 17:58 ` Marc Zyngier
2023-02-09 17:58 ` [PATCH 06/18] KVM: arm64: nv: Add EL2 system registers to vcpu context Marc Zyngier
2023-02-09 17:58 ` Marc Zyngier
2023-02-09 17:58 ` [PATCH 07/18] KVM: arm64: nv: Add nested virt VCPU primitives for vEL2 VCPU state Marc Zyngier
2023-02-09 17:58 ` Marc Zyngier
2023-02-09 17:58 ` [PATCH 08/18] KVM: arm64: nv: Handle HCR_EL2.NV system register traps Marc Zyngier
2023-02-09 17:58 ` Marc Zyngier
2023-02-24 17:39 ` Joey Gouly
2023-02-24 17:39 ` Joey Gouly
2023-02-24 18:36 ` Oliver Upton
2023-02-24 18:36 ` Oliver Upton
2023-02-24 19:03 ` Marc Zyngier
2023-02-24 19:03 ` Marc Zyngier
2023-02-09 17:58 ` [PATCH 09/18] KVM: arm64: nv: Support virtual EL2 exceptions Marc Zyngier
2023-02-09 17:58 ` Marc Zyngier
2023-02-09 17:58 ` [PATCH 10/18] KVM: arm64: nv: Inject HVC exceptions to the virtual EL2 Marc Zyngier
2023-02-09 17:58 ` Marc Zyngier
2023-02-09 17:58 ` [PATCH 11/18] KVM: arm64: nv: Handle trapped ERET from " Marc Zyngier
2023-02-09 17:58 ` Marc Zyngier
2023-02-09 17:58 ` [PATCH 12/18] KVM: arm64: nv: Handle PSCI call via smc from the guest Marc Zyngier
2023-02-09 17:58 ` Marc Zyngier
2023-02-11 10:07 ` Oliver Upton
2023-02-11 10:07 ` Oliver Upton
2023-02-11 10:31 ` Marc Zyngier
2023-02-11 10:31 ` Marc Zyngier
2023-02-11 18:17 ` Oliver Upton
2023-02-11 18:17 ` Oliver Upton
2023-02-09 17:58 ` [PATCH 13/18] KVM: arm64: nv: Add accessors for SPSR_EL1, ELR_EL1 and VBAR_EL1 from virtual EL2 Marc Zyngier
2023-02-09 17:58 ` Marc Zyngier
2023-02-09 17:58 ` [PATCH 14/18] KVM: arm64: nv: Emulate PSTATE.M for a guest hypervisor Marc Zyngier
2023-02-09 17:58 ` Marc Zyngier
2023-02-09 17:58 ` [PATCH 15/18] KVM: arm64: nv: Allow a sysreg to be hidden from userspace only Marc Zyngier
2023-02-09 17:58 ` Marc Zyngier
2023-02-09 17:58 ` [PATCH 16/18] KVM: arm64: nv: Emulate EL12 register accesses from the virtual EL2 Marc Zyngier
2023-02-09 17:58 ` Marc Zyngier
2023-02-09 17:58 ` [PATCH 17/18] KVM: arm64: nv: Filter out unsupported features from ID regs Marc Zyngier
2023-02-09 17:58 ` Marc Zyngier
2023-02-09 17:58 ` [PATCH 18/18] KVM: arm64: nv: Only toggle cache for virtual EL2 when SCTLR_EL2 changes Marc Zyngier
2023-02-09 17:58 ` Marc Zyngier
2023-02-13 22:26 ` [PATCH 00/18] KVM: arm64: Prefix patches for NV support Oliver Upton
2023-02-13 22:26 ` Oliver Upton
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=20230211010019.1ccb6855@slackpad.lan \
--to=andre.przywara@arm.com \
--cc=alexandru.elisei@arm.com \
--cc=catalin.marinas@arm.com \
--cc=christoffer.dall@arm.com \
--cc=gankulkarni@os.amperecomputing.com \
--cc=james.morse@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=rmk+kernel@armlinux.org.uk \
--cc=suzuki.poulose@arm.com \
--cc=yuzenghui@huawei.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.