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

[Julien Grall <julien.grall@xxxxxxxxxx>]

Hi Ian,

On 11/09/14 01:58, Ian Campbell wrote:
> 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.
I though more about the possibility for Xen 4.5. We could keep VIRQ == 
PIRQ when the user specificy the list of interrupts via "irqs=". And 
then revisit the solution for Xen 4.6.
The new DOMCTL to configure the number of SPIS will be still there to 
avoid allocation on domain that doesn't require anything.
On the overall, this solution will require less code from the toolstack 
point of view. This would mean that PHYSDEVOP_map_pirq on ARM will 
always require an index and the pirq.
AFAIU, on x86 it's possible to specify the pirq only when this hypercall 
is called from an HVM.
Regards,

--
Julien Grall

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