On 3/13/25 9:26 AM, Shameerali Kolothum Thodi wrote:
> 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.
OK thanks
Eric
>
> Thanks,
> Shameer
>
