Re: [kvm-unit-tests] x86: Add #PF test case for the SVM DecodeAssists feature

[Alejandro Vallejo <alejandro.garciavallejo@amd.com>]

Hi,

On Thu Jan 15, 2026 at 7:32 PM CET, Sean Christopherson wrote:
> +Kevin and Yosry, who are working on similar tests
>
> On Thu, Jan 15, 2026, Alejandro Vallejo wrote:
>> Tests an intercepted #PF accesing the last (unmapped) qword of the
>> virtual address space. The assist ought provides a prefetched
>> code stream starting at the offending instruction.
>> 
>> This is little more than a smoke test. There's more cases not covered.
>> Namely, CR/DR MOVs, INTn, INVLPG, nested PFs, and fault-on-fetch.
>> 
>> Signed-off-by: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
>> ---
>> I'm not a big fan of using a literal -8ULL as "unbacked va", but I'm not
>> sure how to instruct the harness to give me a hole.
>
> Allocate a page, then use install_pte() or install_page_prot() to create a mapping
> that will #PF.

Right. It hadn't clicked for me exactly how L1 and L2 are related in the
harness. So this test group runs with the L2 reusing the mappings from the L1?

>
>> Likewise, some cases remain
>> untested, with the interesting one (fault-on-fetch) requiring some cumbersome
>> setup (put the codestream in the 14 bytes leading to a non-present NPT page.
>
> Not _that_ cumbersome though.  Allocate a page, install_page_prot() with NX,
> copy/write an instruction to the page, jump/call into the page.
>
> run_in_user_ex() makes it even easier to do that at CPL3.

I didn't mean fetch as in faulted instruction, but rather the CPU hitting a
missing PT as it fetches the 15 bytes of the codestream including and following
the faulting instruction. That'd be...

  opcode_pre:
  mov ($not_present), %al /* #PF! */
  not_present: /* page boundary */
  int3; /* unmapped in the NPT */

... where the CPU would try to fetch int3, and a bunch more bytes on VMEXIT but
fail, thus leaving insn_len as "not_present - opcode_pre" rather than 15. In the
absence of faults the CPU always fetches as much as possible on #PF/NPT-fault
intercepts.

A complete testcase would show the expected non-15 number as length.

>
> All the above said, I would rather piggyback the access test and not reinvent the
> wheel.  E.g. wrap ac_test_run() a la vmx_pf_exception_test(), then intercept #PF
> to verify the instruction information is filled as expected.  We'd need to modify
> ac_test_do_access() to record what instruction it expected to fault, but that
> shouldn't be _too_ hard, and it might even force us to improve the inscrutable
> asm blob.

I can see how this would be better for the simple test I have in this patch, but
it would probably overcomplicate ac_test_do_access() in the more complete
version with the instruction being at the boundary of a missing page.

I'll try to integrate it anyway on the off chance any other caller happens to
need it. I'm skeptical the result would look pretty, but we'll see; maybe it
turns out alright. I'll get back to you after I find some time to play with it.

On another note, would you prefer individual tests for every single assist
or does it sound ok to have this single test for the #PF case? There's no
meaningful difference between #PF and NPT faults as far as the assists are
concerned, and all others are implicitly covered by virtue of exit_info_1
being unconditionally copied irrespective of exit code.

They are trivial to write, so it's simply a matter of the test volume you're
willing to have.

Cheers for the feedback,
Alejandro