Re: [PATCH v4 08/27] hw/arm/smmuv3-accel: Add set/unset_iommu_device callback

2025-10-02 Thread Nicolin Chen
On Thu, Oct 02, 2025 at 04:34:17AM -0700, Shameer Kolothum wrote: > > > Implement a set_iommu_device callback: > > > -If found an existing viommu reuse that. > > I think you need to document why you need a vIOMMU object. > > > -Else, > > > Allocate a vIOMMU with the nested parent S2 hwpt allo

Re: [PATCH v4 06/27] hw/arm/smmuv3-accel: Restrict accelerated SMMUv3 to vfio-pci endpoints with iommufd

2025-09-29 Thread Nicolin Chen
; for guest RAM. > > So in short: > - vfio-pci devices(with iommufd as backend) return the system address >space. > - bridges and root ports return the IOMMU address space. > > Signed-off-by: Shameer Kolothum Reviewed-by: Nicolin Chen With some nits: > +/* &

Re: [PATCH v4 04/27] hw/arm/smmu-common:Make iommu ops part of SMMUState

2025-09-29 Thread Nicolin Chen via
On Mon, Sep 29, 2025 at 02:36:20PM +0100, Shameer Kolothum wrote: > And set to the current default smmu_ops. No functional change intended. > This will allow SMMUv3 accel implementation to set a different iommu ops > later. > > Signed-off-by: Shameer Kolothum Reviewed-by: Nicolin Chen

Re: [PATCH v6 05/22] hw/pci: Introduce pci_device_get_viommu_flags()

2025-09-25 Thread Nicolin Chen
On Wed, Sep 24, 2025 at 07:05:42AM +, Duan, Zhenzhong wrote: > >From: Nicolin Chen > >Subject: Re: [PATCH v6 05/22] hw/pci: Introduce > >> get_viommu_flags() is designed to return 64bit bitmap of purely vIOMMU > >> flags which are only determined by

Re: [PATCH v6 18/22] iommufd: Introduce a helper function to extract vendor capabilities

2025-09-24 Thread Nicolin Chen
On Wed, Sep 24, 2025 at 08:05:36AM +, Duan, Zhenzhong wrote: > >uint64_t host_iommu_extract_quirks(enum iommu_hw_info_type, > >VendorCaps *caps) > >{ > >uint64_t quirks = 0; > > > >#if defined(CONFIG_VTD) > > I have applied all suggested change except CONFIG_VTD here as it's a device > co

Re: [PATCH v6 18/22] iommufd: Introduce a helper function to extract vendor capabilities

2025-09-23 Thread Nicolin Chen
d with vIOMMU > emulation and host IOMMU extracting code, also need a new callback in > PCIIOMMUOps. So we choose a simpler way as above. > > Suggested-by: Nicolin Chen > Signed-off-by: Zhenzhong Duan Reviewed-by: Nicolin Chen With some nits: > +enum { > +/* Nesti

Re: [PATCH v6 05/22] hw/pci: Introduce pci_device_get_viommu_flags()

2025-09-23 Thread Nicolin Chen
ting hiod > ... > pci_device_set_iommu_device(hiod) > > Suggested-by: Yi Liu > Signed-off-by: Zhenzhong Duan Despite some nits, patch looks good to me: Reviewed-by: Nicolin Chen > +enum { > +/* Nesting parent HWPT will be reused by vIOMMU to crea

Re: [RFC PATCH v3 06/15] hw/arm/smmuv3-accel: Restrict accelerated SMMUv3 to vfio-pci endpoints with iommufd

2025-09-19 Thread Nicolin Chen
On Fri, Sep 19, 2025 at 12:38:45AM -0700, Shameer Kolothum wrote: > My suggestion was... > > static AddressSpace *smmuv3_accel_find_add_as(..) > { > ... > if (vfio_pci) { > return &address_space_memory; > } else { > return &sdev->as; > } > } > > ie, use the global to s

Re: [RFC PATCH v3 06/15] hw/arm/smmuv3-accel: Restrict accelerated SMMUv3 to vfio-pci endpoints with iommufd

2025-09-18 Thread Nicolin Chen
On Thu, Sep 18, 2025 at 06:31:43AM -0700, Shameer Kolothum wrote: > > > > @@ -37,7 +37,6 @@ typedef struct SMMUS1Hwpt { > > > > > > > > typedef struct SMMUv3AccelDevice { > > > > SMMUDevice sdev; > > > > -AddressSpace as_sysmem; > > > > HostIOMMUDeviceIOMMUFD *idev; > > > > SMM

Re: [RFC PATCH v3 06/15] hw/arm/smmuv3-accel: Restrict accelerated SMMUv3 to vfio-pci endpoints with iommufd

2025-09-17 Thread Nicolin Chen
On Tue, Sep 16, 2025 at 11:33:21AM +0100, Shameer Kolothum wrote: > > I found a new problem here that we initialize new as_sysmem per > > VFIO device. So, sdevs would return own individual AS pointers > > here at this get_address_space function, although they point to > > the same system address sp

Re: [RFC PATCH v3 13/15] hw/arm/smmuv3: Forward invalidation commands to hw

2025-09-08 Thread Nicolin Chen
On Mon, Sep 08, 2025 at 05:22:35AM -0700, Shameer Kolothum wrote: > > -Original Message- > > From: Eric Auger > > smmuv3_cmdq_consume(SMMUv3State *s) > > > SMMUCmdError cmd_error = SMMU_CERROR_NONE; > > > SMMUQueue *q = &s->cmdq; > > > SMMUCommandType type = 0; > > > +SM

Re: [RFC PATCH v3 12/15] hw/arm/smmuv3-accel: Introduce helpers to batch and issue cache invalidations

2025-09-08 Thread Nicolin Chen
On Mon, Sep 08, 2025 at 02:59:55AM -0700, Shameer Kolothum wrote: > > -Original Message- > > From: Eric Auger > > > +/* > > > + * SMMUCommandBatch - batch of invalidation commands for accel > > smmuv3 > > > + * @cmds: Pointer to list of commands > > > + * @cons: Pointer to list of CONS cor

Re: [RFC PATCH v3 10/15] hw/arm/smmuv3-accel: Allocate a vDEVICE object for device

2025-09-05 Thread Nicolin Chen
On Fri, Sep 05, 2025 at 11:57:59AM +0200, Eric Auger wrote: > Hi Shameer, > > On 7/14/25 5:59 PM, Shameer Kolothum wrote: > > From: Nicolin Chen > > > > Allocate and associate a vDEVICE object for the Guest device > > with the vIOMMU. This will help the

Re: [PATCH v5 02/21] hw/pci: Introduce pci_device_get_viommu_cap()

2025-08-31 Thread Nicolin Chen
On Mon, Sep 01, 2025 at 02:35:29AM +, Duan, Zhenzhong wrote: > >> I just noticed this change will conflict with your suggestion of using > >HW_NESTED terminology. > >> Let me know if you agree with this change or not? > > > >It wouldn't necessarily conflict. VIOMMU_FLAG_WANT_NESTING_PARENT > >i

Re: [PATCH v5 20/21] Workaround for ERRATA_772415_SPR17

2025-08-30 Thread Nicolin Chen
On Fri, Aug 29, 2025 at 04:16:41PM +0800, Yi Liu wrote: > On 2025/8/27 23:09, Nicolin Chen wrote: > > On Wed, Aug 27, 2025 at 07:56:38PM +0800, Yi Liu wrote: > > > On 2025/8/23 07:55, Nicolin Chen wrote: > > We could start with a function that loads the HostIOMMUDeviceCaps

Re: [PATCH v5 05/21] vfio/iommufd: Force creating nested parent domain

2025-08-30 Thread Nicolin Chen
On Fri, Aug 29, 2025 at 01:40:01AM +, Duan, Zhenzhong wrote: > >-Original Message- > >On 8/28/25 11:53 AM, Duan, Zhenzhong wrote: > +/* > + * If vIOMMU supports stage-1 translation, force to create nested > >>> parent > >>> I would rather not use another terminology he

Re: [PATCH v5 02/21] hw/pci: Introduce pci_device_get_viommu_cap()

2025-08-30 Thread Nicolin Chen
On Fri, Aug 29, 2025 at 01:54:50AM +, Duan, Zhenzhong wrote: > >>On 2025/8/27 23:30, Nicolin Chen wrote: > >>> On Wed, Aug 27, 2025 at 02:32:42PM +0200, Eric Auger wrote: > >>>> On 8/27/25 2:30 PM, Yi Liu wrote: > >>>>> On 2025/8/27 19:

Re: [PATCH v5 07/21] intel_iommu: Introduce a new structure VTDHostIOMMUDevice

2025-08-27 Thread Nicolin Chen
Hi Eric, On Wed, Aug 27, 2025 at 06:36:09PM +0200, Eric Auger wrote: > On 8/26/25 7:21 PM, Nicolin Chen wrote: > > QEMU log: > > smmuv3_accel_set_iommu_device: bus=0, devfn=0, sid=0 > > > > The set_iommu_device op is invoked by vfio_pci_realize() where the > > t

Re: [PATCH v5 02/21] hw/pci: Introduce pci_device_get_viommu_cap()

2025-08-27 Thread Nicolin Chen
On Wed, Aug 27, 2025 at 02:32:42PM +0200, Eric Auger wrote: > On 8/27/25 2:30 PM, Yi Liu wrote: > > On 2025/8/27 19:22, Eric Auger wrote: > >>> TBH. I'm hesitating to name it as get_viommu_cap. The scope is a little > >>> larger than what we want so far. So I'm wondering if it can be done > >>> in

Re: [PATCH v5 20/21] Workaround for ERRATA_772415_SPR17

2025-08-27 Thread Nicolin Chen
On Wed, Aug 27, 2025 at 07:56:38PM +0800, Yi Liu wrote: > On 2025/8/23 07:55, Nicolin Chen wrote: > > > +if (vtd.flags & IOMMU_HW_INFO_VTD_ERRATA_772415_SPR17) { > > > +container->bcontainer.bypass_ro = true; > > > > This circled back to che

Re: [PATCH v5 07/21] intel_iommu: Introduce a new structure VTDHostIOMMUDevice

2025-08-27 Thread Nicolin Chen
On Wed, Aug 27, 2025 at 06:45:42AM +, Duan, Zhenzhong wrote: > Hi > > >-Original Message----- > >From: Nicolin Chen > >Subject: Re: [PATCH v5 07/21] intel_iommu: Introduce a new structure > >VTDHostIOMMUDevice > > > >Hi Zhenzhong/Yi, >

Re: [PATCH v5 20/21] Workaround for ERRATA_772415_SPR17

2025-08-27 Thread Nicolin Chen
On Wed, Aug 27, 2025 at 07:11:54AM +, Duan, Zhenzhong wrote: > >> >> +if (vtd.flags & IOMMU_HW_INFO_VTD_ERRATA_772415_SPR17) { > >> >> +container->bcontainer.bypass_ro = true; > >> > > >> >This circled back to checking a vendor specific flag in the core.. > >> > >> I'm not sure if V

Re: [PATCH v5 07/21] intel_iommu: Introduce a new structure VTDHostIOMMUDevice

2025-08-26 Thread Nicolin Chen
Hi Zhenzhong/Yi, On Fri, Aug 22, 2025 at 02:40:45AM -0400, Zhenzhong Duan wrote: > @@ -4371,6 +4374,7 @@ static bool vtd_dev_set_iommu_device(PCIBus *bus, void > *opaque, int devfn, > HostIOMMUDevice *hiod, Error **errp) > { > IntelIOMMUState *s = opaqu

Re: [PATCH v5 20/21] Workaround for ERRATA_772415_SPR17

2025-08-25 Thread Nicolin Chen
On Mon, Aug 25, 2025 at 09:21:48AM +, Duan, Zhenzhong wrote: > > > >-Original Message----- > >From: Nicolin Chen > >Subject: Re: [PATCH v5 20/21] Workaround for ERRATA_772415_SPR17 > > > >On Fri, Aug 22, 2025 at 02:40:58AM -0400, Zhenzhong Duan wrote:

Re: [PATCH v5 20/21] Workaround for ERRATA_772415_SPR17

2025-08-22 Thread Nicolin Chen
On Fri, Aug 22, 2025 at 02:40:58AM -0400, Zhenzhong Duan wrote: > diff --git a/hw/vfio/iommufd.c b/hw/vfio/iommufd.c > index e503c232e1..59735e878c 100644 > --- a/hw/vfio/iommufd.c > +++ b/hw/vfio/iommufd.c > @@ -324,6 +324,7 @@ static bool iommufd_cdev_autodomains_get(VFIODevice > *vbasedev, > {

Re: [PATCH v5 06/21] hw/pci: Export pci_device_get_iommu_bus_devfn() and return bool

2025-08-22 Thread Nicolin Chen
ger Reviewed-by: Nicolin Chen

Re: [PATCH v5 05/21] vfio/iommufd: Force creating nested parent domain

2025-08-22 Thread Nicolin Chen
like a "parent" item that lives inside another parent container. In kernel kdoc/uAPI, we use: - "nesting parent" for stage-2 object - "nested hwpt", "nested domain" for stage-1 object > + * domain which could be reused by vIOMMU to create nested domain. > + */ > +if (vfio_device_viommu_get_nested(vbasedev)) { With these addressed, Reviewed-by: Nicolin Chen

Re: [PATCH v5 07/21] intel_iommu: Introduce a new structure VTDHostIOMMUDevice

2025-08-22 Thread Nicolin Chen
will be used in future > patches. > > Signed-off-by: Zhenzhong Duan > Reviewed-by: Eric Auger Reviewed-by: Nicolin Chen

Re: [PATCH v5 04/21] vfio: Introduce helper vfio_pci_from_vfio_device()

2025-08-22 Thread Nicolin Chen via
ally accepted one now, as this PATCH-04 would be? IOW, the commit should probably have a link to this patch instead. Also, in general, your "Signed-off-by" should be the last line, when you submit a patch. With that, Reviewed-by: Nicolin Chen > diff --git a/hw/vfio/pci.h b/hw/vfio/

Re: [PATCH v5 01/21] intel_iommu: Rename vtd_ce_get_rid2pasid_entry to vtd_ce_get_pasid_entry

2025-08-22 Thread Nicolin Chen via
; No functional change intended. > > Signed-off-by: Zhenzhong Duan > Reviewed-by: Clément Mathieu--Drif > Reviewed-by: Yi Liu > Reviewed-by: Eric Auger Reviewed-by: Nicolin Chen > @@ -944,7 +944,7 @@ static int vtd_get_pe_from_pasid_table(IntelIOMMUState *s, >

Re: [PATCH v5 03/21] intel_iommu: Implement get_viommu_cap() callback

2025-08-22 Thread Nicolin Chen
in following patches. > > Suggested-by: Yi Liu > Signed-off-by: Zhenzhong Duan > Reviewed-by: Eric Auger Reviewed-by: Nicolin Chen

Re: [PATCH v5 02/21] hw/pci: Introduce pci_device_get_viommu_cap()

2025-08-22 Thread Nicolin Chen
... > pci_device_set_iommu_device(hiod) > > Suggested-by: Yi Liu > Signed-off-by: Zhenzhong Duan Reviewed-by: Nicolin Chen

Re: [RFC PATCH v3 06/15] hw/arm/smmuv3-accel: Restrict accelerated SMMUv3 to vfio-pci endpoints with iommufd

2025-08-05 Thread Nicolin Chen
Hi Shameer, On Mon, Jul 14, 2025 at 04:59:32PM +0100, Shameer Kolothum wrote: > @@ -25,30 +31,72 @@ static SMMUv3AccelDevice *smmuv3_accel_get_dev(SMMUState > *bs, SMMUPciBus *sbus, > > sbus->pbdev[devfn] = sdev; > smmu_init_sdev(bs, sdev, bus, devfn); > +address_space

Re: [PATCH v4 02/20] hw/pci: Introduce pci_device_get_viommu_cap()

2025-08-04 Thread Nicolin Chen
On Wed, Jul 30, 2025 at 10:51:13AM +, Duan, Zhenzhong wrote: > >> 2. there can also be more than one vIOMMUs with different user > >> configuration, e.g., arm smmuv3. That's correct. But would you please elaborate how different user configurations would benefit from this new op? I don't se

Re: [RFC PATCH v3 14/15] Read and validate host SMMUv3 feature bits

2025-07-22 Thread Nicolin Chen
On Mon, Jul 14, 2025 at 04:59:40PM +0100, Shameer Kolothum wrote: > +void smmuv3_accel_init_regs(SMMUv3State *s) > +{ > +SMMUv3AccelState *s_accel = s->s_accel; > +SMMUv3AccelDevice *accel_dev; > +uint32_t data_type; > +uint32_t val; > +int ret; > + > +if (s_accel->info.idr[

Re: [PATCH v8 08/12] hw/arm/virt: Allow user-creatable SMMUv3 dev instantiation

2025-07-18 Thread Nicolin Chen
On Fri, Jul 18, 2025 at 08:22:09AM +, Shameerali Kolothum Thodi wrote: > > So, my question was: where do we set the number of 4 to the sbdev? > > As platform_bus_get_irqn() returned very correctly with 0, 4, 8, > > and so on.. > > See smmu_realize() --> smmu_init_irq() > > And then in virt_ma

Re: [PATCH v8 08/12] hw/arm/virt: Allow user-creatable SMMUv3 dev instantiation

2025-07-18 Thread Nicolin Chen
On Fri, Jul 18, 2025 at 08:01:22AM +, Shameerali Kolothum Thodi wrote: > > > +int irq = platform_bus_get_irqn(pbus, sbdev, 0); > > > +hwaddr base = platform_bus_get_mmio_addr(pbus, sbdev, 0); > > > +MachineState *ms = MACHINE(vms); > > > + > > > +if (!(vms->bootinfo.firmware_loa

Re: [PATCH v8 08/12] hw/arm/virt: Allow user-creatable SMMUv3 dev instantiation

2025-07-17 Thread Nicolin Chen
Hi Shameer, On Fri, Jul 11, 2025 at 09:47:45AM +0100, Shameer Kolothum wrote: > +static void create_smmuv3_dev_dtb(VirtMachineState *vms, > + DeviceState *dev, PCIBus *bus) > +{ > +PlatformBusDevice *pbus = PLATFORM_BUS_DEVICE(vms->platform_bus_dev); > +Sy

Re: [PATCH v8 00/12] hw/arm/virt: Add support for user creatable SMMUv3 device

2025-07-17 Thread Nicolin Chen
x27;ve tested this series using the latest vSMMU RFCv3: https://lore.kernel.org/qemu-devel/20250714155941.22176-1-shameerali.kolothum.th...@huawei.com/ I was able to create four vSMMU instances with four pxb buses, then to pass through four vfio-pci devices to a VM. Tested-by: Nicolin Chen

Re: [RFC PATCH v3 14/15] Read and validate host SMMUv3 feature bits

2025-07-16 Thread Nicolin Chen
On Wed, Jul 16, 2025 at 03:42:39PM -0300, Jason Gunthorpe wrote: > On Wed, Jul 16, 2025 at 11:09:45AM -0700, Nicolin Chen wrote: > > OK. I see your point. That will leads to a very long list of > > parameters. > > I would have some useful prebaked ones. Realistically ther

Re: [RFC PATCH v3 14/15] Read and validate host SMMUv3 feature bits

2025-07-16 Thread Nicolin Chen
On Wed, Jul 16, 2025 at 10:26:21AM +, Shameerali Kolothum Thodi wrote: > > On Mon, Jul 14, 2025 at 04:59:40PM +0100, Shameer Kolothum wrote: > > My vSMMU didn't work until I added entries like SIDSIZE, SSIDSIZE, > > TERM_MODEL, STALL_MODEL, and RIL. > > How come your vSMMU not working? Or you

Re: [RFC PATCH v3 06/15] hw/arm/smmuv3-accel: Restrict accelerated SMMUv3 to vfio-pci endpoints with iommufd

2025-07-16 Thread Nicolin Chen
On Wed, Jul 16, 2025 at 10:51:23AM -0700, Nicolin Chen wrote: > On Wed, Jul 16, 2025 at 09:34:04AM +, Shameerali Kolothum Thodi wrote: > > > >> Seems aggressive for a hotplug, could we fail hotplug instead of kill > > > QEMU? > > > > > > > >H

Re: [RFC PATCH v3 09/15] hw/arm/smmuv3-accel: Support nested STE install/uninstall support

2025-07-16 Thread Nicolin Chen
On Wed, Jul 16, 2025 at 08:36:38AM +, Shameerali Kolothum Thodi wrote: > > > +g_hash_table_foreach(bs->configs, smmuv3_accel_ste_range, range); > > > > This will not work correctly? > > > > The bs->configs is a cache that gets an entry inserted to when a > > config is fetched via smmuv3_g

Re: [RFC PATCH v3 14/15] Read and validate host SMMUv3 feature bits

2025-07-16 Thread Nicolin Chen
On Wed, Jul 16, 2025 at 02:45:06PM -0300, Jason Gunthorpe wrote: > On Wed, Jul 16, 2025 at 10:35:25AM -0700, Nicolin Chen wrote: > > On Wed, Jul 16, 2025 at 08:51:23AM -0300, Jason Gunthorpe wrote: > > > On Tue, Jul 15, 2025 at 07:57:57PM -0700, Nicolin Chen wrote: > > >

Re: [RFC PATCH v3 06/15] hw/arm/smmuv3-accel: Restrict accelerated SMMUv3 to vfio-pci endpoints with iommufd

2025-07-16 Thread Nicolin Chen
On Wed, Jul 16, 2025 at 09:34:04AM +, Shameerali Kolothum Thodi wrote: > > >> Seems aggressive for a hotplug, could we fail hotplug instead of kill > > QEMU? > > > > > >Hotplug will unlikely be supported well, as it would introduce > > >too much complication. > > > > > >With iommufd, a vIOMMU o

Re: [RFC PATCH v3 14/15] Read and validate host SMMUv3 feature bits

2025-07-16 Thread Nicolin Chen
On Wed, Jul 16, 2025 at 08:51:23AM -0300, Jason Gunthorpe wrote: > On Tue, Jul 15, 2025 at 07:57:57PM -0700, Nicolin Chen wrote: > > > +val = FIELD_EX32(s_accel->info.idr[5], IDR5, GRAN4K); > > > +if (val < FIELD_EX32(s->idr[5], IDR5, GRAN4K)) { > > >

Re: [RFC PATCH v3 14/15] Read and validate host SMMUv3 feature bits

2025-07-15 Thread Nicolin Chen via
On Mon, Jul 14, 2025 at 04:59:40PM +0100, Shameer Kolothum wrote: > From: Nicolin Chen > > Not all fields in the SMMU IDR registers are meaningful for userspace. > Only the following fields can be used: > >   - IDR0: ST_LEVEL, TERM_MODEL, STALL_MODEL, TTENDIAN, CD2L, ASID16

Re: [RFC PATCH v3 09/15] hw/arm/smmuv3-accel: Support nested STE install/uninstall support

2025-07-15 Thread Nicolin Chen
On Mon, Jul 14, 2025 at 04:59:35PM +0100, Shameer Kolothum wrote: > +static void > +smmuv3_accel_ste_range(gpointer key, gpointer value, gpointer user_data) > +{ > +SMMUDevice *sdev = (SMMUDevice *)key; > +uint32_t sid = smmu_get_sid(sdev); > +SMMUSIDRange *sid_range = (SMMUSIDRange *)u

Re: [RFC PATCH v3 06/15] hw/arm/smmuv3-accel: Restrict accelerated SMMUv3 to vfio-pci endpoints with iommufd

2025-07-15 Thread Nicolin Chen
On Tue, Jul 15, 2025 at 10:53:50AM +, Duan, Zhenzhong wrote: > > > >-Original Message- > >From: Shameer Kolothum > >Subject: [RFC PATCH v3 06/15] hw/arm/smmuv3-accel: Restrict accelerated > >SMMUv3 to vfio-pci endpoints with iommufd > > > >Accelerated SMMUv3 is only useful when the d

Re: [RFC PATCH v3 05/15] hw/arm/smmuv3-accel: Introduce smmuv3 accel device

2025-07-15 Thread Nicolin Chen
On Tue, Jul 15, 2025 at 10:48:31AM +, 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-sm

Re: [RFC PATCH v3 13/15] hw/arm/smmuv3: Forward invalidation commands to hw

2025-07-15 Thread Nicolin Chen
On Tue, Jul 15, 2025 at 11:46:09AM +0100, Jonathan Cameron wrote: > > SMMUCmdError cmd_error = SMMU_CERROR_NONE; > > SMMUQueue *q = &s->cmdq; > > SMMUCommandType type = 0; > > +SMMUCommandBatch batch = {}; > > +uint32_t ncmds; > > > > if (!smmuv3_cmdq_enabled(s)) { > >

Re: [RFC PATCH v3 12/15] hw/arm/smmuv3-accel: Introduce helpers to batch and issue cache invalidations

2025-07-15 Thread Nicolin Chen
On Tue, Jul 15, 2025 at 11:39:54AM +0100, Jonathan Cameron wrote: > > +/* Update batch->ncmds to the number of execute cmds */ > > Not obvious what the return value here means. Maybe a comment? I think it would be clear once we fix the typo in the current one: s/execute/executed That being said

Re: [RFC PATCH v3 08/15] hw/arm/smmuv3-accel: Add set/unset_iommu_device callback

2025-07-15 Thread Nicolin Chen
On Tue, Jul 15, 2025 at 11:29:41AM +0100, Jonathan Cameron wrote: > > +if (!iommufd_backend_alloc_viommu(idev->iommufd, idev->devid, > > + IOMMU_VIOMMU_TYPE_ARM_SMMUV3, > > + s2_hwpt_id, &viommu_id, errp)) { > > +

Re: [RFC PATCH v3 00/15] hw/arm/virt: Add support for user-creatable accelerated SMMUv3

2025-07-14 Thread Nicolin Chen via
On Mon, Jul 14, 2025 at 09:14:17AM -0700, Nicolin Chen wrote: > Hi Shameer, > > Thank you for sending the v3. > > On Mon, Jul 14, 2025 at 04:59:26PM +0100, Shameer Kolothum wrote: > > Branch for testing: > [...] > > Tested on a HiSilicon platform with multiple S

Re: [RFC PATCH v3 14/15] Read and validate host SMMUv3 feature bits

2025-07-14 Thread Nicolin Chen via
On Mon, Jul 14, 2025 at 01:04:02PM -0700, Nicolin Chen wrote: > On Mon, Jul 14, 2025 at 04:59:40PM +0100, Shameer Kolothum wrote: > > From: Nicolin Chen > > > > Not all fields in the SMMU IDR registers are meaningful for userspace. > > Only the following fields can

Re: [RFC PATCH v3 08/15] hw/arm/smmuv3-accel: Add set/unset_iommu_device callback

2025-07-14 Thread Nicolin Chen
On Mon, Jul 14, 2025 at 04:59:34PM +0100, Shameer Kolothum wrote: > From: Nicolin Chen > > Implement a set_iommu_device callback: > -If found an existing viommu reuse that. >(Devices behind the same physical SMMU should share an S2 HWPT) > -Else, > Allocate a v

Re: [RFC PATCH v3 14/15] Read and validate host SMMUv3 feature bits

2025-07-14 Thread Nicolin Chen via
On Mon, Jul 14, 2025 at 04:59:40PM +0100, Shameer Kolothum wrote: > From: Nicolin Chen > > Not all fields in the SMMU IDR registers are meaningful for userspace. > Only the following fields can be used: > >   - IDR0: ST_LEVEL, TERM_MODEL, STALL_MODEL, TTENDIAN, CD2L, ASID16

Re: [RFC PATCH v3 15/15] hw/arm/smmu-common: Add accel property for SMMU dev

2025-07-14 Thread Nicolin Chen
On Mon, Jul 14, 2025 at 04:59:41PM +0100, Shameer Kolothum wrote: > Now user can set "accel=on". Have fun! > > Signed-off-by: Shameer Kolothum Reviewed-by: Nicolin Chen

Re: [RFC PATCH v3 12/15] hw/arm/smmuv3-accel: Introduce helpers to batch and issue cache invalidations

2025-07-14 Thread Nicolin Chen
On Mon, Jul 14, 2025 at 04:59:38PM +0100, Shameer Kolothum wrote: > diff --git a/hw/arm/smmuv3-accel.h b/hw/arm/smmuv3-accel.h > index 21028e60c8..d06c9664ba 100644 > --- a/hw/arm/smmuv3-accel.h > +++ b/hw/arm/smmuv3-accel.h > @@ -13,6 +13,7 @@ > #include "hw/arm/smmu-common.h" > #include "system

Re: [RFC PATCH v3 11/15] hw/pci/pci: Introduce optional get_msi_address_space() callback.

2025-07-14 Thread Nicolin Chen
lems when MSI doorbells need to be translated. > > To fix this, introduce an optional get_msi_address_space() callback. > In the SMMUv3 accelerated case, this callback returns the IOMMU address > space if the guest has set up S1 translations for the vfio-pci device. > Otherwise,

Re: [RFC PATCH v3 10/15] hw/arm/smmuv3-accel: Allocate a vDEVICE object for device

2025-07-14 Thread Nicolin Chen
On Mon, Jul 14, 2025 at 04:59:36PM +0100, Shameer Kolothum wrote: > diff --git a/hw/arm/smmuv3-accel.c b/hw/arm/smmuv3-accel.c > index 74bf20cfaf..f1584dd775 100644 > --- a/hw/arm/smmuv3-accel.c > +++ b/hw/arm/smmuv3-accel.c > @@ -93,6 +93,23 @@ void smmuv3_accel_install_nested_ste(SMMUState *bs,

Re: [RFC PATCH v3 09/15] hw/arm/smmuv3-accel: Support nested STE install/uninstall support

2025-07-14 Thread Nicolin Chen
On Mon, Jul 14, 2025 at 04:59:35PM +0100, Shameer Kolothum wrote: > +static int > +smmuv3_accel_dev_install_nested_ste(SMMUv3AccelDevice *accel_dev, > +uint32_t data_type, uint32_t data_len, > +void *data) > +{ > +SMMUViomm

Re: [RFC PATCH v3 07/15] hw/arm/smmuv3: Implement get_viommu_cap() callback

2025-07-14 Thread Nicolin Chen
ured > in Stage 1 mode, ensure that the 'stage' property is explicitly set to > Stage 1. > > Signed-off-by: Shameer Kolothum Reviewed-by: Nicolin Chen > @@ -81,8 +82,22 @@ static AddressSpace *smmuv3_accel_find_add_as(PCIBus *bus, > void *opaque, > } > }

Re: [RFC PATCH v3 06/15] hw/arm/smmuv3-accel: Restrict accelerated SMMUv3 to vfio-pci endpoints with iommufd

2025-07-14 Thread Nicolin Chen
n associated > SID, making it difficult to trace the originating device. If we allowed > emulated endpoint devices, QEMU would have to invalidate both its own > software IOTLB and the host's hardware IOTLB, which could slow things > down. Change looks good to me, Reviewed-by: Nicolin

Re: [RFC PATCH v3 05/15] hw/arm/smmuv3-accel: Introduce smmuv3 accel device

2025-07-14 Thread Nicolin Chen
ot set it at this > point. It will be introduced in a subsequent patch once the necessary > support is in place. > > Signed-off-by: Shameer Kolothum Overall the patch looks good to me, Reviewed-by: Nicolin Chen with some nits: > @@ -61,7 +61,8 @@ arm_common_ss.add(when: 

Re: [RFC PATCH v3 04/15] hw/arm/smmu-common: Introduce smmu_iommu_ops_by_type() helper

2025-07-14 Thread Nicolin Chen via
> No special handling is required for now and returns the default ops > in base SMMU Class. > > No functional changes intended. > > Signed-off-by: Shameer Kolothum Reviewed-by: Nicolin Chen > +static const PCIIOMMUOps *smmu_iommu_ops_by_type(SMMUState *s) > +{ >

Re: [RFC PATCH v3 02/15] backends/iommufd: Introduce iommufd_vdev_alloc

2025-07-14 Thread Nicolin Chen
On Mon, Jul 14, 2025 at 04:59:28PM +0100, Shameer Kolothum wrote: > +bool iommufd_backend_alloc_vdev(IOMMUFDBackend *be, uint32_t dev_id, > +uint32_t viommu_id, uint64_t virt_id, > +uint32_t *out_vdev_id, Error **errp) > +{ > +int

Re: [RFC PATCH v3 01/15] backends/iommufd: Introduce iommufd_backend_alloc_viommu

2025-07-14 Thread Nicolin Chen
On Mon, Jul 14, 2025 at 04:59:27PM +0100, Shameer Kolothum wrote: > +bool iommufd_backend_alloc_viommu(IOMMUFDBackend *be, uint32_t dev_id, > + uint32_t viommu_type, uint32_t hwpt_id, > + uint32_t *out_viommu_id, Error **errp) > +{ >

Re: [RFC PATCH v3 00/15] hw/arm/virt: Add support for user-creatable accelerated SMMUv3

2025-07-14 Thread Nicolin Chen via
Hi Shameer, Thank you for sending the v3. On Mon, Jul 14, 2025 at 04:59:26PM +0100, Shameer Kolothum wrote: > Branch for testing: [...] > Tested on a HiSilicon platform with multiple SMMUv3s. > > ./qemu-system-aarch64 \ >   -machine virt,accel=kvm,gic-version=3 \ >   -object iommufd,id=iommufd0

Re: [PATCH v7 00/12] hw/arm/virt: Add support for user creatable SMMUv3 device

2025-07-10 Thread Nicolin Chen
Hi Peter, On Thu, Jul 10, 2025 at 12:48:20PM +0100, Peter Maydell wrote: > On Thu, 10 Jul 2025 at 11:10, Shameerali Kolothum Thodi > > > Changes from v6: > > > https://lore.kernel.org/qemu-devel/20250703084643.85740-1- > > > shameerali.kolothum.th...@huawei.com/ > > > > > > 1. Fixed the warning ca

Re: [PATCH v7 07/12] hw/pci: Introduce pci_setup_iommu_per_bus() for per-bus IOMMU ops retrieval

2025-07-10 Thread Nicolin Chen
r_bus when > determining the correct IOMMU ops, ensuring accurate behavior for > per-bus IOMMUs. > > Reviewed-by: Jonathan Cameron > Reviewed-by: Eric Auger > Tested-by: Nathan Chen > Tested-by: Eric Auger > Signed-off-by: Shameer Kolothum Reviewed-by: Nicolin Chen With a

Re: [PATCH v7 07/12] hw/pci: Introduce pci_setup_iommu_per_bus() for per-bus IOMMU ops retrieval

2025-07-10 Thread Nicolin Chen
On Thu, Jul 10, 2025 at 09:40:28PM +, Shameerali Kolothum Thodi wrote: > > So, the logic is trying to avoid: > > "iommu_bus = parent_bus;" > > for a case that parent_bus (pcie.0) having its own IOMMU. > > > > But shouldn't it be just "if (parent_bus->iommu_per_bus)"? > > > > Why does

Re: [PATCH v3 02/20] hw/pci: Introduce pci_device_get_viommu_cap()

2025-07-10 Thread Nicolin Chen
On Thu, Jul 10, 2025 at 01:07:11PM -0400, Donald Dutile wrote: > > > > If not, maybe go a bit further like "VIOMMU_CAP_HW_NESTED_S1"? > > > > > > I am not sure the _S1 part makes much sense in ARM case. It doesn't matter > > > whether the Guest SMMUv3 is configured in s1/s2 or nested for this CAP.

Re: [PATCH v3 02/20] hw/pci: Introduce pci_device_get_viommu_cap()

2025-07-10 Thread Nicolin Chen
On Thu, Jul 10, 2025 at 08:11:28AM +, Shameerali Kolothum Thodi wrote: > > So I suggested: > > /* hardware-accelerated nested stage-1 page table support */ > > VIOMMU_CAP_NESTED_S1 = BIT_ULL(0), > > > > which it should be clear IMHO. > > > > If not, maybe go a bit further like "VIOMM

Re: [PATCH v7 02/12] hw/arm/smmu-common: Check SMMU has PCIe Root Complex association

2025-07-10 Thread Nicolin Chen
s added and validated with SMMUv3. > > Reviewed-by: Jonathan Cameron > Reviewed-by: Eric Auger > Tested-by: Nathan Chen > Tested-by: Eric Auger > Signed-off-by: Shameer Kolothum Reviewed-by: Nicolin Chen With a small suggestion for clarification. > +/* > + * We

Re: [PATCH v7 02/12] hw/arm/smmu-common: Check SMMU has PCIe Root Complex association

2025-07-10 Thread Nicolin Chen
On Thu, Jul 10, 2025 at 07:27:10AM +, Shameerali Kolothum Thodi wrote: > > On Wed, Jul 09, 2025 at 08:08:49AM +, Shameerali Kolothum Thodi > > wrote: > > > > On Tue, Jul 08, 2025 at 04:40:45PM +0100, Shameer Kolothum wrote: > > > > > @@ -937,11 +939,32 @@ static void smmu_base_realize(Devic

Re: [PATCH v7 07/12] hw/pci: Introduce pci_setup_iommu_per_bus() for per-bus IOMMU ops retrieval

2025-07-10 Thread Nicolin Chen
On Thu, Jul 10, 2025 at 04:21:41PM +, Shameerali Kolothum Thodi wrote: > > >> On Wed, Jul 09, 2025 at 08:20:35AM +, Shameerali Kolothum Thodi > > >> wrote: > > On Tue, Jul 08, 2025 at 04:40:50PM +0100, Shameer Kolothum wrote: > > > @@ -2909,6 +2909,19 @@ static void > > pci_de

Re: [PATCH v7 07/12] hw/pci: Introduce pci_setup_iommu_per_bus() for per-bus IOMMU ops retrieval

2025-07-09 Thread Nicolin Chen
On Wed, Jul 09, 2025 at 08:20:35AM +, Shameerali Kolothum Thodi wrote: > > On Tue, Jul 08, 2025 at 04:40:50PM +0100, Shameer Kolothum wrote: > > > @@ -2909,6 +2909,19 @@ static void > > pci_device_get_iommu_bus_devfn(PCIDevice *dev, > > > } > > > } > > > > > > +/*

Re: [PATCH v7 02/12] hw/arm/smmu-common: Check SMMU has PCIe Root Complex association

2025-07-09 Thread Nicolin Chen
On Wed, Jul 09, 2025 at 08:08:49AM +, Shameerali Kolothum Thodi wrote: > > On Tue, Jul 08, 2025 at 04:40:45PM +0100, Shameer Kolothum wrote: > > > @@ -937,11 +939,32 @@ static void smmu_base_realize(DeviceState > > *dev, Error **errp) > > > g_free, g_free);

Re: [PATCH v3 02/20] hw/pci: Introduce pci_device_get_viommu_cap()

2025-07-09 Thread Nicolin Chen
On Wed, Jul 09, 2025 at 01:55:46PM -0400, Donald Dutile wrote: > > > +enum { > > > +VIOMMU_CAP_STAGE1 = BIT_ULL(0), /* stage1 page table supported */ > > > +}; > > > > Thanks for this work. I am happy to see that we can share the > > common code that allocates a NESTING_PARENT in the core usi

Re: [PATCH v3 02/20] hw/pci: Introduce pci_device_get_viommu_cap()

2025-07-08 Thread Nicolin Chen
On Wed, Jul 09, 2025 at 03:38:49AM +, Duan, Zhenzhong wrote: > >> +enum { > >> +VIOMMU_CAP_STAGE1 = BIT_ULL(0), /* stage1 page table > >supported */ > >> +}; > > > >Thanks for this work. I am happy to see that we can share the > >common code that allocates a NESTING_PARENT in the core usin

Re: [PATCH v3 02/20] hw/pci: Introduce pci_device_get_viommu_cap()

2025-07-08 Thread Nicolin Chen
On Tue, Jul 08, 2025 at 07:05:43AM -0400, Zhenzhong Duan wrote: > diff --git a/include/hw/iommu.h b/include/hw/iommu.h > new file mode 100644 > index 00..e80aaf4431 > --- /dev/null > +++ b/include/hw/iommu.h > @@ -0,0 +1,16 @@ > +/* > + * General vIOMMU capabilities, flags, etc > + * > + *

Re: [PATCH v7 08/12] hw/arm/virt: Allow user-creatable SMMUv3 dev instantiation

2025-07-08 Thread Nicolin Chen
; limited to cases where it is attached to the default pcie.0 root complex. > > Reviewed-by: Jonathan Cameron > Reviewed-by: Eric Auger > Tested-by: Nathan Chen > Tested-by: Eric Auger > Signed-off-by: Shameer Kolothum Reviewed-by: Nicolin Chen

Re: [PATCH v7 07/12] hw/pci: Introduce pci_setup_iommu_per_bus() for per-bus IOMMU ops retrieval

2025-07-08 Thread Nicolin Chen
On Tue, Jul 08, 2025 at 04:40:50PM +0100, Shameer Kolothum wrote: > @@ -2909,6 +2909,19 @@ static void pci_device_get_iommu_bus_devfn(PCIDevice > *dev, > } > } > > +/* > + * When multiple PCI Express Root Buses are defined using pxb-pcie, > + * the I

Re: [PATCH v7 02/12] hw/arm/smmu-common: Check SMMU has PCIe Root Complex association

2025-07-08 Thread Nicolin Chen
On Tue, Jul 08, 2025 at 04:40:45PM +0100, Shameer Kolothum wrote: > @@ -937,11 +939,32 @@ static void smmu_base_realize(DeviceState *dev, Error > **errp) > g_free, g_free); > s->smmu_pcibus_by_busptr = g_hash_table_new(NULL, NULL); Although this is not i

Re: [PATCH v6 00/12] hw/arm/virt: Add support for user creatable SMMUv3 device

2025-07-08 Thread Nicolin Chen
On Tue, Jul 08, 2025 at 08:57:37AM +, Shameerali Kolothum Thodi wrote: > > Thank you for the effort and the work here. > > > > A separate topic: do you have any preparation for the vIOMMU uAPI > > patches (iommufd backends) in QEMU? > > > > I think it should be the next step after this series

Re: [PATCH v6 00/12] hw/arm/virt: Add support for user creatable SMMUv3 device

2025-07-08 Thread Nicolin Chen
On Thu, Jul 03, 2025 at 09:46:31AM +0100, Shameer Kolothum wrote: > 1. Rebased to target-arm.next and resolved conflicts with the series >[PATCH-for-10.1 v6 0/9] hw/arm: GIC 'its=off'. > 2. While at it, noticed an issue with RC id mappings creation >and patch #1 is a fix for that. > 3. Pat

Re: [PATCH rfcv3 15/21] intel_iommu: Bind/unbind guest page table to host

2025-06-16 Thread Nicolin Chen
On Mon, Jun 16, 2025 at 08:15:11AM +, Duan, Zhenzhong wrote: > >IIUIC, the guest kernel cmdline can switch the mode between the > >stage1 (nesting) and stage2 (legacy/emulated VT-d), right? > > Right. E.g., kexec from "intel_iommu=on,sm_on" to "intel_iommu=on,sm_off", > Then first kernel will

Re: [PATCH rfcv3 15/21] intel_iommu: Bind/unbind guest page table to host

2025-06-16 Thread Nicolin Chen
On Mon, Jun 16, 2025 at 03:38:26PM +0800, Yi Liu wrote: > On 2025/6/16 13:59, Nicolin Chen wrote: > > On Thu, Jun 12, 2025 at 08:53:40PM +0800, Yi Liu wrote: > > > > > That being said, IOMMU_NOTIFIER_IOTLB_EVENTS should not be needed > > > > > for passthro

Re: [PATCH rfcv3 15/21] intel_iommu: Bind/unbind guest page table to host

2025-06-16 Thread Nicolin Chen
On Mon, Jun 16, 2025 at 03:24:06AM +, Duan, Zhenzhong wrote: > Hi @Liu, Yi L @Nicolin Chen, for emulated/passthru devices > behind the same pcie-pci bridge, I think of an idea, adding > a new PCI callback: > > AddressSpace * (*get_address_space_extend)(PCIBus *bus, > void

Re: [PATCH rfcv3 15/21] intel_iommu: Bind/unbind guest page table to host

2025-06-15 Thread Nicolin Chen
On Thu, Jun 12, 2025 at 02:06:15PM +, Shameerali Kolothum Thodi wrote: > > >> The "switch" in vSMMU model is only needed by KVM for MSI doorbell > > >> translation. By thinking it carefully, maybe it shouldn't switch AS > > >> because VFIO might be confused if it somehow does get_address_space

Re: [PATCH rfcv3 15/21] intel_iommu: Bind/unbind guest page table to host

2025-06-15 Thread Nicolin Chen
On Thu, Jun 12, 2025 at 08:53:40PM +0800, Yi Liu wrote: > > > That being said, IOMMU_NOTIFIER_IOTLB_EVENTS should not be needed > > > for passthrough devices, right? > > > > No, even if x-flts=on is configured in QEMU cmdline, that only mean virtual > > vtd > > supports stage-1 translation, guest

Re: [PATCH rfcv3 15/21] intel_iommu: Bind/unbind guest page table to host

2025-06-15 Thread Nicolin Chen
Sorry for a late reply. On Wed, May 28, 2025 at 07:12:25AM +, Duan, Zhenzhong wrote: > >Third, the vSMMU model, for invalidation efficiency and HW Queue > >support, isolates all emulated devices out of the nesting-enabled > >vSMMU instance, suggested by Jason. So, only passthrough devices > >w

Re: [PATCH v4 2/7] hw/arm/virt-acpi-build: Re-arrange SMMUv3 IORT build

2025-06-15 Thread Nicolin Chen
l > soon add support for user-creatable SMMUv3 devices. These changes will > be useful to have common code paths when we add that support. > > Tested-by: Nathan Chen > Signed-off-by: Shameer Kolothum Reviewed-by: Nicolin Chen > +static void > +populate_smmuv3_legacy_dev(GArray

Re: [PATCH v4 7/7] qemu-options.hx: Document the arm-smmuv3 device

2025-06-15 Thread Nicolin Chen
On Fri, Jun 13, 2025 at 03:44:49PM +0100, Shameer Kolothum wrote: > Now that arm,virt can have user-creatable smmuv3 devices, document it. > > Signed-off-by: Shameer Kolothum Reviewed-by: Nicolin Chen

Re: [PATCH v4 6/7] hw/arm/virt: Allow user-creatable SMMUv3 dev instantiation

2025-06-15 Thread Nicolin Chen
he default pcie.0 RC. I forgot the detail for this limitation. Maybe spare a few more words briefly describing why? > Tested-by: Nathan Chen > Signed-off-by: Shameer Kolothum Reviewed-by: Nicolin Chen

Re: [PATCH v4 3/7] hw/arm/virt-acpi-build: Update IORT for multiple smmuv3 devices

2025-06-15 Thread Nicolin Chen
| 0x - 0x00FF (from RC0) | > | 0x0100 - 0x01FF (from RC1) | > | 0x0200 - 0x (No SMMU) | > ++ > > Tested-by: Nathan Chen > Signed-off-by: Shameer Kolothum Reviewed-by: Nicolin Chen

Re: [PATCH v4 1/7] hw/arm/smmu-common: Check SMMU has PCIe Root Complex association

2025-06-15 Thread Nicolin Chen
olothum Reviewed-by: Nicolin Chen

Re: [PATCH v2 4/4] vfio/iommufd: Save vendor specific device info

2025-05-30 Thread Nicolin Chen
; capability directly. > > Because IOMMU_GET_HW_INFO is only supported in linux, so declare those > capability related structures with CONFIG_LINUX. > > Suggested-by: Eric Auger > Suggested-by: Nicolin Chen > Signed-off-by: Zhenzhong Duan Reviewed-by: Nicolin Chen I like

Re: [PATCH v2 2/4] vfio/iommufd: Add properties and handlers to TYPE_HOST_IOMMU_DEVICE_IOMMUFD

2025-05-30 Thread Nicolin Chen
On Fri, May 30, 2025 at 05:35:10PM +0800, Zhenzhong Duan wrote: > Enhance HostIOMMUDeviceIOMMUFD object with 3 new members, specific > to the iommufd BE + 2 new class functions. > > IOMMUFD BE includes IOMMUFD handle, devid and hwpt_id. IOMMUFD handle > and devid are used to allocate/free ioas and

  1   2   3   >