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

[Julien Grall <julien.grall@xxxxxxxxxx>]

On 23/02/15 15:39, Ian Campbell 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?

The list of things to do for resetting a device would be:
        - Deassign device from DOMU (though it's done during destruction)
        - Assign the device to DOM0 and map MMIO
        - Reset the device

But that not my concern right now. As we agreed, this feature (i.e reset
a device) is not in the scope of this series.

So assigning the device to DOM0 is not safe at all.

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

Ok.

-- 
Julien Grall

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