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
ater
Reviewed-by: Nicolin Chen
> +static bool
> +host_iommu_device_iommufd_vfio_attach_hwpt(HostIOMMUDeviceIOMMUFD *idev,
> + uint32_t hwpt_id, Error **errp)
> +{
> +VFIODevice *vbasedev = HOST_IOMMU_DEVICE(idev)->agent;
> +
>
On Thu, May 29, 2025 at 06:46:20AM +, Duan, Zhenzhong wrote:
> >Looking at the kernel iommufd_hwpt_invalidate() routine and
> >intel_nested_cache_invalidate_user(), it doesn't seem possible to
> >return a different number of cache entries. Are you anticipating
> >other implementations (sMMU) ?
OK. Let me clarify this at the top as I see the gap here now:
First, the vSMMU model is based on Zhenzhong's older series that
keeps an ioas_id in the HostIOMMUDeviceIOMMUFD structure, which
now it only keeps an hwpt_id in this RFCv3 series. This ioas_id
is allocated when a passthrough cdev attach
Nic,
>
> On 2025/5/22 06:49, Nicolin Chen wrote:
> > On Wed, May 21, 2025 at 07:14:45PM +0800, Zhenzhong Duan wrote:
> > > +static const MemoryListener iommufd_s2domain_memory_listener = {
> > > +.name = "iommufd_s2domain",
> >
On Thu, May 22, 2025 at 09:21:04AM +, Duan, Zhenzhong wrote:
>
>
> >-Original Message-----
> >From: Nicolin Chen
> >Subject: Re: [PATCH rfcv3 05/21] vfio/iommufd: Save vendor specific device
> >info
> >
> >On Wed, May 21, 2025 at 07:14:35PM +
On Thu, May 22, 2025 at 06:50:42AM +, Duan, Zhenzhong wrote:
>
>
> >-Original Message-----
> >From: Nicolin Chen
> >Subject: Re: [PATCH rfcv3 15/21] intel_iommu: Bind/unbind guest page table to
> >host
> >
> >On Wed, May 21, 2025 at 07:14:45PM
On Wed, May 21, 2025 at 07:14:45PM +0800, Zhenzhong Duan wrote:
> +static const MemoryListener iommufd_s2domain_memory_listener = {
> +.name = "iommufd_s2domain",
> +.priority = 1000,
> +.region_add = iommufd_listener_region_add_s2domain,
> +.region_del = iommufd_listener_region_del
On Wed, May 21, 2025 at 07:14:35PM +0800, Zhenzhong Duan wrote:
> @@ -852,6 +853,17 @@ static bool hiod_iommufd_vfio_realize(HostIOMMUDevice
> *hiod, void *opaque,
> caps->type = type;
> caps->hw_caps = hw_caps;
>
> +switch (type) {
> +case IOMMU_HW_INFO_TYPE_INTEL_VTD:
> +
On Mon, May 05, 2025 at 06:38:17PM +0200, Eric Auger wrote:
> > +/**
> > + * struct HostIOMMUDeviceIOMMUFDCaps - Define host IOMMU device
> > capabilities.
> > + *
> > + * @type: host platform IOMMU type.
> > + *
> > + * @hw_caps: host platform IOMMU capabilities (e.g. on IOMMUFD this
> > represe
On Fri, May 02, 2025 at 11:27:07AM +0100, Shameer Kolothum wrote:
> Signed-off-by: Shameer Kolothum
Though I think the commit log shouldn't be empty,
Reviewed-by: Nicolin Chen
On Fri, May 02, 2025 at 11:27:06AM +0100, Shameer Kolothum wrote:
> @@ -2972,6 +3004,21 @@ static void virt_machine_device_plug_cb(HotplugHandler
> *hotplug_dev,
> virtio_md_pci_plug(VIRTIO_MD_PCI(dev), MACHINE(hotplug_dev), errp);
> }
>
> +if (object_dynamic_cast(OBJECT(dev),
On Fri, May 02, 2025 at 11:27:02AM +0100, Shameer Kolothum wrote:
> Although this change does not affect functionality at present, it lays
> the groundwork for enabling user-created SMMUv3 devices in
> future patches
>
> Signed-off-by: Shameer Kolothum
Reviewed-by: Nicolin Chen
On Fri, May 02, 2025 at 11:27:04AM +0100, Shameer Kolothum wrote:
> No functional changes intended. This will be useful when we
> add support for user-creatable smmuv3 device.
>
> Signed-off-by: Shameer Kolothum
Reviewed-by: Nicolin Chen
_base - map_b->input_base;
> +}
> +
> +static void
> +get_smmuv3_legacy_dev(VirtMachineState *vms, GArray * smmuv3_devices)
GArray *smmuv3_devices
Or maybe align with the non-legacy path, i.e. "sdev_blob"? Or the
other way around.
Otherwise, lgtm
Reviewed-by: Nicolin Chen
On Wed, Mar 26, 2025 at 07:14:31PM +0100, Eric Auger wrote:
>
>
> On 3/11/25 3:10 PM, Shameer Kolothum wrote:
> > Now that we can have multiple user-creatable smmuv3-accel devices,
> > each associated with different pci buses, update IORT ID mappings
> > accordingly.
> >
> > Signed-off-by: Shamee
On Wed, Mar 19, 2025 at 09:26:29AM +, Shameerali Kolothum Thodi wrote:
> Having said that, current code only allows pxb-pcie root complexes avoiding
> the pcie.0. The idea behind this was, user can use pcie.0 with a non accel
> SMMUv3
> for any emulated devices avoiding the performance bottle
On Wed, Mar 26, 2025 at 06:40:10PM +0100, Eric Auger wrote:
> On 3/11/25 3:10 PM, Shameer Kolothum wrote:
> > From: Nicolin Chen
> >
> > If a vSMMU is configured as a accelerated one, HW IOTLB will be used
> > and all cache invalidation should be done to the HW IOTLB
On Wed, Mar 26, 2025 at 06:18:49PM +0100, Eric Auger wrote:
> > @@ -561,6 +561,16 @@ static int decode_ste(SMMUv3State *s, SMMUTransCfg
> > *cfg,
> >
> > decode_ste_config(cfg, config);
> >
> > + /* S1DSS.Terminate is same as Config.abort for default stream */
>
> S1DSS. Termination
On Wed, Mar 26, 2025 at 03:16:18PM +0100, Eric Auger wrote:
> > @@ -1395,6 +1403,13 @@ static int smmuv3_cmdq_consume(SMMUv3State *s)
> >
> > trace_smmuv3_cmdq_cfgi_cd(sid);
> > smmuv3_flush_config(sdev);
> > +
> > +if (smmuv3_accel_batch_cmds(sdev->smmu, sde
On Wed, Mar 26, 2025 at 02:38:04PM +0100, Eric Auger wrote:
> > +/* Update batch->ncmds to the number of execute cmds */
> > +int smmuv3_accel_issue_cmd_batch(SMMUState *bs, SMMUCommandBatch *batch)
> > +{
> > +SMMUv3AccelState *s_accel = ARM_SMMUV3_ACCEL(bs);
> > +uint32_t total = batch->n
On Tue, Mar 25, 2025 at 07:08:29PM +0100, Eric Auger wrote:
> > +static int
> > +smmuv3_accel_dev_install_nested_ste(SMMUv3AccelDevice *accel_dev,
> > +uint32_t data_type, uint32_t data_len,
> > +void *data)
> > +{
> > +SMM
On Tue, Mar 25, 2025 at 03:43:29PM +, Shameerali Kolothum Thodi wrote:
> > For the record I tested the series with host VFIO device and a
> > virtio-blk-pci device put behind the same pxb-pcie/smmu protection and
> > it works just fine
> >
> > -+-[:0a]-+-01.0-[0b]00.0 Mellanox Technol
On Mon, Mar 24, 2025 at 02:13:20PM +0100, Eric Auger wrote:
> >> If VM has an emulated device and a passthrough device:
> >> attach the emulated device to PCIE.0 <=> vSMMU bypass (or accel=off?)
> >> attach the passthrough device to pxb-pcie <=> vSMMU0 (accel=on)
> > This can be other way around
On Mon, Mar 24, 2025 at 08:19:27AM +, Shameerali Kolothum Thodi wrote:
> > If VM has an emulated device and a passthrough device:
> > attach the emulated device to PCIE.0 <=> vSMMU bypass (or accel=off?)
> > attach the passthrough device to pxb-pcie <=> vSMMU0 (accel=on)
>
> This can be othe
On Wed, Mar 19, 2025 at 07:09:33PM +0100, Eric Auger wrote:
> > Option means something like this:
> > -device smmuv3,accel=on
> > instead of
> > -device "smmuv3-accel"
> > ?
> >
> > Yea, I think that's good.
> Yeah actually that's a big debate for not much. From an implementation
> pov tha
On Wed, Mar 19, 2025 at 05:45:51PM +0100, Eric Auger wrote:
>
>
>
> On 3/17/25 8:10 PM, Nicolin Chen wrote:
> > On Mon, Mar 17, 2025 at 07:07:52PM +0100, Eric Auger wrote:
> >> On 3/17/25 6:54 PM, Nicolin Chen wrote:
> >>> On Wed, Mar 12, 2025 at 04:15:10
On Wed, Mar 19, 2025 at 12:24:32PM -0400, Donald Dutile wrote:
> > > On 3/11/25 10:10 AM, Shameer Kolothum wrote:
> > > > From: Nicolin Chen
> > > >
> > > > Inroduce an SMMUCommandBatch and some helpers to batch and issue
> > > the
>
On Tue, Mar 18, 2025 at 09:31:35PM -0300, Jason Gunthorpe wrote:
> On Tue, Mar 18, 2025 at 07:31:36PM +0100, Eric Auger wrote:
> > Nevertheless I don't think anything prevents the acceleration granted
> > device from also working with virtio/vhost devices for instance unless
> > you unplug the exis
On Tue, Mar 18, 2025 at 07:31:36PM +0100, Eric Auger wrote:
> On 3/17/25 9:19 PM, Nicolin Chen wrote:
> > On Mon, Mar 17, 2025 at 04:24:53PM -0300, Jason Gunthorpe wrote:
> >> On Mon, Mar 17, 2025 at 12:10:19PM -0700, Nicolin Chen wrote:
> >>> Another question: ho
On Mon, Mar 17, 2025 at 04:24:53PM -0300, Jason Gunthorpe wrote:
> On Mon, Mar 17, 2025 at 12:10:19PM -0700, Nicolin Chen wrote:
> > Another question: how does an emulated device work with a vSMMUv3?
> > I could imagine that all the accel steps would be bypassed since
> >
On Mon, Mar 17, 2025 at 07:07:52PM +0100, Eric Auger wrote:
> On 3/17/25 6:54 PM, Nicolin Chen wrote:
> > On Wed, Mar 12, 2025 at 04:15:10PM +0100, Eric Auger wrote:
> >> On 3/11/25 3:10 PM, Shameer Kolothum wrote:
> >>> Based on SMMUv3 as a parent device, add
On Mon, Mar 17, 2025 at 08:38:23AM +, Shameerali Kolothum Thodi wrote:
> Hi Nicolin,
>
> > -Original Message-
> > From: Nicolin Chen
> > Sent: Tuesday, March 11, 2025 9:08 PM
> > To: Shameerali Kolothum Thodi
> > Cc: qemu-...@nongnu.org
On Wed, Mar 12, 2025 at 04:15:10PM +0100, Eric Auger wrote:
> On 3/11/25 3:10 PM, Shameer Kolothum wrote:
> > Based on SMMUv3 as a parent device, add a user-creatable smmuv3-accel
> > device. In order to support vfio-pci dev assignment with a Guest
> guest
> > SMMUv3, the physical SMMUv3 has to be
On Tue, Mar 11, 2025 at 02:10:34PM +, Shameer Kolothum wrote:
> @@ -30,6 +32,185 @@ static SMMUv3AccelDevice *smmuv3_accel_get_dev(SMMUState
> *s, SMMUPciBus *sbus,
> return accel_dev;
> }
>
> +static bool
> +smmuv3_accel_dev_attach_viommu(SMMUv3AccelDevice *accel_dev,
> +
On Tue, Mar 11, 2025 at 02:10:33PM +, Shameer Kolothum wrote:
> diff --git a/include/hw/arm/smmuv3-accel.h b/include/hw/arm/smmuv3-accel.h
> index 56fe376bf4..86c0523063 100644
> --- a/include/hw/arm/smmuv3-accel.h
> +++ b/include/hw/arm/smmuv3-accel.h
> @@ -16,6 +16,10 @@
> #define TYPE_ARM_S
1 - 100 of 185 matches
Mail list logo
