Re: [PATCH 0/2] KVM: nSVM: Expose DecodeAssists to L1
From: Tina Zhang
Date: Mon Jul 06 2026 - 20:02:08 EST
On 7/7/2026 6:10 AM, mlevitsk@xxxxxxxxxx wrote:
On Tue, 2026-06-30 at 08:52 -0700, Jim Mattson wrote:Thanks Jim and Maxim for the comments.
On Mon, Jun 29, 2026 at 5:57 AM Tina Zhang <zhang_wei@xxxxxxxxxxxxxx> wrote:Yes, and I also remember when I implemented some of the optional SVM features,
The SVM DecodeAssists feature is reported in CPUID
Fn8000_000A_EDX[7]. When available, hardware provides the length and bytes
of the intercepted instruction in the VMCB, allowing a hypervisor to consume
the decode information directly instead of re-decoding the instruction in
software on relevant VM-Exit paths.
DecodeAssists actually comprises four components:
* GPR number in EXITINFO1 for MOV-CR and MOV-DR VM-exits
* Software interrupt number in EXITINFO1 for INTn VM-exits
* Linear address in EXITINFO1 for INVLPG[A] VM-exits
* Guest instruction bytes and length in the VMCB for #NPF and #PF VM-exits
You only partially address the last component.
I decided not to implement this, also because of the same reason - pass-through
is easy but for all the emulated VM exits, it can be tricky to get that right.
Yes, that makes sense. This version only covers part of DecodeAssists. I didn't think enough about the other DecodeAssists pieces or the software-emulated/synthetic exit paths.
Since this patch advertises DecodeAssists to L1, L1 should get a reasonably complete and architecturally consistent view of the feature.
I will take another look for the next version and try to handle the remaining pieces properly, while also making sure we don't expose stale or incorrectly synthesized decode-assist state for emulated exits.
Thanks,
Tina
Best regards,
Maxim Levitsky