RE: [PATCHv4 11/30] x86/tdx: Handle in-kernel MMIO

David Laight
2022-02-25T02:24:15Z

From: Dave Hansen
> Sent: 24 February 2022 20:12
...
> === Limitations of this approach ===
>
> > MMIO addresses can be used with any CPU instruction that accesses
> > memory. Address only MMIO accesses done via io.h helpers, such as
> > 'readl()' or 'writeq()'.
>
> Any CPU instruction that accesses memory can also be used to access
> MMIO. However, by convention, MMIO access are typically performed via
> io.h helpers such as 'readl()' or 'writeq()'.
>
> > readX()/writeX() helpers limit the range of instructions which can trigger
> > MMIO. It makes MMIO instruction emulation feasible. Raw access to a MMIO
> > region allows the compiler to generate whatever instruction it wants.
> > Supporting all possible instructions is a task of a different scope.
>
> The io.h helpers intentionally use a limited set of instructions when
> accessing MMIO. This known, limited set of instructions makes MMIO
> instruction decoding and emulation feasible in KVM hosts and SEV guests
> today.
>
> MMIO accesses are performed without the io.h helpers are at the mercy of
> the compiler. Compilers can and will generate a much more broad set of
> instructions which can not practically be decoded and emulated. TDX
> guests will oops if they encounter one of these decoding failures.
>
> This means that TDX guests *must* use the io.h helpers to access MMIO.
>
> This requirement is not new. Both KVM hosts and AMD SEV guests have the
> same limitations on MMIO access.

Am I reading the last sentence correctly?
Normally (on x86 at least) a driver can mmap() PCIe addresses directly
into a user process.
This lets a user process directly issue PCIe read/write bus cycles.
These can be any instructions at all.
I don't think we've had any issues doing that in normal VMs.

Or is this emulation only applying to specific PCIe slaves?

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)