From: Jan Beulich <jbeulich@suse.com>
To: paul@xen.org
Cc: xen-devel@lists.xenproject.org, "'Tian,
Kevin'" <kevin.tian@intel.com>,
'Andrew Cooper' <andrew.cooper3@citrix.com>
Subject: Re: [Xen-devel] [PATCH v3] IOMMU: make DMA containment of quarantined devices optional
Date: Tue, 10 Mar 2020 16:04:31 +0100 [thread overview]
Message-ID: <7f34d08e-7876-5eae-d561-c20db2fd5d99@suse.com> (raw)
In-Reply-To: <000f01d5f6d7$a89fe3b0$f9dfab10$@xen.org>
On 10.03.2020 13:30, Paul Durrant wrote:
>> -----Original Message-----
>> From: Jan Beulich <jbeulich@suse.com>
>> Sent: 10 March 2020 10:27
>> To: Tian, Kevin <kevin.tian@intel.com>; Paul Durrant <paul@xen.org>
>> Cc: xen-devel@lists.xenproject.org; Andrew Cooper <andrew.cooper3@citrix.com>
>> Subject: Re: [PATCH v3] IOMMU: make DMA containment of quarantined devices optional
>>
>> On 10.03.2020 04:43, Tian, Kevin wrote:
>>>> From: Jan Beulich <jbeulich@suse.com>
>>>> Sent: Monday, March 9, 2020 7:09 PM
>>>>
>>>> I'm happy to take better suggestions to replace the "full" command line
>>>> option and Kconfig prompt tokens. I don't think though that "fault" and
>>>> "write-fault" are really suitable there.
>>>
>>> I think we may just allow both r/w access to scratch page for such bogus
>>> device, which may make 'full' more reasonable since we now fully
>>> contain in-fly DMAs. I'm not sure about the value of keeping write-fault
>>> alone for such devices (just because one observed his specific device only
>>> has problem with read-fault).
>>
>> Well, a fundamental problem I have here is that I still don't know
>> the _exact_ conditions for the observed hangs. I consider it unlikely
>> for IOMMU read faults to cause hangs, but for write faults to be
>> "fine".
>
> AFAIK it's because the writes are posted and so any faults are just ignored, whereas a read fault being synchronous causes the device's state machine to lock up. It really is observed behaviour.
>
>> It would seem more likely to me that e.g. a non-present
>> context entry might cause issues. If that was the case, we wouldn't
>> need to handle reads and writes differently; we could instead install
>> an all zero top level page table. And we'd still get all faults that
>> are supposed to surface. But perhaps Paul did try this back then, and
>> it turned out to not be an option.
>>
>
> The only info I had was that faults on DMA reads had to avoided
> completely. I did not have access to the h/w in question at the
> time. I may be able to get it now.
I see. The implication then is, as Kevin said, that we mustn't run
guests with _any_ IOMMU PTEs having their "read" bits clear.
Anything that's "not present" now would need directing to a scratch
page. I then further wonder what effect reads to addresses beyond
AGAW would have. It may be impossible to arrange for sufficiently
secure pass-through with such a device, at which point - again as
said by Kevin - there may be little point in the scratch page
based quarantining.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2020-03-10 15:04 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-09 11:09 [Xen-devel] [PATCH v3] IOMMU: make DMA containment of quarantined devices optional Jan Beulich
2020-03-10 3:43 ` Tian, Kevin
2020-03-10 10:26 ` Jan Beulich
2020-03-10 12:30 ` Paul Durrant
2020-03-10 15:04 ` Jan Beulich [this message]
2020-03-10 15:13 ` Paul Durrant
2020-03-10 15:44 ` Jan Beulich
2020-03-10 16:05 ` Paul Durrant
2020-03-10 16:46 ` Jan Beulich
2020-03-13 3:22 ` Tian, Kevin
2020-03-13 9:26 ` Paul Durrant
2020-03-17 6:10 ` Tian, Kevin
2020-03-13 2:28 ` Tian, Kevin
2020-03-10 5:30 ` Tian, Kevin
2020-03-10 10:31 ` Jan Beulich
2020-03-13 3:05 ` Tian, Kevin
2020-03-13 8:10 ` Jan Beulich
2020-03-13 9:26 ` Paul Durrant
2020-03-17 6:20 ` Tian, Kevin
2020-03-10 8:58 ` Paul Durrant
2020-03-10 10:10 ` Jan Beulich
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=7f34d08e-7876-5eae-d561-c20db2fd5d99@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=kevin.tian@intel.com \
--cc=paul@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.