On Mon, Oct 09, 2023 at 09:52:00PM +1100, Alexey Kardashevskiy wrote: > On 29/9/23 03:32, Lukas Wunner wrote: > > At any given time, only a single entity in a physical system may have > > an SPDM connection to a device. That's because the GET_VERSION request > > (which begins an authentication sequence) resets "the connection and all > > context associated with that connection" (SPDM 1.3.0 margin no 158). > > > > Thus, when a device is passed through to a guest and the guest has > > authenticated it, a subsequent authentication by the host would reset > > the device's CMA-SPDM session behind the guest's back. > > > > Prevent by letting the guest claim exclusive CMA ownership of the device > > during passthrough. Refuse CMA reauthentication on the host as long. > > After passthrough has concluded, reauthenticate the device on the host. [...] > > --- a/drivers/pci/pci.h > > +++ b/drivers/pci/pci.h > > @@ -388,6 +388,7 @@ static inline bool pci_dev_is_disconnected(const struct pci_dev *dev) > > #define PCI_DEV_ADDED 0 > > #define PCI_DPC_RECOVERED 1 > > #define PCI_DPC_RECOVERING 2 > > +#define PCI_CMA_OWNED_BY_GUEST 3 > > In AMD SEV TIO, the PSP firmware creates an SPDM connection. What is the > expected way of managing such ownership, a new priv_flags bit + api for it? Right, I understand. See this ongoing discussion in reply to the cover letter: https://lore.kernel.org/all/652030759e42d_ae7e72946@xxxxxxxxxxxxxxxxxxxxxxxxx.notmuch/ In short, we need a spec amendment to negotiate between platform and OS which of the two controls the DOE instance supporting CMA-SPDM. I think the OS is free to access any Extended Capabilities in Config Space unless the platform doesn't grant it control over them through _OSC. Because the _OSC definition in the PCI Firmware Spec was not amended for CMA-SPDM, it is legal for the OS to assume control of CMA-SPDM, which is what this patch does. Thanks, Lukas
