All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] KVM: arm64: nv: Size nested stage-2 MMUs by the NV PARange cap
@ 2026-10-30 10:51 Fuad Tabba
  2026-10-30 11:09 ` sashiko-bot
  0 siblings, 1 reply; 7+ messages in thread
From: Fuad Tabba @ 2026-10-30 10:51 UTC (permalink / raw)
  To: Marc Zyngier, Oliver Upton
  Cc: Joey Gouly, Steffen Eiden, Suzuki K Poulose, Zenghui Yu,
	Catalin Marinas, Will Deacon, Mark Rutland, Christoffer Dall,
	Wei-Lin Chang, linux-arm-kernel, kvmarm, linux-kernel, Fuad Tabba

init_nested_s2_mmu()'s comment says nested stage-2 MMUs use the PARange
exposed to the guest, but it sizes them with kvm_get_pa_bits(), which
returns the host's IPA limit rather than the 48 bits limit_nv_id_reg()
caps an NV guest at.

On a 52-bit host, every TLBI ALLE1IS from the guest hypervisor then has
KVM unmap each valid nested stage-2 across a range 16 times the one the
guest can use. Under QEMU, the KVM init of an E2H0 guest hypervisor
doesn't complete within 20 minutes.

Make kvm_get_pa_bits() return the 48-bit cap for an NV VM. That also
bounds the nested walker's limits, the emulated TLBI ranges and AT's
address size checks.

Fixes: 4f128f8e1aaac ("KVM: arm64: nv: Support multiple nested Stage-2 mmu structures")
Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
---
The 48 is written here and in limit_nv_id_reg(). I couldn't derive it
from the VM's ID_AA64MMFR0_EL1, since the nested MMUs are created in
kvm_setup_vcpu(), before kvm_reset_vcpu() initialises the VM's ID
registers. Userspace can also lower PARange afterwards.

 arch/arm64/kvm/reset.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
index 10eb7249aa9e8..1918837757682 100644
--- a/arch/arm64/kvm/reset.c
+++ b/arch/arm64/kvm/reset.c
@@ -220,6 +220,10 @@ void kvm_reset_vcpu(struct kvm_vcpu *vcpu)
 
 u32 kvm_get_pa_bits(struct kvm *kvm)
 {
+	/* An NV guest's PARange is capped by limit_nv_id_reg() */
+	if (test_bit(KVM_ARM_VCPU_HAS_EL2, kvm->arch.vcpu_features))
+		return min(kvm_ipa_limit, 48U);
+
 	/* Fixed limit until we can configure ID_AA64MMFR0.PARange */
 	return kvm_ipa_limit;
 }
-- 
2.47.3


^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH] KVM: arm64: nv: Size nested stage-2 MMUs by the NV PARange cap
  2026-10-30 10:51 [PATCH] KVM: arm64: nv: Size nested stage-2 MMUs by the NV PARange cap Fuad Tabba
@ 2026-10-30 11:09 ` sashiko-bot
  2026-10-30 12:08   ` Fuad Tabba
  0 siblings, 1 reply; 7+ messages in thread
From: sashiko-bot @ 2026-10-30 11:09 UTC (permalink / raw)
  To: Fuad Tabba; +Cc: kvmarm, Oliver Upton, Marc Zyngier

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] KVM: arm64: nv: wrong fault injected in kvm_handle_guest_abort()
- [Medium] KVM: arm64: nv: uncapped max_oa_bits in setup_s1_walk()
--

commit 67127beccb09ede5294ce8bb377da5dd05338982
Author: Fuad Tabba <fuad.tabba@linux.dev>

KVM: arm64: nv: Size nested stage-2 MMUs by the NV PARange cap

This commit caps kvm_get_pa_bits() at 48 bits when KVM_ARM_VCPU_HAS_EL2 is
set on the VM so that nested stage-2 MMUs, emulated TLBI ranges, nested
page-table walks, and AT checks are sized to the PARange exposed to a
nested virtualization guest rather than the host IPA limit.

> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
> index 10eb7249aa9e8..1918837757682 100644
> --- a/arch/arm64/kvm/reset.c
> +++ b/arch/arm64/kvm/reset.c
> @@ -220,6 +220,10 @@ void kvm_reset_vcpu(struct kvm_vcpu *vcpu)
>  
>  u32 kvm_get_pa_bits(struct kvm *kvm)
>  {
> +	/* An NV guest's PARange is capped by limit_nv_id_reg() */
> +	if (test_bit(KVM_ARM_VCPU_HAS_EL2, kvm->arch.vcpu_features))
> +		return min(kvm_ipa_limit, 48U);

[Severity: Medium]
When kvm_get_pa_bits() caps an NV guest at 48 bits on a 52-bit host,
init_nested_s2_mmu() initializes the nested stage-2 MMU with a 48-bit IPA
limit (setting VTCR_EL2_IPA(mmu->vtcr) to 48), while get_kvm_ipa_limit()
remains 52.

In arch/arm64/kvm/mmu.c:kvm_handle_guest_abort(), the translation fault
handler still checks the faulting IPA against get_kvm_ipa_limit() before
checking VTCR_EL2_IPA(vcpu->arch.hw_mmu->vtcr):

	if (esr_fsc_is_translation_fault(esr)) {
		/* Beyond sanitised PARange (which is the IPA limit) */
		if (fault_ipa >= BIT_ULL(get_kvm_ipa_limit())) {
			kvm_inject_size_fault(vcpu);
			return 1;
		}

		/* Falls between the IPA range and the PARange? */
		if (fault_ipa >= BIT_ULL(VTCR_EL2_IPA(vcpu->arch.hw_mmu->vtcr))) {
			fault_ipa |= FAR_TO_FIPA_OFFSET(kvm_vcpu_get_hfar(vcpu));

			return kvm_inject_sea(vcpu, is_iabt, fault_ipa);
		}
	}

If an NV guest running with a nested stage-2 MMU (!is_hyp_ctxt(vcpu)) on a
52-bit host accesses an address in [2^48, 2^52) (for example, with the
stage-1 MMU disabled via SCTLR_EL1.M == 0 or HCR_EL2.DC == 1, or with
4K/16K LPA2 TCR_EL1.DS == 1 and IPS == 0b0110), hardware stage-1 will not
raise an address size fault because the physical CPU supports 52-bit PA,
and will instead raise a stage-2 level 0 translation fault against the
48-bit nested stage-2 MMU.

Because fault_ipa < BIT_ULL(get_kvm_ipa_limit()) (52) and
fault_ipa >= BIT_ULL(VTCR_EL2_IPA(vcpu->arch.hw_mmu->vtcr)) (48), won't
kvm_handle_guest_abort() fall through to kvm_inject_sea() and inject a
synchronous external abort into the guest instead of calling
kvm_inject_size_fault() to inject a stage-1 level 0 address size fault?

[Severity: Medium]
The commit message notes that capping kvm_get_pa_bits() at 48 bits also
bounds the nested walker's limits and AT's address size checks.

In arch/arm64/kvm/at.c:setup_s1_walk(), the MMU-disabled path checks
kvm_get_pa_bits(vcpu->kvm):

	if (wr->level == S1_MMU_DISABLED) {
		if (va >= BIT(kvm_get_pa_bits(vcpu->kvm)))
			goto addrsz;

However, the MMU-enabled path in setup_s1_walk() and the nested stage-2
walker in arch/arm64/kvm/nested.c:setup_s2_walk() still clamp max_oa_bits
using get_kvm_ipa_limit():

arch/arm64/kvm/at.c:setup_s1_walk():
	wi->max_oa_bits = min(get_kvm_ipa_limit(), ps_to_output_size(ps, wi->pa52bit));

arch/arm64/kvm/nested.c:setup_s2_walk():
	/* Global limit for now, should eventually be per-VM */
	wi->max_oa_bits = min(get_kvm_ipa_limit(),
			      ps_to_output_size(FIELD_GET(VTCR_EL2_PS_MASK, vtcr), false));

Because limit_nv_id_reg() caps ID_AA64MMFR0_EL1.PARANGE at 48 bits and
TGRAN4_2/TGRAN16_2 at IMP, but leaves stage-1 TGRAN4 and TGRAN16 at 52_BIT
on an LPA2 host, arch/arm64/kvm/at.c:has_52bit_pa() returns true when an
NV guest sets TCR_ELx.DS = 1 with 4K or 16K pages. When the guest also
sets TCR_ELx.PS/IPS = 0b0110, wi->max_oa_bits in setup_s1_walk() evaluates
to 52 instead of 48.

Should setup_s1_walk() and setup_s2_walk() use kvm_get_pa_bits(vcpu->kvm)
instead of get_kvm_ipa_limit() so that check_output_size() raises a
stage-1 address size fault for TTBR base addresses and descriptors with
bits [51:48] set rather than letting walk_s1() and __kvm_at_s12() truncate
those bits when passing the address to stage-2?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261030105139.3543230-1-fuad.tabba@linux.dev?part=1

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] KVM: arm64: nv: Size nested stage-2 MMUs by the NV PARange cap
  2026-10-30 11:09 ` sashiko-bot
