Hi Eric, > -----Original Message----- > From: Eric Auger <[email protected]> > Sent: 27 October 2025 18:03 > To: Shameer Kolothum <[email protected]>; Nicolin Chen > <[email protected]> > Cc: [email protected]; [email protected]; > [email protected]; Jason Gunthorpe <[email protected]>; > [email protected]; [email protected]; Nathan Chen > <[email protected]>; Matt Ochs <[email protected]>; > [email protected]; [email protected]; > [email protected]; [email protected]; > [email protected]; [email protected]; [email protected]; > [email protected] > Subject: Re: [PATCH v4 22/27] hw/arm/smmuv3-accel: Add support for ATS > > External email: Use caution opening links or attachments > > > On 10/27/25 6:54 PM, Shameer Kolothum wrote: > > > >> -----Original Message----- > >> From: Eric Auger <[email protected]> > >> Sent: 27 October 2025 17:38 > >> To: Nicolin Chen <[email protected]> > >> Cc: Shameer Kolothum <[email protected]>; qemu- > >> [email protected]; [email protected]; [email protected]; > >> Jason Gunthorpe <[email protected]>; [email protected]; > >> [email protected]; Nathan Chen <[email protected]>; Matt Ochs > >> <[email protected]>; [email protected]; [email protected]; > >> [email protected]; [email protected]; > >> [email protected]; [email protected]; [email protected]; > >> [email protected] > >> Subject: Re: [PATCH v4 22/27] hw/arm/smmuv3-accel: Add support for ATS > >>
[...] > >> I remember some discussions with Peter who was also reluctant in general > >> to introduce some partial feature support. I think in general this is a > >> good policy to have features emulated and then accelerated. That's also > >> good for testing in case we can bring up some test env. > > Understood. However, ATS and PASID are the two key features required to > make > > any meaningful use of the accelerated support. I’m not suggesting we skip > > emulation for ATS or PASID entirely, just that we prioritize the > > acceleration > > path first. 😊 > I understand this is needed for vSVA. Nevertheless accel SMMU can > already work and be tested in a stdalone manner without ATS and PASID. > Those 2 features add a significant complexity on top of the core series > including from the review pov. This partial support support is not > necessarily great. Also I have not closely followed the thread related > to "[PATCH v4 26/27] vfio: Synthesize vPASID capability to VM" touching > pci.c. I don't know how much this is contreversial. just reading the > commit msg frightens me a little bit: "This is a choice in the good hope > of no conflict with any existing cap or hidden registers" ; Regarding PASID, that concern only applies if we were to blindly use the last 8 bytes of the virtual config space to place the PASID capability. In this implementation, we only synthesize the PASID capability when the device is behind a vSMMUv3 with accel=on. The user explicitly controls which devices have this capability synthesized. I don’t think this poses a major risk. Thanks, Shameer
