Re: [PATCH v2 3/8] KVM: arm64: Consider SCTLR_EL2.M when mapping the L1 VNCR page

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Acquiring `mmu_lock` while preemption is disabled causes a 'sleeping in atomic context' BUG on PREEMPT_RT kernels.
--

--- Patch [3]: [PATCH v2 3/8] KVM: arm64: Consider SCTLR_EL2.M when mapping the L1 VNCR page ---
commit 20af1a04bc308d515b8afd3fe9909a21ff7706cb
Author: Marc Zyngier <[email protected]>

KVM: arm64: Consider SCTLR_EL2.M when mapping the L1 VNCR page

We record a VNCR TLB even when SCTLR_EL2.M is 0 in order to make
our life easier. But this is not something that the architecture
anticipate.

[ ... ]

> diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
> index b026d160f253d..939813aebaafa 100644
> --- a/arch/arm64/kvm/nested.c
> +++ b/arch/arm64/kvm/nested.c
> @@ -1579,6 +1579,10 @@ static void kvm_map_l1_vncr(struct kvm_vcpu *vcpu)

[Severity: High]
This is a pre-existing issue, but looking at the beginning of
kvm_map_l1_vncr():

static void kvm_map_l1_vncr(struct kvm_vcpu *vcpu)
{
	...
	guard(preempt)();
	guard(read_lock)(&vcpu->kvm->mmu_lock);
	...

Can acquiring mmu_lock while preemption is disabled cause a sleeping in
atomic context warning on PREEMPT_RT kernels?

Since rwlock_t is sleepable on RT, does this sequence need adjustment to
avoid panicking the host during nested virtualization execution?

>  	if (!vt->valid)
>  		return;
>  
> +	/* We cache the MMU state in the TLB. Check that it matches. */
> +	if (!!(vcpu_read_sys_reg(vcpu, SCTLR_EL2) & SCTLR_ELx_M) != s1_walk_translated(&vt->wr))
> +		return;
> +
>  	if (read_vncr_el2(vcpu) != vt->gva)
>  		return;
>

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=3