@ 2026-10-30 12:08   ` Fuad Tabba
  2026-10-30 12:24     ` sashiko-bot
  2026-10-30 16:18     ` Wei-Lin Chang
  0 siblings, 2 replies; 7+ messages in thread
From: Fuad Tabba @ 2026-10-30 12:08 UTC (permalink / raw)
  To: sashiko-bot; +Cc: kvmarm, Oliver Upton, Marc Zyngier, Fuad Tabba

On Fri, 30 Oct 2026 11:09:43 +0000, sashiko-bot@kernel.org wrote:
[...]
> Because fault_ipa < BIT_ULL(get_kvm_ipa_limit()) (52) and
> fault_ipa >= BIT_ULL(VTCR_EL2_IPA(vcpu->arch.hw_mmu->vtcr)) (48), won't
> kvm_handle_guest_abort() fall through to kvm_inject_sea() and inject a
> synchronous external abort into the guest instead of calling
> kvm_inject_size_fault() to inject a stage-1 level 0 address size fault?

Yes. I'll fold this into v2:

diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 705f6d84770e9..2a05c7cf8552a 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -2440,8 +2440,8 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu)
 	is_iabt = esr_trap_is_iabt(esr);
 
 	if (esr_fsc_is_translation_fault(esr)) {
-		/* Beyond sanitised PARange (which is the IPA limit) */
-		if (fault_ipa >= BIT_ULL(get_kvm_ipa_limit())) {
+		/* Beyond sanitised PARange */
+		if (fault_ipa >= BIT_ULL(kvm_get_pa_bits(kvm))) {
 			kvm_inject_size_fault(vcpu);
 			return 1;
 		}

[...]
> Should setup_s1_walk() and setup_s2_walk() use kvm_get_pa_bits(vcpu->kvm)
> instead of get_kvm_ipa_limit() so that check_output_size() raises a
> stage-1 address size fault for TTBR base addresses and descriptors with
> bits [51:48] set rather than letting walk_s1() and __kvm_at_s12() truncate
> those bits when passing the address to stage-2?

No. setup_s2_walk() passes pa52bit=false, so its output size is
already at most 48. setup_s1_walk()'s output size can only exceed 48
because, on an LPA2 host, NV guests see stage-1 TGRAN4/TGRAN16 at
52_BIT, which Wei-Lin's patch [1] stops advertising.

Cheers,
/fuad

[1] https://lore.kernel.org/all/20261029223732.103785-2-oupton@kernel.org/

^ permalink raw reply related	[flat|nested] 7+ messages in thread

* Re: [PATCH] KVM: arm64: nv: Size nested stage-2 MMUs by the NV PARange cap
  2026-10-30 12:08   ` Fuad Tabba
