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 16:24 +0000, Jan Beulich wrote:
> >>> On 23.02.15 at 16:39, <ian.campbell@xxxxxxxxxx> wrote:
> > 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?
> 
> I suppose this was really targeted at Julien...

Right, sorry that wasn't very clear of me.

> 
> Jan
> 
> >> > 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