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

["Jan Beulich" <JBeulich@xxxxxxxx>]

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

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