On Wed, Jul 16, 2025 at 10:26:21AM +0000, Shameerali Kolothum Thodi wrote: > > On Mon, Jul 14, 2025 at 04:59:40PM +0100, Shameer Kolothum wrote: > > My vSMMU didn't work until I added entries like SIDSIZE, SSIDSIZE, > > TERM_MODEL, STALL_MODEL, and RIL. > > How come your vSMMU not working? Or you meant the assigned > dev is not working?
The "dev" (behind the vSMMU) running in the guest I mean. > The emulation supports SIDSIZE = 16 and RIL. Could you please > share the difference between these values w.r.t host SMMUv3. My hardware doesn't support RIL while the VMM sets RIL. There are other conflicts like STALL_MODEL that affected the final two-stage STE in the host too. > Probably we should take a look at Intel vtd implementation mentioned > by Zhenzhong in the other thread where it looks like there seems to be > a property for each capability they care about. > > Probably something like, > -device arm-smmuv3,accel=on,pasid_cap=on, > > And then enabling all features related to pasid and on later when > we retrieve the HW_INFO on device plug, compare and fail if not? > > But I think on ARM, we still we have limitations in knowing the actual > host supported features through IDR. In that case, we can only assume > that user is making an informed decision while enabling these features. Yes, I think you are right about this approach. Maybe a "subversion" parameter could mask away quite a few bits like RIL BBML. But the tricky thing is that user might want a customization to those individual bits, because it has to match with the HW values to use the device correctly. Thanks Nicolin
