On Tue, Aug 01, 2023 at 08:28:01AM +, Duan, Zhenzhong wrote:
> Ping, any comments or suggestions are appreciated.
Zhenzhong, I'd love to, yet haven't got the chance to go through
this series. I think that most of us are quite occupied at this
moment by the kernel side of the changes.
I plan
Hi Mostafa,
On Mon, Mar 25, 2024 at 10:13:56AM +, Mostafa Saleh wrote:
>
> Currently, QEMU supports emulating either stage-1 or stage-2 SMMUs
> but not nested instances.
> This patch series adds support for nested translation in SMMUv3,
> this is controlled by property “arm-smmuv3.stage=neste
Hi Peter,
Eric previously mentioned that you might not like the idea.
Before we start this big effort, would it possible for you
to comment a word or two on this topic?
Thanks!
On Mon, Apr 24, 2023 at 04:42:57PM -0700, Nicolin Chen wrote:
> Hi all,
>
> (Please feel free to includ
Hi all,
(Please feel free to include related folks into this thread.)
In light of an ongoing nested-IOMMU support effort via IOMMUFD, we
would likely have a need of a multi-vIOMMU support in QEMU, or more
specificly a multi-vSMMU support for an underlying HW that has multi
physical SMMUs. This wo
Hi Eric,
On Thu, May 18, 2023 at 11:06:50AM +0200, Eric Auger wrote:
> > On Mon, Apr 24, 2023 at 04:42:57PM -0700, Nicolin Chen wrote:
> >> Hi all,
> >>
> >> (Please feel free to include related folks into this thread.)
> >>
> >> In light of an
Hi Eric,
On Tue, Jan 31, 2023 at 09:53:01PM +0100, Eric Auger wrote:
> diff --git a/include/sysemu/iommufd.h b/include/sysemu/iommufd.h
> new file mode 100644
> index 00..06a866d1bd
> --- /dev/null
> +++ b/include/sysemu/iommufd.h
> @@ -0,0 +1,47 @@
> +#ifndef SYSEMU_IOMMUFD_H
> +#define
that. Set the default PCI bus
to bypass iommu, for the maximum performance.
Signed-off-by: Nicolin Chen
---
hw/arm/virt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 3610f53304..5e91dc8c3d 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
Each pxb bus created for a nested SMMU has a reserved bus number, allowing
a hotplug device to attach to the bus in a later stage.
Read it out to apply to the id_count calculation.
Signed-off-by: Nicolin Chen
---
hw/arm/virt-acpi-build.c | 28
include/hw/arm/virt.h
IDR0.
Signed-off-by: Nicolin Chen
---
hw/arm/virt-acpi-build.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
index 6d8b9aea42..c4cf1caf22 100644
--- a/hw/arm/virt-acpi-build.c
+++ b/hw/arm/virt-acpi-build.c
@@ -485,7 +4
and, an emulated deivce should not be associated
to a nested SMMU.
To prepare for that, create a PCIe Expander Bridge per nested SMMU as a
docker for pci-vfio devices. It eases the QEMU code to build ID mappings
in the IORT.
Signed-off-by: Nicolin C
A nested SMMU must use iommufd ioctls to communicate with the host-level
SMMU instance for 2-stage translation support. Add an iommufd link to the
ARM virt-machine, allowing QEMU command to pass in an iommufd object.
Signed-off-by: Nicolin Chen
---
hw/arm/virt.c | 14
A following patch will add a new MMIO region for nested SMMU instances.
This macro will be repeatedly used to set offsets and MMIO sizes in both
virt and virt-acpi-build.
Signed-off-by: Nicolin Chen
---
hw/arm/virt.c | 2 +-
include/hw/arm/virt.h | 3 +++
2 files changed, 4 insertions
ady finished a reset
cycle will need to sync the idr/idrr bits and will have to reset
again?
This series is on Github:
https://github.com/nicolinc/qemu/commits/iommufd_multi_vsmmu-rfcv1
Thanks!
Nicolin
Eric Auger (1):
hw/arm/virt-acpi-build: Add IORT RMR regions to handle MSI nested
b
SMMUv3 instance.
Signed-off-by: Nicolin Chen
---
hw/arm/virt.c | 35 +++
include/hw/arm/virt.h | 8
2 files changed, 43 insertions(+)
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 71093d7c60..be3d8b0ce6 100644
--- a/hw/arm/virt.c
+++ b/hw/arm
m/virt-acpi-build: Add IORT support to bypass
SMMUv3")
Signed-off-by: Nicolin Chen
---
hw/arm/virt-acpi-build.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
index c3ccfef026..b9343dde0f 100644
--- a/hw/arm/virt-acp
On Mon, Jun 17, 2024 at 06:41:55AM -0400, Michael S. Tsirkin wrote:
> On Thu, Jun 13, 2024 at 04:48:02PM -0700, Nicolin Chen wrote:
> > The IORT doc defines "Number of IDs" ("id_count" in the virt-acpi-build)
> > to be "the number of IDs in the range minus o
m/virt-acpi-build: Add IORT support to bypass
SMMUv3")
Signed-off-by: Nicolin Chen
---
Changelog
v2:
* Moved "-1" to the same line of id_count calculation
* Added "+1" to the next_range.input_base calculation
v1:
https://lore.kernel.org/all/20240613234802.828265-1-nicol...@n
On Tue, Jun 18, 2024 at 05:49:58AM -0400, Michael S. Tsirkin wrote:
> On Mon, Jun 17, 2024 at 03:39:45PM -0700, Nicolin Chen wrote:
> > The IORT doc defines "Number of IDs" ("id_count" in the virt-acpi-build)
> > to be "the number of IDs in the range minus o
On Tue, Jun 18, 2024 at 03:38:31PM -0400, Michael S. Tsirkin wrote:
> > > > -next_range.input_base = idmap->input_base +
> > > > idmap->id_count;
> > > > +next_range.input_base = idmap->input_base +
> > > > idmap->id_count + 1;
> > > > }
> > > >
> > >
> > > Given
On Tue, Jun 18, 2024 at 04:03:34PM -0400, Michael S. Tsirkin wrote:
> On Mon, Jun 17, 2024 at 03:39:45PM -0700, Nicolin Chen wrote:
> > -next_range.input_base = idmap->input_base + idmap->id_count;
> > +next_range.input_base = idmap->input_base +
ss
SMMUv3")
Suggested-by: Michael S. Tsirkin
Signed-off-by: Nicolin Chen
---
Changelog
v3:
* Added "-1" internally in build_iort_id_mapping() instead
* Added comments to highlight this and referencing doc
v2:
https://lore.kernel.org/all/20240617223945.906996-1-nicol...@nvidia.com/
On Tue, Jun 18, 2024 at 05:14:32PM -0400, Michael S. Tsirkin wrote:
> > @@ -306,8 +314,8 @@ build_iort(GArray *table_data, BIOSLinker *linker,
> > VirtMachineState *vms)
> > }
> >
> > /* Append the last RC -> ITS ID mapping */
> > -if (next_range.input_base < 0x) {
>
On Tue, Jun 18, 2024 at 05:34:21PM -0400, Michael S. Tsirkin wrote:
> On Tue, Jun 18, 2024 at 02:19:25PM -0700, Nicolin Chen wrote:
> > On Tue, Jun 18, 2024 at 05:14:32PM -0400, Michael S. Tsirkin wrote:
> > > > @@ -306,8 +314,8 @@ build_iort(GArray *table_dat
ly.
Signed-off-by: Nicolin Chen
---
hw/arm/virt-acpi-build.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/hw/arm/virt-acpi-build.c b/hw/arm/virt-acpi-build.c
index ee6f56b410..05af407bbd 100644
--- a/hw/arm/virt-acpi-build.c
+++ b/hw/arm/virt-acpi-build.c
@@ -277,7 +277,6
The caller of smmu_iommu_mr wants to get sdev for smmuv3_flush_config().
Do it directly instead of bridging with an iommu mr pointer.
Signed-off-by: Nicolin Chen
---
hw/arm/smmu-common.c | 8 ++--
hw/arm/smmuv3.c | 12
include/hw/arm/smmu-common.h | 4
On Wed, Jun 19, 2024 at 04:15:35PM +0200, Eric Auger wrote:
> > @@ -209,12 +209,20 @@ static void acpi_dsdt_add_tpm(Aml *scope,
> > VirtMachineState *vms)
> > #define ROOT_COMPLEX_ENTRY_SIZE 36
> > #define IORT_NODE_OFFSET 48
> >
> > +/*
> > + * Input Output Remapping Table (IORT) -- Table 4 ID
SMMUv3")
Suggested-by: Michael S. Tsirkin
Reviewed-by: Eric Auger
Signed-off-by: Nicolin Chen
---
Changelog
v4:
* Rephrased the function documentation and used the latest IORT spec ver.
* Added "Reviewed-by" from Eric
v3:
https://lore.kernel.org/all/2024061820.922809-1-nicol
Hi all,
Hope I didn't miss anybody who is related to the topic. Please,
feel free to add!
<--- Background --->
As some of you know, there is an ongoing effort for nested-smmuv3
support in QEMU on ARM, working with the kernel IOMMUFD uAPIs:
[Nesting for vSTE]
https://lore.kernel.org/linux-iommu/0-
Hi Shameer,
Thanks for the reply!
On Thu, Sep 05, 2024 at 12:55:52PM +, Shameerali Kolothum Thodi wrote:
> > The main takeaway from the discussion is to
> > 1) Turn the vSMMU module into a pluggable one, like intel-iommu
> > 2) Move the per-SMMU pxb bus and device auto-assign into libvirt
> >
Hi Mostafa,
On Fri, Sep 06, 2024 at 11:50:38AM +, Mostafa Saleh wrote:
> > <-- Help Needed --->
> > So, I'm wondering if anyone(s) might have some extra bandwidth in
> > the following months helping these two tasks, either of which can
> > be a standalone project I think.
>
> I don’t have pl
Hi,
Thanks for the work!
On Thu, Apr 14, 2022 at 03:46:52AM -0700, Yi Liu wrote:
> - More tests
I did a quick test on my ARM64 platform, using "iommu=smmuv3"
string. The behaviors are different between using default and
using legacy "iommufd=off".
The legacy pathway exits the VM with:
vfi
lback routine and add a line of comments to highlight it.
Fixes: 87ea529c50 ("vfio: Get migration capability flags for container")
Cc: Kirti Wankhede
Signed-off-by: Nicolin Chen
---
hw/vfio/common.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/hw/vfio/common.c b
On Mon, Sep 12, 2022 at 02:38:52PM +0200, Cornelia Huck wrote:
> External email: Use caution opening links or attachments
>
>
> On Fri, Sep 09 2022, Nicolin Chen wrote:
>
> > Its caller vfio_connect_container() assigns a default value
> > to info->iova_pgsize
Hi Alex,
On Wed, Sep 14, 2022 at 12:10:29PM -0600, Alex Williamson wrote:
> > > > Its caller vfio_connect_container() assigns a default value
> > > > to info->iova_pgsizes, even if vfio_get_iommu_info() fails.
> > > > This would result in a "Segmentation fault" error, when the
> > > > VFIO_IOMMU_
On Wed, Sep 14, 2022 at 02:03:25PM -0600, Alex Williamson wrote:
> > > > +container->pgsizes = 4096;
> > >
> > > This might be a separate question/issue: I wonder if we should use
> > > "sysconf(_SC_PAGE_SIZE)" here instead of 4096.
> > >
> > > With a kernel using a larger page size, e.g.
-4KB systems.
>
> Reported-by: Nicolin Chen
> Link: https://lore.kernel.org/all/20220910004245.2878-1-nicol...@nvidia.com/
> Signed-off-by: Alex Williamson
Reviewed-by: Nicolin Chen
Tested-by: Nicolin Chen
Thanks!
On Sun, Apr 17, 2022 at 12:30:40PM +0200, Eric Auger wrote:
> >> - More tests
> > I did a quick test on my ARM64 platform, using "iommu=smmuv3"
> > string. The behaviors are different between using default and
> > using legacy "iommufd=off".
> >
> > The legacy pathway exits the VM with:
> > vf
On Wed, Jul 12, 2023 at 03:25:26PM +0800, Zhenzhong Duan wrote:
> +#ifdef CONFIG_IOMMUFD
> +static VFIODevice *vfio_pci_iommufd_binded(__u32 devid)
> +{
> +VFIOAddressSpace *space;
> +VFIOContainer *bcontainer;
> +VFIOIOMMUFDContainer *container;
> +VFIOIOASHwpt *hwpt;
> +VFIO
On Wed, Jul 12, 2023 at 03:25:25PM +0800, Zhenzhong Duan wrote:
> The way to get vfio device pointer is different between legacy
> container and iommufd container, with iommufd backend support
> added, it's time to add the iterator support for iommufd.
>
> In order to implement it, a pointer to h
e)
I'll do more tests with vSVA cases in the next days, yet FWIW:
Tested-by: Nicolin Chen
On Thu, Nov 09, 2023 at 07:45:12PM +0800, Zhenzhong Duan wrote:
> +static int iommufd_cdev_attach_ioas_hwpt(VFIODevice *vbasedev, bool is_ioas,
> + uint32_t id, Error **errp)
> +{
> +int ret, iommufd = vbasedev->iommufd->fd;
> +struct vfio_device_att
Hi Eric,
Thanks for the comments!
On Tue, Jul 09, 2024 at 11:11:56AM +0200, Eric Auger wrote:
> On 6/26/24 02:28, Nicolin Chen wrote:
> > A nested SMMU must use iommufd ioctls to communicate with the host-level
> > SMMU instance for 2-stage translation support. Add an iommufd link
On Tue, Jul 09, 2024 at 11:20:16AM +0200, Eric Auger wrote:
> On 6/26/24 02:28, Nicolin Chen wrote:
> > Nested SMMUv3 feature requires the support/presence of host-level SMMUv3
> > instance(s). Add a helper to read the sysfs for the number of instances.
> > Log them in a
On Tue, Jul 09, 2024 at 07:06:50PM +0200, Eric Auger wrote:
> On 7/9/24 18:59, Nicolin Chen wrote:
> > Hi Eric,
> >
> > Thanks for the comments!
> >
> > On Tue, Jul 09, 2024 at 11:11:56AM +0200, Eric Auger wrote:
> >> On 6/26/24 02:28, Nicolin Chen w
On Tue, Jul 09, 2024 at 03:26:58PM +0200, Eric Auger wrote:
> > @@ -1580,12 +1647,33 @@ static void create_pcie(VirtMachineState *vms)
> > qemu_fdt_setprop_cell(ms->fdt, nodename, "#interrupt-cells", 1);
> > create_pcie_irq_map(ms, vms->gic_phandle, irq, nodename);
> >
> > -if (vms->
On Tue, Jul 09, 2024 at 07:22:16PM +0200, Eric Auger wrote:
> On 7/9/24 19:11, Nicolin Chen wrote:
> > On Tue, Jul 09, 2024 at 11:20:16AM +0200, Eric Auger wrote:
> >> On 6/26/24 02:28, Nicolin Chen wrote:
> >>> Nested SMMUv3 feature requires the support
(Resending as my previous mail didn't go through mailing lists)
Hello Eric, Yubo, and other QEMU developers,
I am having a problem with links between vSMMU and PCI Host Bridge,
using ARM-VIRT (64-bit; ACPI) + SMMUv3 (nested translation) setup.
Firstly, I am very new to the areas of QEMU, PCI and
Hello Eric, Yubo, and other QEMU developers,
I am having a problem with links between vSMMU and PCI Host Bridge,
using ARM-VIRT (64-bit; ACPI) + SMMUv3 (nested translation) setup.
Firstly, I am very new to the areas of QEMU, PCI and ACPI. So some
of my thoughts/ideas below might not sound very re
Hi Eric,
Thanks for the reply!
On Mon, Jun 07, 2021 at 11:19:39AM +0200, Eric Auger wrote:
> > So I started to have questions in my mind:
> > (1) Can PCI host bridge (PCIE.128) add to a different vSMMU without
> > following PCIE.0's SMMU setup?
> changes need to be made in hw/arm/virt.c
> cr
On Fri, Nov 01, 2024 at 06:35:23PM +, Shameerali Kolothum Thodi wrote:
> > @Shameer,
> > Do you have some update on the pluggable smmuv3 module?
>
> I have a bare minimum prototype code that works with a pluggable smmuv3.
>
> ...
> -device pxb-pcie,id=pcie.1,bus_nr=2,bus=pcie.0 \
> -device pc
On Fri, Nov 08, 2024 at 12:52:37PM +, Shameer Kolothum wrote:
> Few ToDos to note,
> 1. At present default-bus-bypass-iommu=on should be set when
>arm-smmuv3-nested dev is specified. Otherwise you may get an IORT
>related boot error. Requires fixing.
> 2. Hot adding a device is not wor
On Fri, Nov 08, 2024 at 12:52:42PM +, Shameer Kolothum wrote:
> From: Eric Auger
>
> To handle SMMUv3 nested stage support it is practical to
> expose the guest with reserved memory regions (RMRs)
> covering the IOVAs used by the host kernel to map
> physical MSI doorbells.
There has been an
Hi Eric,
On Wed, Nov 13, 2024 at 06:12:15PM +0100, Eric Auger wrote:
> On 11/8/24 13:52, Shameer Kolothum wrote:
> > @@ -181,6 +181,7 @@ static const MemMapEntry base_memmap[] = {
> > [VIRT_PVTIME] = { 0x090a, 0x0001 },
> > [VIRT_SECURE_GPIO] ={ 0x090b, 0x
Hi,
This is a continued discussion following previous month's:
https://lore.kernel.org/qemu-devel/Zvr%2Fbf7KgLN1cjOl@Asurada-Nvidia/
Kernel changes are getting closer to merge, as Jason's planning to
take vIOMMU series and smmuv3_nesting series into the iommufd tree:
https://lore.kernel.org/all/c
On Mon, Sep 30, 2024 at 10:45:31AM +, Shameerali Kolothum Thodi wrote:
> > -Original Message-
> > From: Nicolin Chen
> > Sent: Thursday, September 5, 2024 9:37 PM
> > To: Shameerali Kolothum Thodi
> > Cc: Eric Auger ; Mostafa Saleh
> >
Hi Eric,
On Thu, Nov 07, 2024 at 12:11:05PM +0100, Eric Auger wrote:
> On 11/1/24 05:09, Nicolin Chen wrote:
> > Hi,
> >
> > This is a continued discussion following previous month's:
> > https://lore.kernel.org/qemu-devel/Zvr%2Fbf7KgLN1cjOl@Asurada-Nvidia/
&g
On Wed, Nov 27, 2024 at 11:29:06PM -0500, Donald Dutile wrote:
> On 11/27/24 5:21 AM, Shameerali Kolothum Thodi wrote:
> > > > W.r.t naming, maybe something related to "hardware-accelerated"?
> > > >
> > > Given that 'accel' has been used for hw-acceleration elsewhere, that seems
> > > like a reas
On Thu, Nov 28, 2024 at 08:54:26AM -0400, Jason Gunthorpe wrote:
> On Wed, Nov 27, 2024 at 08:44:47PM -0800, Nicolin Chen wrote:
> > On Wed, Nov 27, 2024 at 11:29:06PM -0500, Donald Dutile wrote:
> > > On 11/27/24 5:21 AM, Shameerali Kolothum Thodi wrote:
> > > > >
On Mon, Nov 18, 2024 at 06:59:53PM +0100, Eric Auger wrote:
> Looking at your branch I see the following series (marked with cover-letter)
..
> cover-letter: Add RMR WAR for MSI mappings (based on former RMR flat
> mapping and not related to *[PATCH RFCv1 0/7] vfio: Allow userspace
> to
On Thu, Nov 14, 2024 at 08:20:08AM +, Shameerali Kolothum Thodi wrote:
> > > diff --git a/include/hw/arm/virt.h b/include/hw/arm/virt.h index
> > > 46f48fe561..50e47a4ef3 100644
> > > --- a/include/hw/arm/virt.h
> > > +++ b/include/hw/arm/virt.h
> > > @@ -50,6 +50,9 @@
> > > /* MMIO region siz
On Fri, Nov 08, 2024 at 12:52:37PM +, Shameer Kolothum wrote:
> This RFC is for initial discussion/test purposes only and includes patches
> that are only relevant for adding the "arm-smmuv3-nested" support. For the
> complete branch please find,
> https://github.com/hisilicon/qemu/commits/priv
On Thu, Nov 14, 2024 at 11:41:58AM +0100, Eric Auger wrote:
> Hi Shameer,
>
> On 11/14/24 09:48, Shameerali Kolothum Thodi wrote:
> >
> >> -Original Message-
> >> From: Nicolin Chen
> >> Sent: Wednesday, November 13, 2024 6:31 PM
> &g
On Fri, Jan 31, 2025 at 05:54:56PM +0100, Eric Auger wrote:
> On 1/9/25 5:45 AM, Nicolin Chen wrote:
> > On Mon, Dec 16, 2024 at 10:01:29AM +, Shameerali Kolothum Thodi wrote:
> >> And patches prior to this commit adds that support:
> >> 4ccdbe3: ("cover-le
On Tue, Feb 04, 2025 at 06:49:15PM +0100, Eric Auger wrote:
> > In summary, we will have the following series:
> > 1) HWPT uAPI patches in backends/iommufd.c (Zhenzhong or Shameer)
> >
> > https://lore.kernel.org/qemu-devel/sj0pr11mb6744943702eb5798ec9b3b9992...@sj0pr11mb6744.namprd11.prod.outl
On Thu, Feb 06, 2025 at 10:34:15AM +, Shameerali Kolothum Thodi wrote:
> > -Original Message-
> > From: Nicolin Chen
> > On Tue, Feb 04, 2025 at 06:49:15PM +0100, Eric Auger wrote:
> > > However in
> > >
> > > Shameer suggested he may
On Thu, Feb 06, 2025 at 04:38:55PM -0400, Jason Gunthorpe wrote:
> On Thu, Feb 06, 2025 at 12:33:19PM -0800, Nicolin Chen wrote:
> > On Thu, Feb 06, 2025 at 02:22:01PM -0400, Jason Gunthorpe wrote:
> > > On Thu, Feb 06, 2025 at 06:18:14PM +, Shameerali Kolothum Thodi wrote:
&
On Thu, Feb 06, 2025 at 02:22:01PM -0400, Jason Gunthorpe wrote:
> On Thu, Feb 06, 2025 at 06:18:14PM +, Shameerali Kolothum Thodi wrote:
>
> > > So even if you invent an iommu ID we cannot accept it as a handle to
> > > create viommu in iommufd.
> >
> > Creating the vIOMMU only happens when
On Thu, Feb 06, 2025 at 05:11:13PM -0400, Jason Gunthorpe wrote:
> On Thu, Feb 06, 2025 at 12:48:40PM -0800, Nicolin Chen wrote:
> > On Thu, Feb 06, 2025 at 04:38:55PM -0400, Jason Gunthorpe wrote:
> > > On Thu, Feb 06, 2025 at 12:33:19PM -0800, Nicolin Chen wrote:
> > >
On Wed, Dec 11, 2024 at 09:11:12AM -0400, Jason Gunthorpe wrote:
> On Tue, Dec 10, 2024 at 05:28:17PM -0800, Nicolin Chen wrote:
> > > I would ideally turn it around and provide that range information to
> > > the kernel and totally ignore the SW_MSI reserved region once
>
On Thu, Nov 21, 2024 at 09:46:16AM +, Shameerali Kolothum Thodi wrote:
> Hi Eric,
>
> > -Original Message-
> > From: Shameerali Kolothum Thodi
> > Sent: Wednesday, November 20, 2024 4:26 PM
> > To: 'eric.au...@redhat.com' ; qemu-
> > a...@nongnu.org; qemu-devel@nongnu.org
> > Cc: peter
Hi Eric/Don/Shameer,
On Fri, Nov 08, 2024 at 12:52:42PM +, Shameer Kolothum wrote:
> Those IOVAs belong to [0x800, 0x810] matching
> MSI_IOVA_BASE and MSI_IOVA_LENGTH definitions in kernel
> arm-smmu-v3 driver. This is the window used to allocate
> IOVAs matching physical MSI doorbells
On Tue, Dec 10, 2024 at 08:48:21PM -0400, Jason Gunthorpe wrote:
> On Tue, Dec 10, 2024 at 03:01:48PM -0800, Nicolin Chen wrote:
>
> > Yet, here we seem to be missing a pathway between VMM and kernel
> > to agree on the MSI window decided by the kernel, as this patch
> >
On Wed, Dec 11, 2024 at 03:21:37PM +, Shameerali Kolothum Thodi wrote:
> > Once a device reaches to the pci_device_set_iommu_device() call,
> > it should be attached to an IDENTIY/bypass proxy s1_hwpt, so the
> > smmu_find_add_as() will return the iommu as.
>
> Agree. The above situation you e
On Mon, Dec 16, 2024 at 10:01:29AM +, Shameerali Kolothum Thodi wrote:
> And patches prior to this commit adds that support:
> 4ccdbe3: ("cover-letter: Add HW accelerated nesting support for arm
> SMMUv3")
>
> Nicolin is soon going to send out those for review. Or I can include
> those in thi
On Thu, Jan 23, 2025 at 08:28:34AM +, Shameerali Kolothum Thodi wrote:
> > -Original Message-
> > From: Nicolin Chen
> > I wonder if we can make some progress in Feb? If so, we can start
> > to wrap up the iommufd uAPI patches for HWPT, which was a part of
>
Hi Don,
On Fri, Jan 10, 2025 at 11:05:24PM -0500, Donald Dutile wrote:
> On 1/8/25 11:45 PM, Nicolin Chen wrote:
> > On Mon, Dec 16, 2024 at 10:01:29AM +, Shameerali Kolothum Thodi wrote:
> > > And patches prior to this commit adds that support:
> > > 4ccd
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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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, 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: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:07AM +0100, Shameer Kolothum wrote:
> Signed-off-by: Shameer Kolothum
Though I think the commit log shouldn't be empty,
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 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
Ditto.
Otherwise,
Reviewed-by: Nicolin Chen
1 - 100 of 186 matches
Mail list logo
