>>> On 23.02.15 at 11:10, <julien.gr...@linaro.org> wrote: > Hi Jan, > > On 23/02/2015 09:40, Jan Beulich wrote: >>>>> On 20.02.15 at 18:04, <ian.campb...@citrix.com> 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. > > 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. Jan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