@ 2026-10-30 12:24     ` sashiko-bot
  2026-10-30 12:28       ` Fuad Tabba
  2026-10-30 16:18     ` Wei-Lin Chang
  1 sibling, 1 reply; 7+ messages in thread
From: sashiko-bot @ 2026-10-30 12:24 UTC (permalink / raw)
  To: Fuad Tabba; +Cc: kvmarm, Oliver Upton, Marc Zyngier

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] KVM: arm64: nv: missing base changes in kvm_get_pa_bits() and reply changelog
--

commit f427a1e42f6e3dddeb1163b0cde7acfb4c92d8ef
Author: Fuad Tabba <fuad.tabba@linux.dev>

KVM: arm64: nv: Size nested stage-2 MMUs by the NV PARange cap

This commit replaces get_kvm_ipa_limit() with kvm_get_pa_bits(kvm) in
kvm_handle_guest_abort() when checking whether a translation fault IPA
exceeds the guest's PARange.

>     KVM: arm64: nv: Size nested stage-2 MMUs by the NV PARange cap
>     
>     On Fri, 30 Oct 2026 11:09:43 +0000, sashiko-bot@kernel.org wrote:
>     [...]
>     > Because fault_ipa < BIT_ULL(get_kvm_ipa_limit()) (52) and
>     > fault_ipa >= BIT_ULL(VTCR_EL2_IPA(vcpu->arch.hw_mmu->vtcr)) (48), won't
>     > kvm_handle_guest_abort() fall through to kvm_inject_sea() and inject a
>     > synchronous external abort into the guest instead of calling
>     > kvm_inject_size_fault() to inject a stage-1 level 0 address size fault?
>     
>     Yes. I'll fold this into v2:
> 
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 1db10d8d6db73..596b2b6ebbdf0 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -2440,8 +2440,8 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu)
>  	is_iabt = esr_trap_is_iabt(esr);
>  
>  	if (esr_fsc_is_translation_fault(esr)) {
> -		/* Beyond sanitised PARange (which is the IPA limit) */
> -		if (fault_ipa >= BIT_ULL(get_kvm_ipa_limit())) {
> +		/* Beyond sanitised PARange */
> +		if (fault_ipa >= BIT_ULL(kvm_get_pa_bits(kvm))) {
>  			kvm_inject_size_fault(vcpu);
>  			return 1;
>  		}

[Severity: Medium]
Was the incremental reply diff applied directly instead of being folded into
the base patch?

In arch/arm64/kvm/reset.c, kvm_get_pa_bits() is still unchanged and
unconditionally returns kvm_ipa_limit:

u32 kvm_get_pa_bits(struct kvm *kvm)
{
	/* Fixed limit until we can configure ID_AA64MMFR0.PARange */
	return kvm_ipa_limit;
}

Without the base changes to kvm_get_pa_bits() (and with the commit message
containing only the mailing-list reply text), this change in
kvm_handle_guest_abort() in arch/arm64/kvm/mmu.c is a functional no-op: on a
52-bit LPA2 host running a nested virtualization guest whose sanitised
ID_AA64MMFR0_EL1.PARange is capped at 48 bits, kvm_get_pa_bits(kvm) still
returns 52 rather than 48, so neither nested stage-2 MMU sizing nor stage-1
level 0 address size fault injection is updated.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261030120837.3752397-1-fuad.tabba@linux.dev?part=1

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] KVM: arm64: nv: Size nested stage-2 MMUs by the NV PARange cap
  2026-10-30 12:24     ` sashiko-bot
