From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Elliott Mitchell <ehem+xen@m5p.com>
Cc: Jan Beulich <jbeulich@suse.com>,
xen-devel@lists.xenproject.org,
Andrew Cooper <andrew.cooper3@citrix.com>, Wei Liu <wl@xen.org>,
Kelly Choi <kelly.choi@cloud.com>
Subject: Re: Serious AMD-Vi(?) issue
Date: Mon, 13 May 2024 10:44:59 +0200 [thread overview]
Message-ID: <ZkHTC4RpUSpKj4wf@macbook> (raw)
In-Reply-To: <Zj7vkp4r0EY9rxT4@mattapan.m5p.com>
On Fri, May 10, 2024 at 09:09:54PM -0700, Elliott Mitchell wrote:
> On Thu, Apr 18, 2024 at 09:33:31PM -0700, Elliott Mitchell wrote:
> >
> > I suspect this is a case of there is some step which is missing from
> > Xen's IOMMU handling. Perhaps something which Linux does during an early
> > DMA setup stage, but the current Xen implementation does lazily?
> > Alternatively some flag setting or missing step?
> >
> > I should be able to do another test approach in a few weeks, but I would
> > love if something could be found sooner.
>
> Turned out to be disturbingly easy to get the first entry when it
> happened. Didn't even need `dbench`, it simply showed once the OS was
> fully loaded. I did get some additional data points.
>
> Appears this requires an AMD IOMMUv2. A test system with known
> functioning AMD IOMMUv1 didn't display the issue at all.
>
> (XEN) AMD-Vi: IO_PAGE_FAULT: DDDD:bb:dd.f d0 addr fffffffdf8000000 flags 0x8 I
I would expect the address field to contain more information about the
fault, but I'm not finding any information on the AMD-Vi specification
apart from that it contains the DVA, which makes no sense when the
fault is caused by an interrupt.
> (XEN) DDDD:bb:dd.f root @ 83b5f5 (3 levels) dfn=fffffffdf8000
> (XEN) L3[1f7] = 0 np
Attempting to print the page table walk for an Interrupt remapping
fault is useless, we should likely avoid that when the I flag is set.
>
> I find it surprising this required "iommu=debug" to get this level of
> detail. This amount of output seems more appropriate for "verbose".
"verbose" should also print this information.
>
> I strongly prefer to provide snippets. There is a fair bit of output,
> I'm unsure which portion is most pertinent.
I've already voiced my concern that I think what yo uare doing is not
fair. We are debugging this out of interest, and hence you refusing
to provide all information just hampers our ability to debug, and
makes us spend more time than required just thinking what snippets we
need to ask for.
I will ask again, what's there in the Xen or the Linux dmesgs that you
are so worried about leaking? Please provide an specific example.
Why do you mask the device SBDF in the above snippet? I would really
like to understand what's so privacy relevant in a PCI SBDF number.
Does booting with `iommu=no-intremap` lead to any issues being
reported?
Regards, Roger.
next prev parent reply other threads:[~2024-05-13 8:45 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-25 20:24 Serious AMD-Vi issue Elliott Mitchell
2024-02-12 23:23 ` Elliott Mitchell
2024-03-04 19:56 ` Elliott Mitchell
2024-03-18 19:41 ` Serious AMD-Vi(?) issue Elliott Mitchell
2024-03-22 16:41 ` Kelly Choi
2024-03-22 19:22 ` Elliott Mitchell
2024-03-25 7:55 ` Jan Beulich
2024-03-25 21:43 ` Elliott Mitchell
2024-03-27 17:27 ` Elliott Mitchell
2024-03-28 6:25 ` Jan Beulich
2024-03-28 15:22 ` Elliott Mitchell
2024-03-28 16:17 ` Elliott Mitchell
2024-04-11 2:41 ` Elliott Mitchell
2024-04-17 12:40 ` Jan Beulich
2024-04-18 6:45 ` Elliott Mitchell
2024-04-18 7:09 ` Jan Beulich
2024-04-19 4:33 ` Elliott Mitchell
2024-05-11 4:09 ` Elliott Mitchell
2024-05-13 8:44 ` Roger Pau Monné [this message]
2024-05-13 20:11 ` Elliott Mitchell
2024-05-14 8:22 ` Jan Beulich
2024-05-14 20:51 ` Elliott Mitchell
2024-05-15 13:40 ` Kelly Choi
2024-05-16 5:21 ` Elliott Mitchell
2024-05-14 8:20 ` Jan Beulich
2024-06-28 0:18 ` Elliott Mitchell
2024-07-01 18:07 ` Elliott Mitchell
2024-07-04 22:08 ` Elliott Mitchell
2024-07-10 18:35 ` Elliott Mitchell
2024-03-04 23:55 ` AMD-Vi issue Andrew Cooper
2024-03-05 0:34 ` Elliott Mitchell
2025-01-24 14:31 ` Serious " Roger Pau Monné
2025-01-24 21:26 ` Elliott Mitchell
2025-01-26 0:24 ` Teddy Astie
2025-01-27 9:44 ` Roger Pau Monné
2025-02-18 4:05 ` Elliott Mitchell
2025-04-13 22:08 ` Elliott Mitchell
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZkHTC4RpUSpKj4wf@macbook \
--to=roger.pau@citrix.com \
--cc=andrew.cooper3@citrix.com \
--cc=ehem+xen@m5p.com \
--cc=jbeulich@suse.com \
--cc=kelly.choi@cloud.com \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.