Messages in this thread | | | Subject | Re: [RFC v1 12/26] x86/tdx: Handle in-kernel MMIO | From | Dave Hansen <> | Date | Thu, 1 Apr 2021 12:56:24 -0700 |
| |
On 2/5/21 3:38 PM, Kuppuswamy Sathyanarayanan wrote: > From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com> > > Handle #VE due to MMIO operations. MMIO triggers #VE with EPT_VIOLATION > exit reason. > > For now we only handle subset of instruction that kernel uses for MMIO > oerations. User-space access triggers SIGBUS. .. > + case EXIT_REASON_EPT_VIOLATION: > + ve->instr_len = tdx_handle_mmio(regs, ve); > + break;
Is MMIO literally the only thing that can cause an EPT violation for TDX guests?
Forget userspace for a minute. #VE's from userspace are annoying, but fine. We can't control what userspace does. If an action it takes causes a #VE in the TDX architecture, tough cookies, the kernel must handle it and try to recover or kill the app.
The kernel is very different. We know in advance (must know, actually...) which instructions might cause exceptions of any kind. That's why we have exception tables and copy_to/from_user(). That's why we can handle kernel page faults on userspace, but not inside spinlocks.
Binary-dependent OSes are also very different. It's going to be natural for them to want to take existing, signed drivers and use them in TDX guests. They might want to do something like this.
But for an OS where we have source for the *ENTIRE* thing, and where we have a chokepoint for MMIO accesses (arch/x86/include/asm/io.h), it seems like an *AWFUL* idea to: 1. Have the kernel set up special mappings for I/O memory 2. Kernel generates special instructions to access that memory 3. Kernel faults on that memory 4. Kernel cracks its own special instructions to see what they were doing 5. Kernel calls up to host to do the MMIO
Instead of doing 2/3/4, why not just have #2 call up to the host directly? This patch seems a very slow, roundabout way to do paravirtualized MMIO.
BTW, there's already some SEV special-casing in io.h.
| |