RE: [RFC PATCH v2 04/20] hw/arm/virt: Add support for smmuv3-accel

[Shameerali Kolothum Thodi via <qemu-devel@nongnu.org>]

Hi Eric,

> -----Original Message-----
> From: Eric Auger <eric.auger@redhat.com>
> Sent: Wednesday, March 12, 2025 6:31 PM
> To: Shameerali Kolothum Thodi
> <shameerali.kolothum.thodi@huawei.com>; qemu-arm@nongnu.org;
> qemu-devel@nongnu.org
> Cc: peter.maydell@linaro.org; jgg@nvidia.com; nicolinc@nvidia.com;
> ddutile@redhat.com; berrange@redhat.com; nathanc@nvidia.com;
> mochs@nvidia.com; smostafa@google.com; Linuxarm
> <linuxarm@huawei.com>; Wangzhou (B) <wangzhou1@hisilicon.com>;
> jiangkunkun <jiangkunkun@huawei.com>; Jonathan Cameron
> <jonathan.cameron@huawei.com>; zhangfei.gao@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