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

[Julien Grall <julien.grall@linaro.org>]

Hi Jan,

On 23/02/2015 09:40, Jan Beulich wrote:
>>>> On 20.02.15 at 18:04, <ian.campbell@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.

Regards,

-- 
Julien Grall