[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 18/24] xen/passthrough: iommu_deassign_device_dt: By default reassign device to nobody
On Tue, 2015-03-10 at 15:29 +0000, Julien Grall wrote: > Hi, > > On 23/02/15 15:34, Ian Campbell wrote: > > On Mon, 2015-02-23 at 10:10 +0000, Julien Grall wrote: > >> > >> On 20/02/2015 17:04, Ian Campbell wrote: > >>> On Tue, 2015-01-13 at 14:25 +0000, Julien Grall wrote: > >>>> Currently, when the device is deassigned from a domain, we directly > >>>> reassign > >>>> to DOM0. > >>>> > >>>> As the device may not have been correctly reset, this may lead to > >>>> corruption or > >>>> expose some part of DOM0 memory. Also, we may have no way to reset some > >>>> platform devices. > >>>> > >>>> If Xen reassigns the device to "nobody", it may receive some > >>>> global/context > >>>> fault because the transaction has failed (indeed the context has been > >>>> marked invalid). Unfortunately there is no simple way to quiesce a buggy > >>>> hardware. I think we could live with that for a first version of platform > >>>> device passthrough. > >>>> > >>>> DOM0 will have to issue an hypercall to assign the device to itself if it > >>>> wants to use it. > >>> > >>> Does this behaviour differ from x86? > > > > I realise now that x86 is a red-herring, what I really meant was differ > > from other types of device (specifically PCI ones). > > > >> If so then it is worth calling that > >>> out explicitly (even if not, good to know I think!) > >> > >> What do you mean by "calling that out explicitly"? > > > > Stating in the commit log or a suitably placed comment (at least under > > xen/include/public hopefully) that deassignment of dt devices behaves > > differently to deassignment of other types of devices. > > I tried to search any documentation explaining the behavior of those > DOMCTL for PCI (mostly the deassign one) but I didn't find any. > > By any chance, do you know if there is one? If so where? If you didn't find it in the obvious places under xen/include/public then it probably doesn't exist. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |