What about PCI_NO_PASID?

________________________________
From: Duan, Zhenzhong <[email protected]>
Sent: 12 February 2026 03:43
To: Nicolin Chen <[email protected]>; Shameer Kolothum Thodi 
<[email protected]>
Cc: [email protected] <[email protected]>; [email protected] 
<[email protected]>; [email protected] <[email protected]>; [email protected] 
<[email protected]>; [email protected] <[email protected]>; [email protected] 
<[email protected]>; Jason Gunthorpe <[email protected]>; 
[email protected] <[email protected]>; CLEMENT MATHIEU--DRIF 
<[email protected]>; Tian, Kevin <[email protected]>; Liu, Yi 
L <[email protected]>; Hao, Xudong <[email protected]>
Subject: RE: [RFC PATCH 01/14] backends/iommufd: Add pasid attach/detach 
callbacks

Caution: External email. Do not open attachments or click links, unless this 
email comes from a known sender and you know the content is safe.


>-----Original Message-----
>From: Nicolin Chen <[email protected]>
>Subject: Re: [RFC PATCH 01/14] backends/iommufd: Add pasid attach/detach
>callbacks
>
>On Wed, Feb 11, 2026 at 09:14:33AM -0800, Shameer Kolothum Thodi wrote:
>> > > Have you considered extending attach_hwpt() to
>> > >take a PASID instead of introducing a separate callback?
>> >
>> > Yes, I did. To extending attach/detach_hwpt(), we need to add two
>> > parameters, "bool has_pasid, uint32_t pasid". E.g.,
>> >
>> >     bool (*attach_hwpt)(HostIOMMUDeviceIOMMUFD *idev,
>> >                                          bool has_pasid, uint32_t pasid,
>> >                                          uint32_t hwpt_id, Error **errp);
>
>The RID attach/detach could be just pasid=IOMMU_NO_PASID without
>that "has_pasid"?

After further thinking, yes, we could.

IOMMU_NO_PASID isn't export as UAPI, we need to define it in QEMU.

>
>> > and refactor iommufd_cdev_attach/detach_ioas_hwpt() a bit.
>> >
>> > I'm fine either way, two separate callbacks just look cleaner for me.
>> > Let me know if extending is preferred.
>>
>> Since PASID attach/detach is essentially an extension of the existing
>> attach/detach flow, I would prefer extending the current callbacks.
>> I think that keeps the interface simpler and avoids code duplication.
>
>+1

Ok, wll extend attach/detach_hwpt(). Thanks all.

Reply via email to