All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.