From: Marc Zyngier <maz@kernel.org>
To: Fuad Tabba <tabba@google.com>
Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
oliver.upton@linux.dev, james.clark@linaro.org, will@kernel.org,
joey.gouly@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com,
catalin.marinas@arm.com, broonie@kernel.org, qperret@google.com
Subject: Re: [PATCH v2 07/12] KVM: arm64: Rework specifying restricted features for protected VMs
Date: Sun, 24 Nov 2024 12:38:33 +0000 [thread overview]
Message-ID: <86jzcsvmba.wl-maz@kernel.org> (raw)
In-Reply-To: <20241122110622.3010118-8-tabba@google.com>
On Fri, 22 Nov 2024 11:06:17 +0000,
Fuad Tabba <tabba@google.com> wrote:
>
> The existing code didn't properly distinguish between signed and
> unsigned features, and was difficult to read and to maintain.
> Rework it using the same method used in other parts of KVM when
> handling vcpu features.
>
> Signed-off-by: Fuad Tabba <tabba@google.com>
> ---
> .../arm64/kvm/hyp/include/nvhe/fixed_config.h | 1 -
> arch/arm64/kvm/hyp/nvhe/sys_regs.c | 356 +++++++++---------
> 2 files changed, 186 insertions(+), 171 deletions(-)
>
> diff --git a/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h b/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h
> index 69e26d1a0ebe..37a6d2434e47 100644
> --- a/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h
> +++ b/arch/arm64/kvm/hyp/include/nvhe/fixed_config.h
> @@ -198,7 +198,6 @@
> FIELD_PREP(ARM64_FEATURE_MASK(ID_AA64ISAR2_EL1_APA3), ID_AA64ISAR2_EL1_APA3_PAuth) \
> )
>
> -u64 pvm_read_id_reg(const struct kvm_vcpu *vcpu, u32 id);
> bool kvm_handle_pvm_sysreg(struct kvm_vcpu *vcpu, u64 *exit_code);
> bool kvm_handle_pvm_restricted(struct kvm_vcpu *vcpu, u64 *exit_code);
> void kvm_init_pvm_id_regs(struct kvm_vcpu *vcpu);
> diff --git a/arch/arm64/kvm/hyp/nvhe/sys_regs.c b/arch/arm64/kvm/hyp/nvhe/sys_regs.c
> index 3aa76b018f70..cea3b099dc56 100644
> --- a/arch/arm64/kvm/hyp/nvhe/sys_regs.c
> +++ b/arch/arm64/kvm/hyp/nvhe/sys_regs.c
> @@ -28,221 +28,237 @@ u64 id_aa64mmfr1_el1_sys_val;
> u64 id_aa64mmfr2_el1_sys_val;
> u64 id_aa64smfr0_el1_sys_val;
>
> -/*
> - * Inject an unknown/undefined exception to an AArch64 guest while most of its
> - * sysregs are live.
> - */
> -static void inject_undef64(struct kvm_vcpu *vcpu)
> -{
> - u64 esr = (ESR_ELx_EC_UNKNOWN << ESR_ELx_EC_SHIFT);
> -
> - *vcpu_pc(vcpu) = read_sysreg_el2(SYS_ELR);
> - *vcpu_cpsr(vcpu) = read_sysreg_el2(SYS_SPSR);
> -
> - kvm_pend_exception(vcpu, EXCEPT_AA64_EL1_SYNC);
> -
> - __kvm_adjust_pc(vcpu);
> -
> - write_sysreg_el1(esr, SYS_ESR);
> - write_sysreg_el1(read_sysreg_el2(SYS_ELR), SYS_ELR);
> - write_sysreg_el2(*vcpu_pc(vcpu), SYS_ELR);
> - write_sysreg_el2(*vcpu_cpsr(vcpu), SYS_SPSR);
> -}
> +struct pvm_feature {
> + int shift;
> + int width;
> + u64 mask;
> + u64 max_supported;
> + bool is_signed;
Most of this is very similar to struct arm64_ftr_bits. Can you align
the types and names with it? And do you really need 'mask', which can
be derived from shift and width?
max_supported as an unsigned value is also potentially troublesome for
signed features. And does it need to be 64bit wide?
> + bool (*vcpu_supported)(const struct kvm_vcpu *vcpu);
We really need to find a way to kill this. The two features that stick
out badly are SVE and PAuth, and I don't see why we can't eventually
track them at the VM level instead (despite the userspace API).
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2024-11-24 12:39 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-22 11:06 [PATCH v2 00/12] KVM: arm64: Rework guest VM fixed feature handling and trapping in pKVM Fuad Tabba
2024-11-22 11:06 ` [PATCH v2 01/12] KVM: arm64: Consolidate allowed and restricted VM feature checks Fuad Tabba
2024-11-22 11:06 ` [PATCH v2 02/12] KVM: arm64: Group setting traps for protected VMs by control register Fuad Tabba
2024-11-22 11:06 ` [PATCH v2 03/12] KVM: arm64: Move checking protected vcpu features to a separate function Fuad Tabba
2024-11-22 11:06 ` [PATCH v2 04/12] KVM: arm64: Use KVM extension checks for allowed protected VM capabilities Fuad Tabba
2024-11-22 11:06 ` [PATCH v2 05/12] KVM: arm64: Initialize feature id registers for protected VMs Fuad Tabba
2024-11-24 12:12 ` Marc Zyngier
2024-11-25 11:58 ` Fuad Tabba
2024-11-22 11:06 ` [PATCH v2 06/12] KVM: arm64: Set protected VM traps based on its view of feature registers Fuad Tabba
2024-11-22 11:06 ` [PATCH v2 07/12] KVM: arm64: Rework specifying restricted features for protected VMs Fuad Tabba
2024-11-24 12:38 ` Marc Zyngier [this message]
2024-11-25 12:00 ` Fuad Tabba
2024-11-26 18:28 ` Kristina Martšenko
2024-11-27 9:06 ` Fuad Tabba
2024-11-22 11:06 ` [PATCH v2 08/12] KVM: arm64: Remove fixed_config.h header Fuad Tabba
2024-11-22 11:06 ` [PATCH v2 09/12] KVM: arm64: Remove redundant setting of HCR_EL2 trap bit Fuad Tabba
2024-11-22 11:06 ` [PATCH v2 10/12] KVM: arm64: Calculate cptr_el2 traps on activating traps Fuad Tabba
2024-11-22 11:06 ` [PATCH v2 11/12] KVM: arm64: Refactor kvm_reset_cptr_el2() Fuad Tabba
2024-11-22 11:06 ` [PATCH v2 12/12] KVM: arm64: Fix the value of the CPTR_EL2 RES1 bitmask for nVHE Fuad Tabba
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=86jzcsvmba.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=james.clark@linaro.org \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=oliver.upton@linux.dev \
--cc=qperret@google.com \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=will@kernel.org \
--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 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).