Re: [Xen-devel] [PATCH v3 18/24] xen/passthrough: iommu_deassign_device_dt: By default reassign device to nobody

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Mon, 2015-02-23 at 10:20 +0000, Jan Beulich wrote:
> >>> On 23.02.15 at 11:10, <julien.grall@xxxxxxxxxx> wrote:
> > Hi Jan,
> > 
> > On 23/02/2015 09:40, Jan Beulich wrote:
> >>>>> On 20.02.15 at 18:04, <ian.campbell@xxxxxxxxxx> 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? If so then it is worth calling that
> >>> out explicitly (even if not, good to know I think!)
> >> Indeed this is different from x86, and I think such behavior should
> >> be consistent across architectures. If Dom0 isn't handed back the
> >> device, who's going to do the supposedly prerequisite reset? On
> >> x86/PCI that's pciback's job, and it would be illegitimate for the
> >> driver to do _anything_ with the device if it wasn't owned by Dom0.
> > 
> > I think we already had this discussion on a previous version...
> > 
> > Right now, there is no possibility to reset a platform device in the 
> > kernel. There is some discussion about it but nothing more.

"there is no possibility to reset a platform device" isn't quite true,
there is certainly a theoretical possibility (i.e. it is obviously the
case that a dom0 could be written to do so for at least some devices).

So what happens if such a dom0 arises in the future? I suppose the
intention is that the user would having deassigned from domU and
determined that there kernel has the necessary feature would do some
sort of xl command to assign to dom0?

> > This series doesn't intend to have a generic solution for platform 
> > device pass-through. It's target embedded people who will always 
> > passthrough the same device to the same guest.
> > 
> > As DOM0 *should not* use the device (no reset driver, and no possibility 
> > to unbind), the safest way is to reassign the device to nobody.
> > 
> > So if the device is not quiescent it may mess up DOM0.
> 
> And I think spelling this out in the description is what Ian is
> asking for.

Yes.

I think it probably ought to be mentioned in the docs surrounding the
hypercalls in question, for both PCI, DT and any other device type
whether or not there is some implicit rebinding or not.

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel