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
; 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:
> +/*
&
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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,
>
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
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
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:
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,
> {
ger
Reviewed-by: 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
will be used in future
> patches.
>
> Signed-off-by: Zhenzhong Duan
> Reviewed-by: Eric Auger
Reviewed-by: Nicolin Chen
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/
; 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,
>
in following patches.
>
> Suggested-by: Yi Liu
> Signed-off-by: Zhenzhong Duan
> Reviewed-by: Eric Auger
Reviewed-by: Nicolin Chen
...
> pci_device_set_iommu_device(hiod)
>
> Suggested-by: Yi Liu
> Signed-off-by: Zhenzhong Duan
Reviewed-by: 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
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
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[
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
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
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
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
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
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
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
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
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:
> > >
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
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)) {
> > >
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
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
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
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
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)) {
> >
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
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)) {
> > +
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
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
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
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
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
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
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,
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,
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
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,
> }
> }
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
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:
> 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)
> +{
>
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
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)
> +{
>
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
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
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
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
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.
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
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
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
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
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,
> > > }
> > > }
> > >
> > > +/*
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);
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
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
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
> + *
> + *
; 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
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
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
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
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
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
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
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
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
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
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
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
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
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
| 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
olothum
Reviewed-by: 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
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 - 100 of 220 matches
Mail list logo