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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2014-09-10 at 11:45 -0700, Julien Grall wrote:
> Hi Ian,
> 
> On 10/09/14 03:11, Ian Campbell wrote:
> >>> 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?
> 
> The current code is actually numbering from IRQ32 onwards.

In the hypervisor though, I thought? I meant do it in the toolstack,
which is where you can more easily handle overrides like user requests
for specific virq:pirq mappings (as a future extension).

IOW the *hypercall* interface now should take both a pirq and a virq and
map on to the other, but there is no need right now (unless you want to)
to plumb that all the way out to (lib)xl.

>  I was mostly 
> thinking of the Andrii use case. Shall we handle it for Xen 4.5?

I think it's a nice to have if we can do it in time, but I wouldn't want
to risk the rest of the series missing the boat because of it.

Ian.


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