On 6/17/25 12:52 PM, Jonathan Cameron wrote:
On Tue, 17 Jun 2025 09:49:54 +0200
Eric Auger wrote:
On 6/16/25 12:20 PM, Jonathan Cameron wrote:
On Fri, 13 Jun 2025 15:44:43 +0100
Shameer Kolothum wrote:
Although this change does not affect functionality at present, it is
Patch title s
On 6/16/25 7:12 AM, Jonathan Cameron wrote:
On Fri, 13 Jun 2025 15:44:49 +0100
Shameer Kolothum wrote:
Now that arm,virt can have user-creatable smmuv3 devices, document it.
Signed-off-by: Shameer Kolothum
---
qemu-options.hx | 6 ++
1 file changed, 6 insertions(+)
diff --git a/qe
On 6/5/25 1:58 PM, Nathan Chen wrote:
On 6/4/2025 7:34 PM, Donald Dutile wrote:
On 6/4/25 10:02 PM, Nathan Chen wrote:
On 6/2/2025 8:41 AM, Shameer Kolothum wrote:
This patch series introduces support for a user-creatable SMMUv3 device
(-device arm-smmuv3) in QEMU.
Tested-by: Nathan
On 6/4/25 10:02 PM, Nathan Chen wrote:
On 6/2/2025 8:41 AM, Shameer Kolothum wrote:
This patch series introduces support for a user-creatable SMMUv3 device
(-device arm-smmuv3) in QEMU.
Tested-by: Nathan Chen
I am able to create 16 SMMUv3 devices in a qemu VM with emulated devices
proper
(!vms->default_bus_bypass_iommu) {
+qemu_fdt_setprop_cells(ms->fdt, nodename, "iommu-map",
+ 0x0, vms->iommu_phandle, 0x0, 0x1);
+}
break;
default:
g_assert_not_reached();
Reviewed-by: Donald Dutile
On 5/20/25 5:13 AM, Duan, Zhenzhong wrote:
-Original Message-
From: Donald Dutile
Subject: Re: [PATCH rfcv2 00/20] intel_iommu: Enable stage-1 translation for
passthrough device
Hey Zhenzhong,
Thanks for feedback. replies below.
- Don
On 5/19/25 4:37 AM, Duan, Zhenzhong wrote
Hey Zhenzhong,
Thanks for feedback. replies below.
- Don
On 5/19/25 4:37 AM, Duan, Zhenzhong wrote:
Hi Donald,
-Original Message-
From: Donald Dutile
Subject: Re: [PATCH rfcv2 00/20] intel_iommu: Enable stage-1 translation for
passthrough device
Zhenzhong,
Hi!
Eric asked me to
On 5/8/25 9:57 AM, Peter Maydell wrote:
On Thu, 8 May 2025 at 14:46, Donald Dutile wrote:
I would refer to the ARM SMMU spec, Figure 2.3 in the G.a version, where
it's slightly different; more like:
+--+
| PCIe Devices | (one device, unless a PCIe switch is
On 5/7/25 4:50 AM, Shameerali Kolothum Thodi wrote:
-Original Message-
From: Markus Armbruster
Sent: Wednesday, May 7, 2025 8:17 AM
To: Donald Dutile
Cc: Shameer Kolothum via ; qemu-
a...@nongnu.org; Shameerali Kolothum Thodi
; eric.au...@redhat.com;
peter.mayd...@linaro.org; j
On 5/6/25 7:47 AM, Markus Armbruster wrote:
Shameer Kolothum via writes:
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
---
hw/arm/smmuv3.c | 26
}
static void create_virtio_iommu_dt_bindings(VirtMachineState *vms)
Reviewed-by: Donald Dutile
On 5/2/25 1:13 PM, Nicolin Chen wrote:
On Fri, May 02, 2025 at 11:27:03AM +0100, Shameer Kolothum wrote:
@@ -43,6 +43,7 @@
#include "hw/acpi/generic_event_device.h"
#include "hw/acpi/tpm.h"
#include "hw/acpi/hmat.h"
+#include "hw/arm/smmuv3.h"
#include "hw/pci/pcie_host.h"
#include
On 5/2/25 6:27 AM, 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
---
hw/arm/smmuv3.c | 26 ++
hw/arm/virt.c
On 5/2/25 6:27 AM, Shameer Kolothum wrote:
Hi All,
Changes from v1:
https://lore.kernel.org/qemu-devel/20250415081104.71708-1-shameerali.kolothum.th...@huawei.com/
Addressed feedback on v1. Thanks to all.
1. Retained the same name as the legacy SMMUv3(arm-smmuv3) for new
device type as w
On 4/22/25 4:57 AM, Shameerali Kolothum Thodi wrote:
-Original Message-
From: Donald Dutile
Sent: Friday, April 18, 2025 9:34 PM
To: Shameerali Kolothum Thodi
; qemu-...@nongnu.org;
qemu-devel@nongnu.org
Cc: eric.au...@redhat.com; peter.mayd...@linaro.org; j...@nvidia.com;
nicol
() call after attach_device() call in
vfio_device_attach(). Drop vfio_device_hiod_realize() which looks redundant now. Suggested-by:
Cédric Le Goater Suggested-by: Donald Dutile
Signed-off-by: Zhenzhong Duan
Reviewed-by: Donald Dutile
On 4/16/25 1:38 AM, Shameerali Kolothum Thodi wrote:
-Original Message-
From: Nicolin Chen
Sent: Wednesday, April 16, 2025 5:19 AM
To: Shameerali Kolothum Thodi
Cc: qemu-...@nongnu.org; qemu-devel@nongnu.org;
eric.au...@redhat.com; peter.mayd...@linaro.org; j...@nvidia.com;
ddut..
Shameer,
Hi!
First off, like the partitioning of these pieces.
On 4/15/25 4:10 AM, Shameer Kolothum wrote:
Hi All,
This patch series introduces support for a user-creatable SMMUv3 device
(-device arm-smmuv3-dev) in QEMU.
Can we drop the '-dev', as 'arm-smmu' is sufficient, as is '-device'?
Zhenzhong,
Hi!
Eric asked me to review this series.
Since it's rather late since you posted will summarize review feedback
below/bottom.
- Don
On 2/19/25 3:22 AM, Zhenzhong Duan wrote:
Hi,
Per Jason Wang's suggestion, iommufd nesting series[1] is split into
"Enable stage-1 translation for em
On 3/19/25 1:00 PM, Eric Auger wrote:
Hi,
On 3/19/25 1:23 AM, Jason Gunthorpe wrote:
On Tue, Mar 18, 2025 at 05:22:51PM -0400, Donald Dutile wrote:
I agree with Eric that 'accel' isn't needed -- this should be
ascertained from the pSMMU that a physical device is attached
On 3/24/25 10:56 AM, Eric Auger wrote:
On 3/21/25 1:59 AM, Donald Dutile wrote:
On 3/19/25 2:21 PM, Eric Auger wrote:
Hi Don,
On 3/19/25 5:21 PM, Donald Dutile wrote:
On 3/19/25 5:26 AM, Shameerali Kolothum Thodi wrote:
Hi Don,
Hey!
-Original Message-
From: Donald
On 3/19/25 2:09 PM, Eric Auger wrote:
Hi Nicolin,
On 3/19/25 6:14 PM, Nicolin Chen wrote:
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 wro
On 3/19/25 2:21 PM, Eric Auger wrote:
Hi Don,
On 3/19/25 5:21 PM, Donald Dutile wrote:
On 3/19/25 5:26 AM, Shameerali Kolothum Thodi wrote:
Hi Don,
Hey!
-Original Message-
From: Donald Dutile
Sent: Tuesday, March 18, 2025 10:12 PM
To: Shameerali Kolothum Thodi
; qemu
On 3/19/25 1:04 PM, Eric Auger wrote:
On 3/18/25 10:22 PM, Donald Dutile wrote:
On 3/18/25 3:13 PM, Nicolin Chen wrote:
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 3/19/25 5:48 AM, Shameerali Kolothum Thodi wrote:
-Original Message-
From: Donald Dutile
Sent: Wednesday, March 19, 2025 1:31 AM
To: Shameerali Kolothum Thodi
; qemu-...@nongnu.org;
qemu-devel@nongnu.org
Cc: eric.au...@redhat.com; peter.mayd...@linaro.org; j...@nvidia.com
On 3/19/25 5:26 AM, Shameerali Kolothum Thodi wrote:
Hi Don,
Hey!
-Original Message-
From: Donald Dutile
Sent: Tuesday, March 18, 2025 10:12 PM
To: Shameerali Kolothum Thodi
; qemu-...@nongnu.org;
qemu-devel@nongnu.org
Cc: eric.au...@redhat.com; peter.mayd...@linaro.org; j
On 3/11/25 10:10 AM, 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 too, v.s.
the emulated iotlb. In this case, an iommu notifier isn't registered,
as the devices behind
Shameer,
Hey,
On 3/11/25 10:10 AM, Shameer Kolothum wrote:
From: Nicolin Chen
Read the underlying SMMUv3 device info and set corresponding IDR
bits. We need at least one cold-plugged vfio-pci dev associated
with the smmuv3-accel instance to do this now. Hence fail if it
is not available.
T
Jason,
Hey!
On 3/18/25 8:23 PM, Jason Gunthorpe wrote:
On Tue, Mar 18, 2025 at 05:22:51PM -0400, Donald Dutile wrote:
I agree with Eric that 'accel' isn't needed -- this should be
ascertained from the pSMMU that a physical device is attached to.
I seem to remember the point w
Shameer,
Hi,
On 3/11/25 10:10 AM, Shameer Kolothum wrote:
From: Nicolin Chen
Inroduce an SMMUCommandBatch and some helpers to batch and issue the
Introduce
commands. Currently separate out TLBI commands and device cache commands
to avoid some errata on certain versions of SMMUs
Shameer,
Hi,
On 3/11/25 10:10 AM, Shameer Kolothum wrote:
From: Nicolin Chen
Allocate and associate a vDEVICE object for the Guest device
with the vIOMMU. This will help the kernel to do the
vSID --> sid translation whenever required (eg: device specific
invalidations).
Signed-off-by: Nicoli
Doesn't this commit become moot, if accel becomes an smmuv3 option vs separate
device object altogether,
dynamically added if a pdev is attached to a host SMMUv3 that has accel
feature(s)?
Blocking w/virtio-iommu falls under the same situation mentioned in 03/20 wrt
mixing emulated & physica
Shameer,
Hi!
On 3/11/25 10:10 AM, Shameer Kolothum wrote:
User must associate a pxb-pcie root bus to smmuv3-accel
and that is set as the primary-bus for the smmu dev.
Signed-off-by: Shameer Kolothum
---
hw/arm/smmuv3-accel.c | 19 +++
1 file changed, 19 insertions(+)
diff
On 3/17/25 3:24 PM, 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
!sdev->idev. Yet, the emulated iotlb should cache its tr
On 3/18/25 3:13 PM, Nicolin Chen wrote:
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: how d
On 3/4/25 9:56 PM, Suthikulpanit, Suravee wrote:
On 3/5/2025 6:02 AM, Donald Dutile wrote:
Hi Suravee!
Not your issue, but wondering if others know:
Why isn't this an issue for Intel-vtd-iommu & ARM-SMMUV3 ?
Are they instantiated as non-PCI-id (platform) devices, but AMD p
Hi Suravee!
Not your issue, but wondering if others know:
Why isn't this an issue for Intel-vtd-iommu & ARM-SMMUV3 ?
Are they instantiated as non-PCI-id (platform) devices, but AMD puts their
IOMMU in PCI space?
Adv. thanks for the info.
- Don
On 3/4/25 1:37 PM, Suravee Suthikulpanit wrote:
Nicolin,
Hi!
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:
4ccdbe3: ("cover-letter: Add HW accelerated nesting support for arm
SMMUv3")
Nicolin is soon going to send out th
On 12/13/24 8:19 AM, Daniel P. Berrangé wrote:
On Fri, Dec 13, 2024 at 08:46:42AM -0400, Jason Gunthorpe wrote:
On Fri, Dec 13, 2024 at 12:00:43PM +, Daniel P. Berrangé wrote:
On Fri, Nov 08, 2024 at 12:52:37PM +, Shameer Kolothum via wrote:
Hi,
This series adds initial support for
On 11/28/24 7:54 AM, 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:
W.r.t naming, maybe something related to "hardware-accele
On 11/27/24 5:21 AM, Shameerali Kolothum Thodi wrote:
-Original Message-
From: Donald Dutile
Sent: Tuesday, November 26, 2024 6:29 PM
To: Nicolin Chen ; Eric Auger
Cc: Shameerali Kolothum Thodi
; qemu-...@nongnu.org;
qemu-devel@nongnu.org; peter.mayd...@linaro.org; j
On 11/27/24 11:00 AM, Jason Gunthorpe wrote:
On Wed, Nov 27, 2024 at 10:21:24AM +, Shameerali Kolothum Thodi wrote:
For SMMUv3, NVIDIA-specific vCMDQ, it needs a parameter to state that
specifically,
since I'm concluding from reading the SMMUv3 version G.a spec, that
ECMDQ was added
to be
On 11/13/24 1:05 PM, Nicolin Chen wrote:
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_SE
On 11/7/24 3:31 PM, Nicolin Chen wrote:
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/
Kernel ch
ot;);
if (vms->dtb_randomness) {
+1 to Peter's suggested comment, otherwise, unless privy to this thread,
one would wonder how/why.
Reviewed-by: Donald Dutile
Need to check that guest slot/device number is not > 31 or walk off
the devfn table when checking if a devfn is available or not in a guest.
before this fix, passing in an addr=abc or addr=34,
can crash qemu, sometimes fail gracefully if data past end
of devfn table fails the availability test.
46 matches
Mail list logo
