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.
&g
bsite 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
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+subs
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
leas
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
> > >
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
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:
>> Ma
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
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 re
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/ma
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.
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 (PU
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 publicl
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
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
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
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 tryi
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 E
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
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 lis
20 matches
Mail list logo