@ 2026-10-30 12:28       ` Fuad Tabba
  0 siblings, 0 replies; 7+ messages in thread
From: Fuad Tabba @ 2026-10-30 12:28 UTC (permalink / raw)
  To: sashiko-reviews; +Cc: kvmarm, Oliver Upton, Marc Zyngier

On Fri, 30 Oct 2026 at 12:24, <sashiko-bot@kernel.org> wrote:
>
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] KVM: arm64: nv: missing base changes in kvm_get_pa_bits() and reply changelog
> --
>
> commit f427a1e42f6e3dddeb1163b0cde7acfb4c92d8ef
> Author: Fuad Tabba <fuad.tabba@linux.dev>
>
> KVM: arm64: nv: Size nested stage-2 MMUs by the NV PARange cap
>
> This commit replaces get_kvm_ipa_limit() with kvm_get_pa_bits(kvm) in
> kvm_handle_guest_abort() when checking whether a translation fault IPA
> exceeds the guest's PARange.
>
> >     KVM: arm64: nv: Size nested stage-2 MMUs by the NV PARange cap
> >
> >     On Fri, 30 Oct 2026 11:09:43 +0000, sashiko-bot@kernel.org wrote:
> >     [...]
> >     > Because fault_ipa < BIT_ULL(get_kvm_ipa_limit()) (52) and
> >     > fault_ipa >= BIT_ULL(VTCR_EL2_IPA(vcpu->arch.hw_mmu->vtcr)) (48), won't
> >     > kvm_handle_guest_abort() fall through to kvm_inject_sea() and inject a
> >     > synchronous external abort into the guest instead of calling
> >     > kvm_inject_size_fault() to inject a stage-1 level 0 address size fault?
> >
> >     Yes. I'll fold this into v2:
> >
> > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > index 1db10d8d6db73..596b2b6ebbdf0 100644
> > --- a/arch/arm64/kvm/mmu.c
> > +++ b/arch/arm64/kvm/mmu.c
> > @@ -2440,8 +2440,8 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu)
> >       is_iabt = esr_trap_is_iabt(esr);
> >
> >       if (esr_fsc_is_translation_fault(esr)) {
> > -             /* Beyond sanitised PARange (which is the IPA limit) */
> > -             if (fault_ipa >= BIT_ULL(get_kvm_ipa_limit())) {
> > +             /* Beyond sanitised PARange */
> > +             if (fault_ipa >= BIT_ULL(kvm_get_pa_bits(kvm))) {
> >                       kvm_inject_size_fault(vcpu);
> >                       return 1;
> >               }
>
> [Severity: Medium]
> Was the incremental reply diff applied directly instead of being folded into
> the base patch?

Patience, young grasshopper... this will be folded into the base
patch, see above.

/fuad

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] KVM: arm64: nv: Size nested stage-2 MMUs by the NV PARange cap
  2026-10-30 12:08   ` Fuad Tabba
  2026-10-30 12:24     ` sashiko-bot
@ 2026-10-30 16:18     ` Wei-Lin Chang
  2026-10-30 16:25       ` Fuad Tabba
  1 sibling, 1 reply; 7+ messages in thread
From: Wei-Lin Chang @ 2026-10-30 16:18 UTC (permalink / raw)
  To: Fuad Tabba, sashiko-bot; +Cc: kvmarm, Oliver Upton, Marc Zyngier, Fuad Tabba

On Fri, Oct 30, 2026 at 12:08:37PM +0000, Fuad Tabba wrote:
> On Fri, 30 Oct 2026 11:09:43 +0000, sashiko-bot@kernel.org wrote:
> [...]
> > Because fault_ipa < BIT_ULL(get_kvm_ipa_limit()) (52) and
> > fault_ipa >= BIT_ULL(VTCR_EL2_IPA(vcpu->arch.hw_mmu->vtcr)) (48), won't
> > kvm_handle_guest_abort() fall through to kvm_inject_sea() and inject a
> > synchronous external abort into the guest instead of calling
> > kvm_inject_size_fault() to inject a stage-1 level 0 address size fault?
> 
> Yes. I'll fold this into v2:
> 
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 705f6d84770e9..2a05c7cf8552a 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -2440,8 +2440,8 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu)
>  	is_iabt = esr_trap_is_iabt(esr);
>  
>  	if (esr_fsc_is_translation_fault(esr)) {
> -		/* Beyond sanitised PARange (which is the IPA limit) */
> -		if (fault_ipa >= BIT_ULL(get_kvm_ipa_limit())) {
> +		/* Beyond sanitised PARange */
> +		if (fault_ipa >= BIT_ULL(kvm_get_pa_bits(kvm))) {
>  			kvm_inject_size_fault(vcpu);
>  			return 1;
>  		}
> 
> [...]
> > Should setup_s1_walk() and setup_s2_walk() use kvm_get_pa_bits(vcpu->kvm)
> > instead of get_kvm_ipa_limit() so that check_output_size() raises a
> > stage-1 address size fault for TTBR base addresses and descriptors with
> > bits [51:48] set rather than letting walk_s1() and __kvm_at_s12() truncate
> > those bits when passing the address to stage-2?
> 
> No. setup_s2_walk() passes pa52bit=false, so its output size is
> already at most 48. setup_s1_walk()'s output size can only exceed 48
> because, on an LPA2 host, NV guests see stage-1 TGRAN4/TGRAN16 at
> 52_BIT, which Wei-Lin's patch [1] stops advertising.

Agreed, however would it be more future-proof if they are changed to
kvm_get_pa_bits() anyway?

I.e. If kvm_get_pa_bits() < get_kvm_ipa_limit() is possible in the
future, the resulting max_oa_bits could be too large.

Also I don't see why we should use get_kvm_ipa_limit() (a host KVM
global limit) during a guest specific translation table walk.

Thanks,
Wei-Lin Chang

> 
> Cheers,
> /fuad
> 
> [1] https://lore.kernel.org/all/20261029223732.103785-2-oupton@kernel.org/

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: [PATCH] KVM: arm64: nv: Size nested stage-2 MMUs by the NV PARange cap
  2026-10-30 16:18     ` Wei-Lin Chang
