Re: [Xen-devel] [PATCH for-4.13] docs/xl: Document pci-assignable state

["Durrant, Paul" <pdurrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Xen-devel <xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf Of Jan
> Beulich
> Sent: 26 November 2019 14:27
> To: Ian Jackson <ian.jackson@xxxxxxxxxx>
> Cc: Juergen Gross <jgross@xxxxxxxx>; xen-devel@xxxxxxxxxxxxxxxxxxxx; Paul
> Durrant <paul.durrant@xxxxxxxxxx>; George Dunlap
> <george.dunlap@xxxxxxxxxx>; Wei Liu <wl@xxxxxxx>
> Subject: Re: [Xen-devel] [PATCH for-4.13] docs/xl: Document pci-assignable
> state
> 
> On 26.11.2019 15:14, Ian Jackson wrote:
> > George Dunlap writes ("[PATCH for-4.13] docs/xl: Document pci-assignable
> state"):
> >>  =item B<pci-assignable-remove> [I<-r>] I<BDF>
> > ...
> >> +Make the device at PCI Bus/Device/Function BDF not assignable to
> >> +guests.  This will at least unbind the device from pciback, and
> >> +re-assign it from the "quarantine domain" back to domain 0.  If the -r
> >> +option is specified, it will also attempt to re-bind the device to its
> >> +original driver, making it usable by Domain 0 again.  If the device is
> >> +not bound to pciback, it will return success.
> >> +
> >> +Note that this functionality will work even for devices which were not
> >> +made assignable by B<pci-assignable-add>.  This can be used to allow
> >> +dom0 to access devices which were automatically quarantined by Xen
> >> +after domain destruction as a result of Xen's B<iommu=quarantine>
> >> +command-line default.
> >
> > What are the security implications of doing this if the device might
> > still be doing DMA or something ?
> 
> Devices get reset in between, so well behaving ones should not
> still be doing DMA at that point. Misbehaving ones would better
> not be assigned (back and forth) anyway. But a recent patch of
> Paul's suggests that people still wish to do so, on the
> assumption that such DMA will drain sufficiently quickly.

Yes. I will hopefully find time to post the next version of that patch this 
week.

  Paul

> 
> > (For that matter, presumably there are security implications of
> > assigning the same device in sequence to different guests?)
> 
> Right.
> 
> Jan
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxxx
> https://lists.xenproject.org/mailman/listinfo/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel