[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.