Re: [Xen-devel] [PATCH v2 00/21] xen/arm: Add support for non-pci passthrough

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2014-09-09 at 12:34 -0700, Julien Grall wrote:
> (Adding Christoffer)
> 
> Hi Ian,
> 
> On 09/09/14 07:34, Ian Campbell wrote:
> > On Thu, 2014-07-31 at 16:00 +0100, Julien Grall wrote:
> >>      - Only common device properties (interrupts, regs) are written to
> >>      the guest device tree. Device that needs other properties may not 
> >> work.
> >
> > So I've glanced through the later (more toolstack oriented) bits from
> > towards the end but I think there's a question of the target users which
> > needs thinking about before I can have a sensible opinion on those.
> >
> > As I see it the main purpose of this series is to get the underlying
> > plumbing in place (wiring up iommus, routing IRQs etc) to support guests
> > with passthrough devices, for embedded folks to use and to provide a
> > basis for eventual PCI passthrough functionality. I really want to see
> > this stuff in 4.5
> >
> > What I'm concerned about is the toolstack side. TBH I'm not very keen on
> > the thing with exposing very DT specific stuff like compatible strings
> > down from the hypervisor via domctls.
> > It's not really clear how best to expose this functionality, I have a
> > feeling that this series either goes too far or not far enough and ends
> > up not really satisfying anyone.
> 
> I don't see many other solutions to get the compatible strings. There is 
> no easy way to get the property from DOM0, unless we introduce a new 
> driver in Linux.

Right, they would have to come from the user (in my proposal via the DT
blob injection).

> > My suspicion is that regular folks won't really be using passthrough
> > until it is via PCI and that in the meantime this functionality is only
> > going to be used by e.g. people building embedded system and superkeen
> > early adopters both of whom know what they are doing and can tolerate
> > some hacks etc to get things working (and I think that's fine, it's
> > still a worthwhile set of things to get into 4.5 and those folks are
> > worth supporting).
> >
> > I'm also worried that we may be committing ourselves to a libxl API
> > already without really working through all the issues (e.g. other
> > properties).
> >
> > Given that I wonder if we wouldn't be better off for 4.5 supporting
> > something much simpler at the toolstack level, namely allowing users to
> > use iomem= and irq= in their domain config to map platform devices
> > through (already works with your series today?)
> 
> This would need a bit a plumbing for irq part to allow the user choosing 
> the VIRQ (like Arianna did for MMIO range).

Is it required, or can we just number them from IRQ32 onwards?

Adding the ability to specify would be a nice to have, but not essential
right now IMHO, although if it falls out nicely from the changes you are
already planning to make then great.

> 
>  > and perhaps a back door
> > to allow the injection a blob of DT into the guest's DT to describe
> > them. i.e. enough to actually get stuff done but not pretending to be
> > too finely integrated.
> 
> I would be fine with this solution for Xen 4.5. I will give a look to 
> see what could be done.
> 
> > Then we can revisit the "proper" toolstack side for 4.6. Otherwise I
> > fear that by the time we get the toolstack side sorted out to our
> > satisfaction the basic functionality (which seems to be largely done)
> > will have missed 4.5.
> 
> Depending of the use cases, your solution based on "iomem", "irq" and DT 
> blob might be enough for device platform passthrough.

I hope so.


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