> > > > > > > > FLR to a bound device is absolutely fine, just break the CC state. > > > > Sometimes it is exactly what host need to stop CC immediately. > > > > The problem is in VFIO's pre-FLR handling so we need to patch VFIO, not > > > > PCI core. > > > > > > What is a problem here exactly? > > > FLR by the host which equals to any other PCI error? The guest may or may > > > not be able to handle it, afaik it does not handle any errors now, QEMU > > > just stops the guest. > > > > It is about TDX Connect. > > > > According to the dmabuf patchset, the dmabuf needs to be revoked before > > FLR. That means KVM unmaps MMIOs when the device is in LOCKED/RUN state. > > That is forbidden by TDX Module and will crash KVM. > > > FLR is something you tell the device to do, how/why would TDX know about it?
I'm talking about FLR in VFIO driver. The VFIO driver would zap bar before FLR. The zapping would trigger KVM unmap MMIOs. See vfio_pci_zap_bars() for legacy case, and see [1] for dmabuf case. [1] https://lore.kernel.org/kvm/20250307052248.405803-4-vivek.kasire...@intel.com/ A pure FLR without zapping bar is absolutely OK. > Or it check the TDI state on every map/unmap (unlikely)? Yeah, TDX Module would check TDI state on every unmapping. > > > > So the safer way is > > to unbind the TDI first, then revoke MMIOs, then do FLR. > > > > I'm not sure when p2p dma is involved AMD will have the same issue. > > On AMD, the host can "revoke" at any time, at worst it'll see RMP events from > IOMMU. Thanks, Is the RMP event firstly detected by host or guest? If by host, host could fool guest by just suppress the event. Guest thought the DMA writting is successful but it is not and may cause security issue. Thanks, Yilun
