Hi Eric, > -----Original Message----- > From: Eric Auger <eric.au...@redhat.com> > Sent: Wednesday, March 12, 2025 6:31 PM > To: Shameerali Kolothum Thodi > <shameerali.kolothum.th...@huawei.com>; qemu-...@nongnu.org; > qemu-devel@nongnu.org > Cc: peter.mayd...@linaro.org; j...@nvidia.com; nicol...@nvidia.com; > ddut...@redhat.com; berra...@redhat.com; nath...@nvidia.com; > mo...@nvidia.com; smost...@google.com; Linuxarm > <linux...@huawei.com>; Wangzhou (B) <wangzh...@hisilicon.com>; > jiangkunkun <jiangkun...@huawei.com>; Jonathan Cameron > <jonathan.came...@huawei.com>; zhangfei....@linaro.org > Subject: Re: [RFC PATCH v2 04/20] hw/arm/virt: Add support for smmuv3- > accel > > Hi Shameer, > > > >>>>> Thanks for taking a look. I am just jumping on this one for now. > >>>>> Yes, there were discussions around that. But I was not sure we > >>>>> concluded on deprecating the machine option. So if I get you > >>>>> correctly the idea is, > >>>>> > >>>>> if we have, > >>>>> -device smmuv3 it will instantiate the current machine wide smmuv3 > >>>>> and for -device smmuv3,accel this device? > >>>> yes that would be my preference. > >>> Ok. I will look into that in my next respin. A quick question. Does > >>> qemu DEVICE model support the differentiation like above easily? Or > we > >>> have to manage it with properties? > >> Not sure if I understand you question. I meant it can be a boolean > device > >> property (DEFINE_PROP_BOOL) smmuv3,accel=on > >> > >> No? > > Right. My query was more about any hidden Qemu magic to have device > instantiation > > similar to what we have at the moment even though we name both > devices "smmuv3". > > > > That way I can keep much of the code rather than checking "accel" > property > > in SMMUv3 code and redirecting calls. But looks like not. > I don't think there is any such a trick. > > Having the legacy device (without accel) only instantiable with the virt > machine option and the new accelerated one only instantiable with a > -device option looks strange to me. By the way they model the same > device so I think it makes more sense to use the same device with an > option.
Ok. Will address that in the next respin. > Also do you see anything that would prevent the acceleration enhanced > device from being able to translate emulated devices as well. Ideally > the smmu device should react differently depending on the device which > is translated. I think it worked with the original implementation as far > as I remember. Yes, smmuv3-accel works with emulated devices as well. Currently the only limitation is, we should have at least one vfi-pci dev cold plugged as mentioned in the cover letter. Hopefully we will be able to resolve that restriction soon. Thanks, Shameer
