On 25/2/25 20:00, Xu Yilun wrote:
On Tue, Feb 18, 2025 at 10:10:01PM +1100, Alexey Kardashevskiy wrote:
When a TDISP-capable device is passed through, it is configured as
a shared device to begin with. Later on when a VM probes the device,
detects its TDISP capability (reported via the PCIe ExtCap bit
called "TEE-IO"), performs the device attestation and transitions it
to a secure state when the device can run encrypted DMA and respond
to encrypted MMIO accesses.
Since KVM is out of the TCB, secure enablement is done in the secure
firmware. The API requires PCI host/guest BDFns, a KVM id hence such
calls are routed via IOMMUFD, primarily because allowing secure DMA
is the major performance bottleneck and it is a function of IOMMU.
I still have concern about the vdevice interface for bind. Bind put the
device to LOCKED state, so is more of a device configuration rather
than an iommu configuration. So seems more reasonable put the API in VFIO?
IOMMUFD means pretty much VFIO (in the same way "VFIO means KVM" as 95+%
of VFIO users use it from KVM, although VFIO works fine without KVM) so
not much difference where to put this API and can be done either way.
VFIO is reasonable, the immediate problem is that IOMMUFD's vIOMMU knows
the guest BDFn (well, for AMD) and VFIO PCI does not.
Add TDI bind to do the initial binding of a passed through PCI
function to a VM. Add a forwarder for TIO GUEST REQUEST. These two
call into the TSM which forwards the calls to the PSP.
Signed-off-by: Alexey Kardashevskiy <aik@xxxxxxx>
---
Both enabling secure DMA (== "SDTE Write") and secure MMIO (== "MMIO
validate") are TIO GUEST REQUEST messages. These are encrypted and
the HV (==IOMMUFD or KVM or VFIO) cannot see them unless the guest
shares some via kvm_run::kvm_user_vmgexit (and then QEMU passes those
via ioctls).
This RFC routes all TIO GUEST REQUESTs via IOMMUFD which arguably should
only do so only for "SDTE Write" and leave "MMIO validate" for VFIO.
The fact is HV cannot see the guest requests, even I think HV never have
to care about the guest requests. HV cares until bind, then no HV side
MMIO & DMA access is possible, any operation/state after bind won't
affect HV more. And HV could always unbind to rollback guest side thing.
That said guest requests are nothing to do with any host side component,
iommu or vfio. It is just the message posting between VM & firmware. I
suppose KVM could directly do it by calling TSM driver API.
No, it could not as the HV needs to add the host BDFn to the guest's
request before calling the firmware and KVM does not have that knowledge.
These guest requests are only partly encrypted as the guest needs
cooperation from the HV. The guest BDFn comes unencrypted from the VM to
let the HV find the host BDFn and do the bind.
Also, say, in order to enable MMIO range, the host needs to "rmpupdate"
MMIOs first (and then the firmware does "pvalidate") so it needs to know
the range which is in unencrypted part of guest request.
Here is a rough idea: https://github.com/aik/qemu/commit/f804b65aff5b
A TIO Guest request is made of:
- guest page with unencrypted header (msg type is essential) and
encrypted body for consumption by the firmware;
- a couple of 64bit bit fields and RAX/RBX/... in shared GHCB page.
Thanks,
Thanks,
Yilun
--
Alexey
