[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Hi Ian,

On 20/02/15 15:38, Ian Campbell wrote:
> On Tue, 2015-01-13 at 14:25 +0000, Julien Grall wrote:
>> When a device is marked for passthrough (via the new property 
>> "xen,passthrough"),
>> dom0 must not access to the device (i.e not loading a driver), but should
> "must not access the device (i.e. not load a driver)"
> perhaps "should still be able"
>> be able to manage the MMIO/interrupt of the passthrough device.
>> The latter part will allow the toolstack to map MMIO/IRQ when a device
>> is pass through to a guest.
>> The property "xen,passthrough" will be translated as 'status="disabled"'
>> in the device tree to avoid DOM0 using the device. We assume that DOM0 is
>> able to cope with this property (already the case for Linux).
> Is it true to say "already the case for Linux, and required by ePAPR"?
> Or are we relying on a Linux implementation detail here?

The ePAPR says:

"Indicates that the device is not presently operational, but it might
become operational in the future (for example, something is not plugged
in, or switched off).
Refer to the device binding for details on what disabled means for a
given device."

So I think we can say "required by ePAPR".

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

We may want to be less strict if we decide to let DOM0 cope with
platform device passthrough (as it's done for PCI).

But this is more complicate than the current use case for this type of


Julien Grall

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.