On Fri, May 30, 2025 at 12:54:44PM +1000, Alexey Kardashevskiy wrote:
>
>
> 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,
> };
That's a good point. So I think we don't have to use a 'type' field for
ioctl(IOMMUFD_VDEVICE_GUEST_REQUEST). But I didn't see these viommu_type
would be passed to TSM driver. So for this pci_tsm_guest_req kAPI, is it
still good we keep the 'type' for type safe check in TSM driver?
>
>
> > >
> > >
> > > > /* 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,
>
No, I just say QEMU/IOMMUFD don't care about the execution, so no need
an explicit fw_err return to them. Platform TSM driver should definitely
know about fw_err and handle it (to do DOE or anything else) internally,
but don't have to EXPLICITLY propagate these error code to up layers (TSM
core/QEMU/IOMMUFD).
Thanks,
Yilun
> > > 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
>
