Hi Shameer,
On 3/12/25 6:34 PM, Shameerali Kolothum Thodi wrote: > >> -----Original Message----- >> From: Eric Auger <eric.au...@redhat.com> >> Sent: Wednesday, March 12, 2025 4:28 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, >>>>>> I know there were quite a lot of dicussions on the 1st multi >>>>>> instantiation series related to the way we instanatiate that device >>>>>> and maybe I missed some blockers but why wouldn't we allow the >>>>>> instantiation of the legacy smmu device with -device too. I think >>>>>> this would be simpler for libvirt and we would somehow deprecate >>>>>> the machine option method? would that make a problem if you were >> to >>>>>> use -device smmu,accel or something alike? >>>>> 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. 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. Thanks Eric > > Thanks, > Shameer > > > >
