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

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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.

Ian.

> 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
> passthrough.
> 
> Regards,
> 



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