|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [RFC v1 6/7] x86/svm: Use the emulator path for VMEXIT_HLT
Hello,Here is my feedback from a SEV-ES implementation perspective, as it has specific needs related to some VMEXIT handling. Le 18/05/2026 à 15:14, Ross Lagerwall a écrit : Signed-off-by: Ross Lagerwall <ross.lagerwall@xxxxxxxxxx> --- xen/arch/x86/hvm/emulate.c | 5 +++++ xen/arch/x86/hvm/svm/emulate.c | 2 +- xen/arch/x86/hvm/svm/svm.c | 24 +++++++++++------------- xen/arch/x86/hvm/svm/svm.h | 1 + 4 files changed, 18 insertions(+), 14 deletions(-) diff --git a/xen/arch/x86/hvm/emulate.c b/xen/arch/x86/hvm/emulate.c index c9553cd28238..471c032c1e9c 100644 --- a/xen/arch/x86/hvm/emulate.c +++ b/xen/arch/x86/hvm/emulate.c @@ -2800,6 +2800,11 @@ static int _hvm_emulate_one(struct hvm_emulate_ctxt *hvmemul_ctxt,switch ( hvmemul_ctxt->insn ) 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. case VMEXIT_IOIO: Teddy Attachment:
OpenPGP_0x660FA9D102CBCFD0.asc Attachment:
OpenPGP_signature.asc
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |