> -----Original Message----- > From: Duan, Zhenzhong <zhenzhong.d...@intel.com> > Sent: Wednesday, July 16, 2025 4:39 AM > To: Nicolin Chen <nicol...@nvidia.com> > Cc: Shameerali Kolothum Thodi > <shameerali.kolothum.th...@huawei.com>; qemu-...@nongnu.org; > qemu-devel@nongnu.org; eric.au...@redhat.com; > 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; shameerkolot...@gmail.com > Subject: RE: [RFC PATCH v3 05/15] hw/arm/smmuv3-accel: Introduce > smmuv3 accel device > > > > >-----Original Message----- > >From: Nicolin Chen <nicol...@nvidia.com> > >Subject: Re: [RFC PATCH v3 05/15] hw/arm/smmuv3-accel: Introduce > >smmuv3 accel device > > > >On Tue, Jul 15, 2025 at 10:48:31AM +0000, Duan, Zhenzhong wrote: > >> >+static const TypeInfo types[] = { > >> >+ { > >> >+ .name = TYPE_ARM_SMMUV3_ACCEL, > >> >+ .parent = TYPE_ARM_SMMUV3, > >> >+ .class_init = smmuv3_accel_class_init, > >> >+ } > >> > >> In cover-letter, I see "-device arm-smmuv3", so where is above accel > >> device created so we could use smmuv3_accel_ops? > > > >The smmu-common.c is the shared file between accel and non-accel > >instances. It has a module property: > > DEFINE_PROP_BOOL("accel", SMMUState, accel, false), > > It looks we expose a new TYPE_ARM_SMMUV3_ACCEL type device just for > exporting accel iommu_ops? > What about returning accel iommu_ops directly in > smmu_iommu_ops_by_type() and drop the new type? We are not creating any new device here. Its just a Class object of different type. I had a different approach previously and Eric suggested to try this as there are examples in VFIO/IOMMUFD for something like this. https://lore.kernel.org/qemu-devel/1105d100-dd1e-4aca-b518-50f903967...@redhat.com/ Thanks, Shameer > > > >where it directs to different iommu_ops: > >937 static const PCIIOMMUOps *smmu_iommu_ops_by_type(SMMUState > *s) > >938 { > >939 SMMUBaseClass *sbc; > >940 > >941 if (s->accel) { > >942 sbc = > >ARM_SMMU_CLASS(object_class_by_name(TYPE_ARM_SMMUV3_ACCEL)); > >943 } else { > >944 sbc = > >ARM_SMMU_CLASS(object_class_by_name(TYPE_ARM_SMMU)); > >945 } > >946 assert(sbc->iommu_ops); > >947 > >948 return sbc->iommu_ops; > >949 } > > > >Nicolin
RE: [RFC PATCH v3 05/15] hw/arm/smmuv3-accel: Introduce smmuv3 accel device
Shameerali Kolothum Thodi via Wed, 16 Jul 2025 02:29:04 -0700
- Re: [RFC PATCH v3 03/15] hw/arm/smmu-co... Jonathan Cameron via
- [RFC PATCH v3 04/15] hw/arm/smmu-common: Int... Shameer Kolothum via
- Re: [RFC PATCH v3 04/15] hw/arm/smmu-co... Nicolin Chen via
- Re: [RFC PATCH v3 04/15] hw/arm/smmu-co... Jonathan Cameron via
- [RFC PATCH v3 05/15] hw/arm/smmuv3-accel: In... Shameer Kolothum via
- Re: [RFC PATCH v3 05/15] hw/arm/smmuv3-... Nicolin Chen
- Re: [RFC PATCH v3 05/15] hw/arm/smmuv3-... Jonathan Cameron via
- RE: [RFC PATCH v3 05/15] hw/arm/smmuv3-... Duan, Zhenzhong
- Re: [RFC PATCH v3 05/15] hw/arm/smm... Nicolin Chen
- RE: [RFC PATCH v3 05/15] hw/arm... Duan, Zhenzhong
- RE: [RFC PATCH v3 05/15] hw... Shameerali Kolothum Thodi via
- [RFC PATCH v3 13/15] hw/arm/smmuv3: Forward ... Shameer Kolothum via
- Re: [RFC PATCH v3 13/15] hw/arm/smmuv3:... Jonathan Cameron via
- Re: [RFC PATCH v3 13/15] hw/arm/smm... Nicolin Chen
- RE: [RFC PATCH v3 13/15] hw/arm... Shameerali Kolothum Thodi via
- [RFC PATCH v3 11/15] hw/pci/pci: Introduce o... Shameer Kolothum via
- Re: [RFC PATCH v3 11/15] hw/pci/pci: In... Nicolin Chen
- [RFC PATCH v3 14/15] Read and validate host ... Shameer Kolothum via
- Re: [RFC PATCH v3 14/15] Read and valid... Nicolin Chen via
- Re: [RFC PATCH v3 14/15] Read and v... Nicolin Chen via
- Re: [RFC PATCH v3 14/15] Read and valid... Jonathan Cameron via