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 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.
> 
> 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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel