Hi Shameer,
On 3/19/25 5:53 PM, Shameerali Kolothum Thodi wrote: > >> -----Original Message----- >> From: Eric Auger <eric.au...@redhat.com> >> Sent: Wednesday, March 19, 2025 4:46 PM >> To: Nicolin Chen <nicol...@nvidia.com> >> Cc: Shameerali Kolothum Thodi >> <shameerali.kolothum.th...@huawei.com>; qemu-...@nongnu.org; >> qemu-devel@nongnu.org; peter.mayd...@linaro.org; j...@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 03/20] hw/arm/smmuv3-accel: Add initial >> infrastructure for smmuv3-accel device >>>>> Is there any benefit from emulated devices working in the HW- >>>>> accelerated nested translation mode? >>>> Not really but do we have any justification for using different device >>>> name in accel mode? I am not even sure that accel option is really >>>> needed. Ideally the qemu device should be able to detect it is >>>> protecting a VFIO device, in which case it shall check whether nested is >>>> supported by host SMMU and then automatically turn accel mode? >>>> >>>> I gave the example of the vfio device which has different class >>>> implementration depending on the iommufd option being set or not. >>> Do you mean that we should just create a regular smmuv3 device and >>> let a VFIO device to turn on this smmuv3's accel mode depending on >>> its LEGACY/IOMMUFD class? >> no this is not what I meant. I gave an example where depending on an >> option passed to thye VFIO device you choose one class implement or the >> other. >>> Another question: how does an emulated device work with a vSMMUv3? >> I don't get your question. vSMMUv3 currently only works with emulated >> devices. Did you mean accelerated SMMUv3? >>> I could imagine that all the accel steps would be bypassed since >>> !sdev->idev. Yet, the emulated iotlb should cache its translation >>> so we will need to flush the iotlb, which will increase complexity >>> as the TLBI command dispatching function will need to be aware what >>> ASID is for emulated device and what is for vfio device.. >> I don't get the issue. For emulated device you go through the usual >> translate path which indeed caches configs and translations. In case the >> guest invalidates something, you know the SID and you find the entries >> in the cache that are tagged by this SID. > Not always you get sid, eg: CMD_TLBI_NH_ASID Effectively with ASID invalidation you potentially need to do both qemu IOTLB invalidation and host invalidation propagation. but this code is already in place in the code and used in vhost mode: smmu_inv_notifiers_all(&s->smmu_state); smmu_iotlb_inv_asid_vmid(bs, asid, vmid); but as stated before in VFIO accel mode the cache is not filled so I don't expect a huge penalty Besides we can also disable qemu caches if it turns the accel mode is in use, no? Eric > > Thanks, > Shameer
