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

[Dong, Chuanxiao]

> -----Original Message-----
> From: Jon Lange <jlange at microsoft.com>
> Sent: Tuesday, May 7, 2024 12:31 PM
> To: Dong, Chuanxiao <chuanxiao.dong at intel.com>; Jörg Rödel <joro at 8bytes.org>
> Cc: Thomas Leroy <tleroy at suse.de>; Carlos López <clopez at suse.de>; svsm-devel at coconut-svsm.dev
> Subject: RE: [svsm-devel] [EXTERNAL] Re: x86 decoder further steps
> 
> My hope is that we can design the user/kernel virtualization ABI to include MMIO primitives, such as
> "MMIO read requested" and "MMIO write requested".  These primitives would involve performing all
> of the instruction decoding in kernel mode, so we can take advantage of a single instruction decoder,
> and that decoder would pass MMIO requests up to user mode.

I think it matches what I though. Below is my understanding, and please let me know if this matches with your expectation or not.

The vmentry has to be happened in the kernel mode as executing the TDCALL instruction in user mode will cause #GP, so the user mode will use some sort of syscall to enter the kernel mode to do the vmentry. Based on this, the kernel mode is the first place to reach upon a guest vmexit. After identify the vmexit reason, the kernel mode can directly perform the instruction decoding if it is needed, and pass the decoded MMIO information (like below example) up to the user mode via returning from this syscall. And then the user mode performs MMIO emulation, as below example, to return value Y to the kernel mode via the syscall when needs to  vmentry again. The kernel mode completes the instruction emulation by writing the value Y to the decoded destination register or guest memory, and then performs the vmentry.

> For example, it might say "vTPM
> driver: here is a CRB write at address X which contains value Y" or "hey virtual PCI driver: a request was
> made for config space at address X; please supply value Y to return." Note that in this model, all of the
> register manipulation is also hidden in kernel mode so that the kernel/user interface can be limited to
> address/value pairs for MMIO emulation.  This minimizes the amount of code that needs to be
> replicated across MMIO handlers and also minimizes the chattiness of the user/kernel interface.
> 
> -Jon
> 
> -----Original Message-----
> From: Dong, Chuanxiao <chuanxiao.dong at intel.com>
> Sent: Monday, May 6, 2024 7:16 PM
> To: Jörg Rödel <joro at 8bytes.org>
> Cc: Thomas Leroy <tleroy at suse.de>; Jon Lange <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
> 
> [You don't often get email from chuanxiao.dong at intel.com. Learn why this is important at
> https://aka.ms/LearnAboutSenderIdentification ]
> 
> > -----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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
> > > thub.com%2Fintel-staging%2Ftd-partitioning-svsm%2Ftree%2Fsvsm-tdp&da
> > > ta=05%7C02%7Cjlange%40microsoft.com%7Cf0e2c42e6a3145645be208dc6e3bad
> > > 57%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C638506449805174183%7
> > > CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I
> > > k1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=X2f6LB0t03ylcyYKSqIKrgLgITQ
> > > Aa4r%2BAQpFqCk0YbY%3D&reserved=0 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