[svsm-devel] [EXTERNAL] Re: x86 decoder further steps

[Dong, Chuanxiao]

> -----Original Message-----
> From: Jörg Rödel <joro at 8bytes.org>
> Sent: Friday, May 3, 2024 6:33 PM
> To: Dong, Chuanxiao <chuanxiao.dong at intel.com>
> Cc: Thomas Leroy <tleroy at suse.de>; Lange, Jon <jlange at microsoft.com>; Carlos López
> <clopez at suse.de>; svsm-devel at coconut-svsm.dev
> Subject: Re: [svsm-devel] [EXTERNAL] Re: x86 decoder further steps
> 
> On Fri, May 03, 2024 at 09:23:21AM +0000, Dong, Chuanxiao wrote:
> > We made a prototype
> > https://github.com/intel-staging/td-partitioning-svsm/tree/svsm-tdp
> > which extended the coconut-SVSM to support Intel TD partitioned guest.
> > It can decode and emulate some basic MMIO and String I/O instructions
> > used by the Linux guest. Currently it is part of TD partitioned guest
> > specific code, but if this code is also helpful to the NAE events
> > instruction as well, we can see how to integrate it with the existing
> > decoder?
> 
> I agree with Jon that it is best to implement our own limited instruction decoder. This has security
> advantages as this decoder will be smaller than a more complete one we pull in, which is especially
> important as instruction decoding will mostly be done in the SVSM kernel for performance reasons.

As you know that, we are going to move parts of this prototype hypervisor code from SVSM kernel to the user space. So based on this,  seems this hypervisor can still decode instructions in the kernel. And completing the instruction emulation, e.g., writing back the MMIO read result (generated by the virtual device model) to the destination vcpu register or guest memory will also be done in the kernel mode, is this a correct understanding?

> So itegrating the MMIO and String I/O emulation support from the Intel branch into our own instruction
> decoder would be really great.
> 
> Regards,
> 
> 	Joerg