From: Sean Christopherson <seanjc@google.com>
To: Alejandro Vallejo <alejandro.garciavallejo@amd.com>
Cc: kvm@vger.kernel.org, Paolo Bonzini <pbonzini@redhat.com>,
Yosry Ahmed <yosry.ahmed@linux.dev>,
Kevin Cheng <chengkev@google.com>
Subject: Re: [kvm-unit-tests] x86: Add #PF test case for the SVM DecodeAssists feature
Date: Thu, 15 Jan 2026 10:32:51 -0800 [thread overview]
Message-ID: <aWky0xn4sG2dNryK@google.com> (raw)
In-Reply-To: <20260115164342.27736-1-alejandro.garciavallejo@amd.com>
+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.
> 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.
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.
next prev parent reply other threads:[~2026-01-15 18:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-15 13:17 [PATCH] KVM: nSVM: Expose SVM DecodeAssists to guest hypervisors Alejandro Vallejo
2026-01-15 16:43 ` [kvm-unit-tests] x86: Add #PF test case for the SVM DecodeAssists feature Alejandro Vallejo
2026-01-15 18:32 ` Sean Christopherson [this message]
2026-01-16 12:59 ` Alejandro Vallejo
2026-01-16 13:03 ` Alejandro Vallejo
2026-01-28 23:15 ` [PATCH] KVM: nSVM: Expose SVM DecodeAssists to guest hypervisors Jim Mattson
2026-01-29 16:53 ` Alejandro Vallejo
2026-01-29 18:08 ` Jim Mattson
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=aWky0xn4sG2dNryK@google.com \
--to=seanjc@google.com \
--cc=alejandro.garciavallejo@amd.com \
--cc=chengkev@google.com \
--cc=kvm@vger.kernel.org \
--cc=pbonzini@redhat.com \
--cc=yosry.ahmed@linux.dev \
/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 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.