@ 2026-10-30 16:25       ` Fuad Tabba
  0 siblings, 0 replies; 7+ messages in thread
From: Fuad Tabba @ 2026-10-30 16:25 UTC (permalink / raw)
  To: Wei-Lin Chang; +Cc: sashiko-bot, kvmarm, Oliver Upton, Marc Zyngier

On Fri, 30 Oct 2026 at 16:18, Wei-Lin Chang <weilin.chang@arm.com> wrote:
>
> On Fri, Oct 30, 2026 at 12:08:37PM +0000, Fuad Tabba wrote:
> > On Fri, 30 Oct 2026 11:09:43 +0000, sashiko-bot@kernel.org wrote:
> > [...]
> > > Because fault_ipa < BIT_ULL(get_kvm_ipa_limit()) (52) and
> > > fault_ipa >= BIT_ULL(VTCR_EL2_IPA(vcpu->arch.hw_mmu->vtcr)) (48), won't
> > > kvm_handle_guest_abort() fall through to kvm_inject_sea() and inject a
> > > synchronous external abort into the guest instead of calling
> > > kvm_inject_size_fault() to inject a stage-1 level 0 address size fault?
> >
> > Yes. I'll fold this into v2:
> >
> > diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> > index 705f6d84770e9..2a05c7cf8552a 100644
> > --- a/arch/arm64/kvm/mmu.c
> > +++ b/arch/arm64/kvm/mmu.c
> > @@ -2440,8 +2440,8 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu)
> >       is_iabt = esr_trap_is_iabt(esr);
> >
> >       if (esr_fsc_is_translation_fault(esr)) {
> > -             /* Beyond sanitised PARange (which is the IPA limit) */
> > -             if (fault_ipa >= BIT_ULL(get_kvm_ipa_limit())) {
> > +             /* Beyond sanitised PARange */
> > +             if (fault_ipa >= BIT_ULL(kvm_get_pa_bits(kvm))) {
> >                       kvm_inject_size_fault(vcpu);
> >                       return 1;
> >               }
> >
> > [...]
> > > Should setup_s1_walk() and setup_s2_walk() use kvm_get_pa_bits(vcpu->kvm)
> > > instead of get_kvm_ipa_limit() so that check_output_size() raises a
> > > stage-1 address size fault for TTBR base addresses and descriptors with
> > > bits [51:48] set rather than letting walk_s1() and __kvm_at_s12() truncate
> > > those bits when passing the address to stage-2?
> >
> > No. setup_s2_walk() passes pa52bit=false, so its output size is
> > already at most 48. setup_s1_walk()'s output size can only exceed 48
> > because, on an LPA2 host, NV guests see stage-1 TGRAN4/TGRAN16 at
> > 52_BIT, which Wei-Lin's patch [1] stops advertising.
>
> Agreed, however would it be more future-proof if they are changed to
> kvm_get_pa_bits() anyway?

Ack. A walk on behalf of the guest should be bounded by the guest's
PARange rather than the host's IPA limit. Will do that in v2.

Thanks!
/fuad

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2026-10-30 16:26 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-10-30 10:51 [PATCH] KVM: arm64: nv: Size nested stage-2 MMUs by the NV PARange cap Fuad Tabba
2026-10-30 11:09 ` sashiko-bot
2026-10-30 12:08   ` Fuad Tabba
2026-10-30 12:24     ` sashiko-bot
2026-10-30 12:28       ` Fuad Tabba
2026-10-30 16:18     ` Wei-Lin Chang
2026-10-30 16:25       ` Fuad Tabba

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.