Re: [Xen-devel] [PATCH v3 07/24] xen/arm: Introduce xen, passthrough property

[Julien Grall <julien.grall@xxxxxxxxxx>]

Hi Ian,

On 23/02/15 15:12, Ian Campbell wrote:
> On Fri, 2015-02-20 at 17:01 +0000, Julien Grall wrote:
>>>> diff --git a/docs/misc/arm/device-tree/passthrough.txt 
>>>> b/docs/misc/arm/device-tree/passthrough.txt
>>>> new file mode 100644
>>>> index 0000000..04645b3
>>>> --- /dev/null
>>>> +++ b/docs/misc/arm/device-tree/passthrough.txt
>>>> @@ -0,0 +1,7 @@
>>>> +Device passthrough
>>>> +===================
>>>> +
>>>> +Any device that will be passthrough to a guest should have a property
>>>> +"xen,passthrough" in their device tree node.
>>>> +
>>>> +The device won't be exposed to DOM0 and therefore no driver will be 
>>>> loaded.
>>>
>>> This (and the commit message to some extent) seem stricter than what I
>>> think is actually required here.
>>>
>>> I understand that it is a very good idea for any sort of passthrough to
>>> prevent dom0 from messing with a device before it gets assigned to the
>>> eventual guest domain.
>>>
>>> But AIUI it is not strictly speaking a hard requirement that dom0 does
>>> not do this and depending on the device it may be perfectly acceptable
>>> for dom0 to drive a device for a bit and then give it to a guest and
>>> then have it back again etc.
>>
>> When the device has the property "xen,passthrough", Xen won't map the
>> MMIO and IRQ to DOM0. So it's an hard requirement.
> 
> That's not what I meant.
> 
> What I was getting at is that it's not 100% mandatory for a device you
> want to pass through to have the "xen,passthrough" property at all, but
> the wording of the binding implies otherwise..
> 
> There will be at least some devices in the world (even if only trivial
> ones) where you can pass them through even if dom0 has been touching
> them before. Or dom0 might choose to implement a reset helper for some
> device or other.

Hmmm right... I will update the binding.

Regards,

-- 
Julien Grall

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