Re: [PATCH v3 15/15] KVM: arm64: selftests: Add test for AT emulation

[Zenghui Yu <zenghui.yu@linux.dev>]

On 2/28/26 5:43 PM, Zenghui Yu wrote:
> Hi Oliver,
> 
> On 11/25/25 3:01 AM, Oliver Upton wrote:
> > +static void handle_sync(struct kvm_vcpu *vcpu, struct ucall *uc)
> > +{
> > +	switch (uc->args[1]) {
> > +	case CLEAR_ACCESS_FLAG:
> > +		/*
> > +		 * Delete + reinstall the memslot to invalidate stage-2
> > +		 * mappings of the stage-1 page tables, forcing KVM to
> > +		 * use the 'slow' AT emulation path.
> 
> Once the guest continues executing instructions, we would get a stage 2
> translation fault (on a S1 PTW) immediately and re-build the stage 2
> mappings for the S1 page tables. Depends on how much we have re-built
> for S1 page tables, the "forcing KVM to use the 'slow' AT emulation
> path" may not always be true.
> 
> I tested it in a QEMU guest (with "-machine virt,virtualization=on \
> -cpu max -accel tcg", so it's essentially a NV2 capable HW!) and it
> failed at the first test_at_insn(S1E2R, expect_fault):
> 
> [root@localhost arm64]# getconf PAGESIZE
> 65536
> [root@localhost arm64]# ./at
> Random seed: 0x6b8b4567
> __vm_create: mode='PA-bits:40,  VA-bits:48,  4K pages' type='0', pages='672'
> ==== Test Assertion Failure ====
>   arm64/at.c:58: (expect_fault) == fault
>   pid=824 tid=824 errno=4 - Interrupted system call
>      1	0x0000000000402d8f: run_test at at.c:137
>      2	0x00000000004020e3: main at at.c:162
>      3	0x0000ffffb07daf3b: ?? ??:0
>      4	0x0000ffffb07db007: ?? ??:0
>      5	0x000000000040222f: _start at ??:?
>   AT S1E2R: expected fault (par: ff00000080000b80)1
> 
> because in my test, the S1 page tables used to translate TEST_ADDR are
> located at
> 
> 	level 0: 0x180000
> 	level 1: 0x181000
> 	level 2: 0x187000
> 	level 3: 0x188000
> 
> All of them had already been re-mapped in stage 2 [*] (in the same 64KB
> physical page) before KVM started to emulate AT S1E2R. The AT_S1E1R
> (fast path) will successfully get the translation result and it's IMP
> DEF that whether an access flag fault will be triggered (QEMU chooses to
> not fault).

Fix myself up: an access flag fault should be taken in this case (with
AF bit is 0 and HA is not enabled). I've just sent a fix to QEMU for
that [*].

Given that we can't force the slow emulation path, we should still avoid
testing the IMP DEF behavior (i.e., TEST_ACCESS_FLAG). I will send a
patch to remove it.

[*] https://lore.kernel.org/r/20260317122517.47627-1-zenghui.yu@linux.dev

Thanks,
Zenghui