> From: Paul Durrant <xadimg...@gmail.com>
> Sent: Wednesday, March 11, 2020 12:05 AM
>
[...]
>
> >
> > > However, is a really saying that things will break if any of the
> > > PTEs has their present bit clear?
> >
> > Well, you said that read faults are fatal (to the host). Reads will,
> > for any address with an unpopulated PTE, result in a fault and hence
> > by implication be fatal.
>
> Oh I see. I thought there was an implication that the IOMMU could not cope
> with non-present PTEs in some way. Agreed that, when the device is assigned
> to the guest, then it can arrange (via ballooning) for a non-present entry to
> be hit by a read transaction, resulting in a lock-up. But dealing with a
> malicious guest was not the issue at hand... dealing with a buggy device that
> still tried to DMA after reset and whilst in quarantine was the problem.
>
More thinking on this, I wonder whether the scratch page is sufficient, or
whether we should support such device in the first place. Looking at
0c35d446:
--
The reason for doing this is that some hardware may continue to re-try
DMA (despite FLR) in the event of an error, or even BME being cleared, and
will fail to deal with DMA read faults gracefully. Having a scratch page
mapped will allow pending DMA reads to complete and thus such buggy
hardware will eventually be quiesced.
--
'eventually'... what does it exactly mean? How would an user know a
device has been quiesced before he attempts to re-assign the device
to other domU or dom0? by guess? Note the exact behavior of such
device, after different guest behaviors (hang, kill, bug, etc.), is not
documented. Who knows whether a in-fly DMA may be triggered when
the new owner starts to initialize the device again? How many stale
states are remaining on such device which, even not triggerring in-fly
DMAs, may change the desired behavior of the new owner? e.g. it's
possible one control register configured by the old owner, but not
touched by the new owner. If it cannot be reset, what's the point of
supporting assignment of such bogus device?
Thereby I feel any support of such bogus device should be maintained
offtree, instead of in upstream Xen. Thoughts?
Thanks
Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
