Re: New IOMMU mailing list coming
On Tue, Jun 14, 2022 at 10:30:21AM +0200, Jörg Rödel wrote: > Hi all, > > after several problems with the current IOMMU mailing list (no DKIM > support, poor b4 interoperability) we have decided to move the IOMMU > development discussions to a new list hosted at lists.linux.dev. > > The new list is up and running already, to subscribe please send an > email to iommu+subscr...@lists.linux.dev. It is not yet archived, but > there will be a hard switch between the old and the new list on > > July 5th, 2022 > > After that date the old list will no longer work and the archive will > switch to the new mailing list. > > Sorry for any inconveniences this might cause. Gentle reminder that the old IOMMU mailing list at iommu@lists.linux-foundation.org will no longer be archived from Tuesday, July 5th on and will disappear soon after. If not already done, please subscribe to the new mailing list at iomm+subscr...@lists.linux.dev Thanks and see you over there! Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[CFP LPC 2022] VFIO/IOMMU/PCI Microconference
Hello everyone!
We are pleased to announce that there will be another
VFIO/IOMMU/PCI Microconference
at this year's Linux Plumbers Conference (LPC), from 12th to the 14th of
September in Dublin, Ireland. LPC is a hybrid event this year;
attendance can be in person or remote.
In this microconference we want to discuss ongoing developments around
the VFIO, IOMMU and PCI subsystems and their interactions in Linux.
Tentative topics that are under consideration for this year include (but
not limited to):
* PCI:
- Cache Coherent Interconnect for Accelerators (CCIX)/Compute
Express Link (CXL) expansion memory and accelerators
management
- Data Object Exchange (DOE)
- Integrity and Data Encryption (IDE)
- Component Measurement and Authentication (CMA)
- Security Protocol and Data Model (SPDM)
- I/O Address Space ID Allocator (IOASID)
- INTX/MSI IRQ domain consolidation
- Gen-Z interconnect fabric
- ARM64 architecture and hardware
- PCI native host controllers/endpoints drivers current
challenges and improvements (e.g., state of PCI quirks, etc.)
- PCI error handling and management e.g., Advanced Error
Reporting (AER), Downstream Port Containment (DPC), ACPI
Platform Error Interface (APEI) and Error Disconnect Recover
(EDR)
- Power management and devices supporting Active-state Power
Management (ASPM)
- Peer-to-Peer DMA (P2PDMA)
- Resources claiming/assignment consolidation
- Probing of native PCIe controllers and general reset
implementation
- Prefetchable vs non-prefetchable BAR address mappings
- Untrusted/external devices management
- DMA ownership models
- Thunderbolt, DMA, RDMA and USB4 security
* VFIO:
- Write-combine on non-x86 architectures
- I/O Page Fault (IOPF) for passthrough devices
- Shared Virtual Addressing (SVA) interface
- Single-root I/O Virtualization(SRIOV)/Process Address Space
ID (PASID) integration
- PASID in SRIOV virtual functions
- Device assignment/sub-assignment
* IOMMU:
- /dev/iommufd development
- IOMMU virtualization
- IOMMU drivers SVA interface
- DMA-API layer interactions and the move towards generic
dma-ops for IOMMU drivers
- Possible IOMMU core changes (e.g., better integration with
device-driver core, etc.)
Please submit your proposals on the LPC website at:
https://lpc.events/event/16/abstracts/
Make sure to select the "VFIO/IOMMU/PCI MC" in the Track pulldown
menu.
Looking forward to seeing you all there, either in Dublin or virtual! :)
The organizers,
Alex Williamson
Bjorn Helgaas
Jörg Rödel
Lorenzo Pieralisi
Krzysztof Wilczyński
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
New IOMMU mailing list coming
Hi all, after several problems with the current IOMMU mailing list (no DKIM support, poor b4 interoperability) we have decided to move the IOMMU development discussions to a new list hosted at lists.linux.dev. The new list is up and running already, to subscribe please send an email to iommu+subscr...@lists.linux.dev. It is not yet archived, but there will be a hard switch between the old and the new list on July 5th, 2022 After that date the old list will no longer work and the archive will switch to the new mailing list. Sorry for any inconveniences this might cause. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Personal email outage
Hi, last week I had an outage of the mail server which handles my 8bytes.org emails, and I probably lost some of the incoming stuff that was sent to me. The machine has been repaired now and I can receive emails again on that account, but it is likely that I still lost a couple of emails (at least I have seen several replies to emails I didn't get). I plan to go through all IOMMU patches tomorrow, if I havn't replied to your patches by Friday, please just re-send them to me. Sorry for the inconveniences and delays! Thanks, Joerg signature.asc Description: Digital signature ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: nvme: IO_PAGE_FAULT logged with Intel SSDPEKKF512G8
On Tue, Jan 18, 2022 at 06:01:06PM +0100, Paul Menzel wrote: > > > $ dmesg --level=err > > > [4.194306] nvme :01:00.0: AMD-Vi: Event logged > > > [IO_PAGE_FAULT domain=0x000c address=0xc080 flags=0x0050] > > > [4.206970] nvme :01:00.0: AMD-Vi: Event logged > > > [IO_PAGE_FAULT domain=0x000c address=0xc000 flags=0x0050] This was caused by a DMA read to a write-only page. Looks like a bug in the driver or the devices firmware. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 01/11] iommu: Add device dma ownership set/release interfaces
On Fri, Nov 19, 2021 at 07:14:10PM +0800, Lu Baolu wrote: > The singleton group requirement for iommu_attach/detach_device() was > added by below commit: > > commit 426a273834eae65abcfc7132a21a85b3151e0bce > Author: Joerg Roedel > Date: Thu May 28 18:41:30 2015 +0200 > > iommu: Limit iommu_attach/detach_device to devices with their own group > > This patch changes the behavior of the iommu_attach_device > and iommu_detach_device functions. With this change these > functions only work on devices that have their own group. > For all other devices the iommu_group_attach/detach > functions must be used. > > Signed-off-by: Joerg Roedel > > Joerg,can you please shed some light on the background of this > requirement? Does above idea of transition from singleton group > to group with single driver bound make sense to you? This change came to be because the iommu_attach/detach_device() interface doesn't fit well into a world with iommu-groups. Devices within a group are by definition not isolated between each other, so they must all be in the same address space (== iommu_domain). So it doesn't make sense to allow attaching a single device within a group to a different iommu_domain. I know that in theory it is safe to allow devices within a group to be in different domains because there iommu-groups catch multiple non-isolation cases: 1) Devices behind a non-ACS capable bridge or multiple functions of a PCI device. Here it is safe to put the devices into different iommu-domains as long as all affected devices are controlled by the same owner. 2) Devices which share a single request-id and can't be differentiated by the IOMMU hardware. These always need to be in the same iommu_domain. To lift the single-domain-per-group requirement the iommu core code needs to learn the difference between the two cases above. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: AMD-Vi: [Firmware Warn]: EFR mismatch. Use IVHD EFR (0xf77ef22294ada : 0x400f77ef22294ada).
Possible, but still DELL is the first point of contact here. If they find out that the problem is actually in Agesa, then DELL can escalate this to AMD. > Am 15.09.2021 um 10:42 schrieb Paul Menzel : > > Dear Jörg, > > > Am 15.09.21 um 10:30 schrieb Jörg Rödel: >> Mainly DELL should look at this, because it is their BIOS which is >> responsible for this inconsistency. > > I am not so sure about that, as today’s (x86) firmware often consists of > platform initialization (PI) code (or firmware support package (FSP), > provided by the chipset/SoC vendors, like AGESA for AMD, which the ODM just > integrate. > > If only Dell systems are affected, that would of course point to a bug in the > Dell firmware. > > > Kind regards, > > Paul ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: AMD-Vi: [Firmware Warn]: EFR mismatch. Use IVHD EFR (0xf77ef22294ada : 0x400f77ef22294ada).
Mainly DELL should look at this, because it is their BIOS which is responsible for this inconsistency. > Am 15.09.2021 um 00:17 schrieb Paul Menzel : > > [Use Mario’s current address] > > Am 15.09.21 um 00:15 schrieb Paul Menzel: >> [Cc: +Mario from AMD] >> Dear Jörg, >> Am 14.09.21 um 14:09 schrieb Jörg Rödel: >>> On Tue, Sep 14, 2021 at 11:10:57AM +0200, Paul Menzel wrote: >>>> Linux 5.15-rc1 still warns about that (also with latest system firmware >>>> 1.1.50). >>> >>> The reason is most likely that the latest firmware still reports a >>> different EFR feature set in the IVRS table than the IOMMU reports in >>> its EFR MMIO register. >> What do you mean exactly? Only 0x400 is prepended. The rest of the string is >> identical. What feature set would the 0x400 in the beginning be? >> Anyway, it’d be great if AMD and Dell could take a look. >> Kind regards, >> Paul ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: AMD-Vi: [Firmware Warn]: EFR mismatch. Use IVHD EFR (0xf77ef22294ada : 0x400f77ef22294ada).
On Tue, Sep 14, 2021 at 11:10:57AM +0200, Paul Menzel wrote: > Linux 5.15-rc1 still warns about that (also with latest system firmware > 1.1.50). The reason is most likely that the latest firmware still reports a different EFR feature set in the IVRS table than the IOMMU reports in its EFR MMIO register. Regards, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/amd: Put newline after closing bracket in warning
On Mon, Apr 12, 2021 at 08:01:41PM +0200, Paul Menzel wrote: > drivers/iommu/amd/init.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] iommu/amd: Print extended features in one line to fix divergent log levels
On Wed, Jun 17, 2020 at 12:04:20AM +0200, Paul Menzel wrote: > drivers/iommu/amd_iommu_init.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Applied, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: MSI B350M MORTAR: `AMD-Vi: Unable to write to IOMMU perf counter.` and `pci 0000:00:00.2: can't derive routing for PCI INT A`
On Fri, Jul 27, 2018 at 11:18:56AM +0200, Paul Menzel wrote: > On the AMD site [1] I see the three family 0x17 documents below. > > 1. Open-Source Register Reference for AMD Family 17h Processors (PUB) > 2. Processor Programming Reference (PPR) for AMD Family 17h Models 00h-0Fh > Processors (PUB) > 3. Software Optimization Guide for AMD Family 17h Processors (PUB) > > What documented is required? The BKDG? IIRC the PPR is the new BKDG, but the public version does not seem to contain any references about how the IOMMU needs to be set up by firmware. Thanks, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: MSI B350M MORTAR: `AMD-Vi: Unable to write to IOMMU perf counter.` and `pci 0000:00:00.2: can't derive routing for PCI INT A`
Hi Paul, On Mon, Jul 23, 2018 at 12:09:37PM +0200, Paul Menzel wrote: > > or the BIOS did not enable the performance counter feature in the IOMMU > > hardware. > > Is it possible to check that from the OS side? It would be if we had the NB documentation, but I guess those details are not publicly available. > > Are you running on the latest BIOS? > > Yes, I am even using a “beta“ one from [1]. > > DMI: MSI MS-7A37/B350M MORTAR (MS-7A37), BIOS 1.G1 05/17/2018 I think the best you can do is to report this as a bug to your BIOS vendor and hope they'll fix it. Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: AMD-Vi: Decrease time of enabling lazy IO/TLB flushing
On Tue, Jul 17, 2018 at 06:07:07PM +0200, Paul Menzel wrote: > On a MSI B350M MORTAR with AMD Ryzen 3 2200g (Raven) with Linux 4.18-rc5+ > and Debian Sid/unstable `pci_iommu_init` takes 40 ms according to > `initcall_debug`. 40ms is a lot indeed, but IOMMU initialization is also a complex process which includes scanning ACPI tables, allocating memory, flushing hardware caches (which probably accounts for a fair amount of the time needed). Would be good if someone can come up with patches to improve the situation here, as I don't know when I will find the time to look into that. Thanks, Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: MSI B350M MORTAR: `AMD-Vi: Unable to write to IOMMU perf counter.` and `pci 0000:00:00.2: can't derive routing for PCI INT A`
Hi Paul, On Tue, Jul 17, 2018 at 06:02:07PM +0200, Paul Menzel wrote: > $ dmesg > […] > [0.145696] calling pci_iommu_init+0x0/0x3f @ 1 > [0.145719] AMD-Vi: Unable to write to IOMMU perf counter. This is likely a firmware issue. Either the IVRS ACPI table is incorrect or the BIOS did not enable the performance counter feature in the IOMMU hardware. Are you running on the latest BIOS? Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] Intel-IOMMU: Delete an error message for a failed memory allocation in init_dmars()
On Sat, Jan 20, 2018 at 05:37:52PM -0800, Joe Perches wrote: > While Markus' commit messages are nearly universally terrible, > is there really any signficant value in knowing when any > particular OOM condition occurs other than the subsystem that > became OOM? > > You're going to be hosed in any case. > > Why isn't the generic OOM stack dump good enough? Because if we know the exact allocation attempt that failed right away, we can more easily check if we can rewrite it so that it is more likely to succeed, e.g. rewriting one higher-order allocation to multiple order-0 allocations. Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] Intel-IOMMU: Delete an error message for a failed memory allocation in init_dmars()
On Sat, Jan 20, 2018 at 03:55:37PM +0100, SF Markus Elfring wrote: > Do you need any more background information for this general > transformation pattern? No. > Do you find the Linux allocation failure report insufficient for this > use case? Yes, because it can't tell me what the code was trying to allocate. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH] Intel-IOMMU: Delete an error message for a failed memory allocation in init_dmars()
On Sat, Jan 20, 2018 at 02:00:13PM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 20 Jan 2018 13:51:49 +0100 > > Omit an extra message for a memory allocation failure in this function. > > This issue was detected by using the Coccinelle software. > > Signed-off-by: Markus Elfring NACK on this one and the other two IOMMU patches you sent. The messages give the user/developer useful information about what the memory that failed to allocate would have been used for. Joerg ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/2] iommu/tegra: Add support for struct iommu_device
Yes, I was running some tests against the new tree which didn't finish yesterday. Today I am traveling, but will be back im the evening and then I push the tree out. Regards, Joerg Sent from a Galaxy Class Phone Ursprüngliche Nachricht Von: Jon Hunter Datum: 31.08.17 12:23 (GMT+01:00) An: Joerg Roedel Cc: Thierry Reding , Robin Murphy , iommu@lists.linux-foundation.org, linux-te...@vger.kernel.org, linux-ker...@vger.kernel.org, Joerg Roedel Betreff: Re: [PATCH 1/2] iommu/tegra: Add support for struct iommu_device Hi Joerg, On 30/08/17 16:30, Joerg Roedel wrote: > Hi Jon, > > On Wed, Aug 30, 2017 at 03:22:05PM +0100, Jon Hunter wrote: >> Yes I can confirm that this fixes the crash. I assume that you will fix >> the error path for bus_set_iommu() above as I believe now it needs to >> call iommu_device_sysfs_remove(). > > Thanks for testing the patch. I updated the error-path and put the > commit below into the iommu-tree: Today's -next is still failing and I don't see this fix in your public tree yet [0]. Can you push this out? Cheers Jon [0] https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git/ -- nvpublic ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH 1/1] IOMMU-MSM: Deletion of unnecessary checks before the function call "clk_disable"
On Wed, Oct 22, 2014 at 08:00:17PM +0200, SF Markus Elfring wrote: > drivers/iommu/msm_iommu.c | 3 +-- > drivers/iommu/msm_iommu_dev.c | 6 ++ > 2 files changed, 3 insertions(+), 6 deletions(-) Applied to arm/msm, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
