Re: [PATCH v3 12/13] PCI/TSM: support TDI related operations for host TSM driver

[Alexey Kardashevskiy <aik@amd.com>]

On 30/5/25 00:20, Xu Yilun wrote:
>>>>
>>>>>> + * struct pci_tsm_guest_req_info - parameter for pci_tsm_ops.guest_req()
>>>>>> + * @type: identify the format of the following blobs
>>>>>> + * @type_info: extra input/output info, e.g. firmware error code
>>>>>
>>>>> Call it "fw_ret"?
>>>>
>>>> Sure.
>>>
>>> This field is intended for out-of-blob values, like fw_ret. But fw_ret
>>> is specified in GHCB and is vendor specific. Other vendors may also
>>> have different values of this kind.
>>>
>>> So I intend to gather these out-of-blob values in type_info, like:
>>>
>>> enum pci_tsm_guest_req_type {
>>>     PCI_TSM_GUEST_REQ_TDXC,
>>>     PCI_TSM_GUEST_REQ_SEV_SNP,
>>> };
>>
>>
>> The pci_tsm_ops hooks already know what they are - SEV or TDX.
> 
> I think this is for type safe check to some extend. The tsm driver hook
> assumes the blobs are for its known format, but userspace may pass in
> another format ...

The blobs are guest_request blobs, they enter the kernel via iommufd's viommu ioctl and viommu already has  iommu_viommu_type which is (in my tree):

enum iommu_viommu_type {
         IOMMU_VIOMMU_TYPE_DEFAULT = 0,
         IOMMU_VIOMMU_TYPE_ARM_SMMUV3 = 1,
        IOMMU_VIOMMU_TYPE_AMD_TSM = 2,
        IOMMU_VIOMMU_TYPE_AMD = 3,
  };


>>
>>
>>> /* SEV SNP guest request type info */
>>> struct pci_tsm_guest_req_sev_snp {
>>> 	s32 fw_err;
>>> };
>>>
>>> Since IOMMUFD has the userspace entry, maybe these definitions should be
>>> moved to include/uapi/linux/iommufd.h.
>>>
>>> In pci-tsm.h, just define:
>>>
>>> struct pci_tsm_guest_req_info {
>>> 	u32 type;
>>> 	void __user *type_info;
>>> 	size_t type_info_len;
>>> 	void __user *req;
>>> 	size_t req_len;
>>> 	void __user *resp;
>>> 	size_t resp_len;
>>> };
>>>
>>> BTW: TDX Connect has no out-of-blob value, so should set type_info_len = 0
>>
>>
>> No TDX Connect fw error handling on the host OS whatsoever, always return to the guest?
> 
> Always return to guest. The fw error info (not raw fw error code) is
> embedded in response blob.
> 
> For QEMU/IOMMUFD, Guest Request doesn't care blob data, so don't have
> to judge fw_error either. Alway return to the guest and let the guest
> decide what to do.

So whatever is inside such requests, the host is not told about it ever? How does DOE bouncing work on Intel then if the fw cannot ask the host to do DOE? Thanks,

>> oookay, do not use it but the fw response is still a generic thing. Whatever is specific to AMD can be packed into req/resp and QEMU/guest will handle those.
> 
> But for out-of-blob data, it is the same effort as packing into type_info.
> At least we could have a clear idea, which blob is SW defined, which blob
> is GHCI/GHCB defined.
> 
> Thanks,
> Yilun

-- 
Alexey