From: Marc Zyngier <maz@kernel.org>
To: Quentin Perret <qperret@google.com>
Cc: catalin.marinas@arm.com, james.morse@arm.com,
julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com,
android-kvm@google.com, seanjc@google.com, mate.toth-pal@arm.com,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, kernel-team@android.com,
kvmarm@lists.cs.columbia.edu, tabba@google.com, ardb@kernel.org,
mark.rutland@arm.com, dbrazdil@google.com
Subject: [PATCH 0/3] KVM:arm64: Proposed host stage-2 improvements
Date: Mon, 22 Mar 2021 16:48:25 +0000 [thread overview]
Message-ID: <20210322164828.800662-1-maz@kernel.org> (raw)
Hi all,
Since Quentin's series is pretty close to final, I though that instead
of asking for additional rework, I'd have a go at it myself. These
patches try to bring some simplifications to the cpufeature
duplication that has been introduced between EL1 and EL2.
This whole infrastructure exists for a single reason: making the
*sanitised* versions of ID_AA64MMFR{0,1}_EL1 available to EL2. On top
of that, the read_ctr macro gets in the way as it needs direct access
to arm64_ftr_reg_ctrel0 to cope with ARM64_MISMATCHED_CACHE_TYPE.
This series tackles the latest point first by taking advantage of the
fact that with pKVM enabled, late CPUs aren't allowed to boot, and
thus that we know the final CTR_EL0 value before KVM starts, no matter
whether there is a mismatch or not. We can thus specialise read_ctr to
do the right thing without requiring access to the EL1 data structure.
Once that's sorted, we can easily simplify the whole infrastructure to
only snapshot the two u64 we need before enabling the protected mode.
Tested on a Synquacer system.
M.
Marc Zyngier (3):
KVM: arm64: Constraint KVM's own __flush_dcache_area to protectected
mode
KVM: arm64: Generate final CTR_EL0 value when running in Protected
mode
KVM: arm64: Drop the CPU_FTR_REG_HYP_COPY infrastructure
arch/arm64/include/asm/assembler.h | 9 +++++++++
arch/arm64/include/asm/cpufeature.h | 1 -
arch/arm64/include/asm/kvm_cpufeature.h | 26 -------------------------
arch/arm64/include/asm/kvm_host.h | 4 ----
arch/arm64/include/asm/kvm_hyp.h | 3 +++
arch/arm64/kernel/cpufeature.c | 13 -------------
arch/arm64/kernel/image-vars.h | 1 +
arch/arm64/kvm/hyp/nvhe/cache.S | 4 ++++
arch/arm64/kvm/hyp/nvhe/hyp-smp.c | 6 ++----
arch/arm64/kvm/hyp/nvhe/mem_protect.c | 5 ++---
arch/arm64/kvm/sys_regs.c | 23 ++--------------------
arch/arm64/kvm/va_layout.c | 7 +++++++
12 files changed, 30 insertions(+), 72 deletions(-)
delete mode 100644 arch/arm64/include/asm/kvm_cpufeature.h
--
2.29.2
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Quentin Perret <qperret@google.com>
Cc: android-kvm@google.com, catalin.marinas@arm.com,
mate.toth-pal@arm.com, tabba@google.com,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, seanjc@google.com,
kernel-team@android.com, kvmarm@lists.cs.columbia.edu
Subject: [PATCH 0/3] KVM:arm64: Proposed host stage-2 improvements
Date: Mon, 22 Mar 2021 16:48:25 +0000 [thread overview]
Message-ID: <20210322164828.800662-1-maz@kernel.org> (raw)
Hi all,
Since Quentin's series is pretty close to final, I though that instead
of asking for additional rework, I'd have a go at it myself. These
patches try to bring some simplifications to the cpufeature
duplication that has been introduced between EL1 and EL2.
This whole infrastructure exists for a single reason: making the
*sanitised* versions of ID_AA64MMFR{0,1}_EL1 available to EL2. On top
of that, the read_ctr macro gets in the way as it needs direct access
to arm64_ftr_reg_ctrel0 to cope with ARM64_MISMATCHED_CACHE_TYPE.
This series tackles the latest point first by taking advantage of the
fact that with pKVM enabled, late CPUs aren't allowed to boot, and
thus that we know the final CTR_EL0 value before KVM starts, no matter
whether there is a mismatch or not. We can thus specialise read_ctr to
do the right thing without requiring access to the EL1 data structure.
Once that's sorted, we can easily simplify the whole infrastructure to
only snapshot the two u64 we need before enabling the protected mode.
Tested on a Synquacer system.
M.
Marc Zyngier (3):
KVM: arm64: Constraint KVM's own __flush_dcache_area to protectected
mode
KVM: arm64: Generate final CTR_EL0 value when running in Protected
mode
KVM: arm64: Drop the CPU_FTR_REG_HYP_COPY infrastructure
arch/arm64/include/asm/assembler.h | 9 +++++++++
arch/arm64/include/asm/cpufeature.h | 1 -
arch/arm64/include/asm/kvm_cpufeature.h | 26 -------------------------
arch/arm64/include/asm/kvm_host.h | 4 ----
arch/arm64/include/asm/kvm_hyp.h | 3 +++
arch/arm64/kernel/cpufeature.c | 13 -------------
arch/arm64/kernel/image-vars.h | 1 +
arch/arm64/kvm/hyp/nvhe/cache.S | 4 ++++
arch/arm64/kvm/hyp/nvhe/hyp-smp.c | 6 ++----
arch/arm64/kvm/hyp/nvhe/mem_protect.c | 5 ++---
arch/arm64/kvm/sys_regs.c | 23 ++--------------------
arch/arm64/kvm/va_layout.c | 7 +++++++
12 files changed, 30 insertions(+), 72 deletions(-)
delete mode 100644 arch/arm64/include/asm/kvm_cpufeature.h
--
2.29.2
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Quentin Perret <qperret@google.com>
Cc: catalin.marinas@arm.com, james.morse@arm.com,
julien.thierry.kdev@gmail.com, suzuki.poulose@arm.com,
android-kvm@google.com, seanjc@google.com, mate.toth-pal@arm.com,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, kernel-team@android.com,
kvmarm@lists.cs.columbia.edu, tabba@google.com, ardb@kernel.org,
mark.rutland@arm.com, dbrazdil@google.com
Subject: [PATCH 0/3] KVM:arm64: Proposed host stage-2 improvements
Date: Mon, 22 Mar 2021 16:48:25 +0000 [thread overview]
Message-ID: <20210322164828.800662-1-maz@kernel.org> (raw)
Hi all,
Since Quentin's series is pretty close to final, I though that instead
of asking for additional rework, I'd have a go at it myself. These
patches try to bring some simplifications to the cpufeature
duplication that has been introduced between EL1 and EL2.
This whole infrastructure exists for a single reason: making the
*sanitised* versions of ID_AA64MMFR{0,1}_EL1 available to EL2. On top
of that, the read_ctr macro gets in the way as it needs direct access
to arm64_ftr_reg_ctrel0 to cope with ARM64_MISMATCHED_CACHE_TYPE.
This series tackles the latest point first by taking advantage of the
fact that with pKVM enabled, late CPUs aren't allowed to boot, and
thus that we know the final CTR_EL0 value before KVM starts, no matter
whether there is a mismatch or not. We can thus specialise read_ctr to
do the right thing without requiring access to the EL1 data structure.
Once that's sorted, we can easily simplify the whole infrastructure to
only snapshot the two u64 we need before enabling the protected mode.
Tested on a Synquacer system.
M.
Marc Zyngier (3):
KVM: arm64: Constraint KVM's own __flush_dcache_area to protectected
mode
KVM: arm64: Generate final CTR_EL0 value when running in Protected
mode
KVM: arm64: Drop the CPU_FTR_REG_HYP_COPY infrastructure
arch/arm64/include/asm/assembler.h | 9 +++++++++
arch/arm64/include/asm/cpufeature.h | 1 -
arch/arm64/include/asm/kvm_cpufeature.h | 26 -------------------------
arch/arm64/include/asm/kvm_host.h | 4 ----
arch/arm64/include/asm/kvm_hyp.h | 3 +++
arch/arm64/kernel/cpufeature.c | 13 -------------
arch/arm64/kernel/image-vars.h | 1 +
arch/arm64/kvm/hyp/nvhe/cache.S | 4 ++++
arch/arm64/kvm/hyp/nvhe/hyp-smp.c | 6 ++----
arch/arm64/kvm/hyp/nvhe/mem_protect.c | 5 ++---
arch/arm64/kvm/sys_regs.c | 23 ++--------------------
arch/arm64/kvm/va_layout.c | 7 +++++++
12 files changed, 30 insertions(+), 72 deletions(-)
delete mode 100644 arch/arm64/include/asm/kvm_cpufeature.h
--
2.29.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply other threads:[~2021-03-22 16:49 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-22 16:48 Marc Zyngier [this message]
2021-03-22 16:48 ` [PATCH 0/3] KVM:arm64: Proposed host stage-2 improvements Marc Zyngier
2021-03-22 16:48 ` Marc Zyngier
2021-03-22 16:48 ` [PATCH 1/3] KVM: arm64: Constraint KVM's own __flush_dcache_area to protectected mode Marc Zyngier
2021-03-22 16:48 ` Marc Zyngier
2021-03-22 16:48 ` Marc Zyngier
2021-03-22 16:48 ` [PATCH 2/3] KVM: arm64: Generate final CTR_EL0 value when running in Protected mode Marc Zyngier
2021-03-22 16:48 ` Marc Zyngier
2021-03-22 16:48 ` Marc Zyngier
2021-03-22 17:40 ` Quentin Perret
2021-03-22 17:40 ` Quentin Perret
2021-03-22 17:40 ` Quentin Perret
2021-03-22 18:37 ` Marc Zyngier
2021-03-22 18:37 ` Marc Zyngier
2021-03-22 18:37 ` Marc Zyngier
2021-03-23 9:47 ` Quentin Perret
2021-03-23 9:47 ` Quentin Perret
2021-03-23 9:47 ` Quentin Perret
2021-03-22 16:48 ` [PATCH 3/3] KVM: arm64: Drop the CPU_FTR_REG_HYP_COPY infrastructure Marc Zyngier
2021-03-22 16:48 ` Marc Zyngier
2021-03-22 16:48 ` Marc Zyngier
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=20210322164828.800662-1-maz@kernel.org \
--to=maz@kernel.org \
--cc=android-kvm@google.com \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=dbrazdil@google.com \
--cc=james.morse@arm.com \
--cc=julien.thierry.kdev@gmail.com \
--cc=kernel-team@android.com \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=mate.toth-pal@arm.com \
--cc=qperret@google.com \
--cc=seanjc@google.com \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.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.