Re: [PATCH v5 3/8] KVM: nSVM: Track fresh hardware DecodeAssist bytes

[Tina Zhang <zhang_wei@open-hieco.net>]

On 9/5/2026 7:42 AM, Jim Mattson wrote:
> On Mon, Aug 24, 2026 at 5:40 AM Tina Zhang <zhang_wei@open-hieco.net> wrote:
>>
>> VMCB02 instruction bytes are valid only for the hardware VM-Exit that
>> populated them.  Track whether VMCB02 contains instruction bytes for the
>> data #PF or #NPF currently being reflected to L1 so that stale bytes are
>> not copied to VMCB12.
>>
>> Clear the VMCB02 instruction-byte fields and freshness state before each
>> nested run.  Mark the bytes as fresh only when a data #PF or #NPF came
> 
> By "nested run," do you mean "emulated VMRUN"? IIUC, that's when the
> bytes and freshness are cleared.

Yes, I meant when KVM prepares VMCB02 after emulating L1's VMRUN. The 
same helper is also used when restoring nested state. I'll reword the 
commit message to make that clear.


>> +static void nested_svm_clear_insn_bytes(struct vmcb *vmcb)
>> +{
>> +       vmcb->control.insn_len = 0;
>> +       memset(vmcb->control.insn_bytes, 0,
>> +              sizeof(vmcb->control.insn_bytes));
>> +}
> 
> Is it necessary to clear the bytes? The APM says, "All other
> intercepts clear bits 7:0 in this field to zero (to indicate an
> invalid condition); implementations may leave the other bytes
> untouched."
> 
> Are you concerned about leaking bytes from unreflected VM-exits handled by L0?

No, clearing the entire byte array isn't necessary.  VMCB02 is private 
to L0, and insn_len determines whether the bytes are valid and how many
bytes may be copied to VMCB12.  Setting insn_len to zero is sufficient
and matches the behavior allowed by the APM. I'll drop the memset().


>> -int nested_svm_exit_handled(struct vcpu_svm *svm)
>> +int nested_svm_exit_handled(struct vcpu_svm *svm, bool from_hardware)
> 
> I don't think 'from_hardware' is necessary. The two callsites where
> from_hardware is false are for opcode exits, and will be ruled out by
> the check for nested_svm_vmexit_has_insn_bytes(svm->vmcb). If you drop
> this extra parameter, there will be less churn.

Agreed. Both non-hardware callsites set an opcode exit code before 
calling nested_svm_exit_handled(), so nested_svm_vmexit_has_insn_bytes() 
will reject them.  I'll drop the from_hardware parameter from 
nested_svm_exit_handled() and restore its callers.

Thanks,
Tina