Re: [RFC v1 6/7] x86/svm: Use the emulator path for VMEXIT_HLT

[Jan Beulich <jbeulich@xxxxxxxx>]

On 19.05.2026 19:02, Teddy Astie wrote:
> Le 18/05/2026 à 15:14, Ross Lagerwall a écrit :
>> @@ -2496,6 +2491,7 @@ void asmlinkage svm_vmexit_handler(void)
>>       vintr_t intr;
>>       bool vcpu_guestmode = false;
>>       struct vlapic *vlapic = vcpu_vlapic(v);
>> +    struct hvm_emulate_ctxt ctxt;
>>   
>>       regs->rax = vmcb->rax;
>>       regs->rip = vmcb->rip;
>> @@ -2840,7 +2836,9 @@ void asmlinkage svm_vmexit_handler(void)
>>       }
>>   
>>       case VMEXIT_HLT:
>> -        svm_vmexit_do_hlt(vmcb, regs);
>> +        hvm_emulate_init_once(&ctxt, NULL, NULL, regs);
>> +        ctxt.insn = INSTR_HLT;
>> +        svm_emulate_one(&ctxt);
>>           break;
> 
> 
> In this case, most of the logic is hidden behind svm_emulate_one(); 
> however, SEV-ES changes some aspects of the VMEXIT_HLT behavior (this is 
> the same for e.g VMEXIT_PAUSE).
> 
> With SEV-ES, we can't access the CPU registers anymore but hlt can still 
> be intercepted (it's a "Automatic Exit (AE)"), in this case, the CPU 
> increases RIP itself (this is documented in SEV-ES section of the APM), 
> and we just have to emulate the HLT behavior. How would that specific 
> behavior fit in this new design ?
> 
> We can skip increasing rip in this specific case, but it's now common code.

I guess we may need to somehow reflect fault vs trap semantics in the
context, for RIP updating to only occur in the former case.

Jan