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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2014-09-11 at 12:11 -0700, Julien Grall wrote:
> 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.

I guess I don't mind if we do 1:1 or autoincrementing for 4.5.

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

That's probably because on x86 PV there is no virq, only evtchns. We
should be following the HVM style though.

> 
> Regards,
> 



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