From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH v2 00/21] xen/arm: Add support for non-pci passthrough Date: Thu, 11 Sep 2014 12:11:44 -0700 Message-ID: <5411F3F0.8010809@linaro.org> References: <1406818852-31856-1-git-send-email-julien.grall@linaro.org> <1410273261.8217.212.camel@kazak.uk.xensource.com> <540F563D.5080202@linaro.org> <1410343891.8217.291.camel@kazak.uk.xensource.com> <54109C2E.3050608@linaro.org> <1410425924.6166.35.camel@kazak.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XS9mZ-00028R-6K for xen-devel@lists.xenproject.org; Thu, 11 Sep 2014 19:11:51 +0000 Received: by mail-qc0-f178.google.com with SMTP id x13so21592825qcv.23 for ; Thu, 11 Sep 2014 12:11:48 -0700 (PDT) In-Reply-To: <1410425924.6166.35.camel@kazak.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Campbell Cc: xen-devel@lists.xenproject.org, tim@xen.org, Christoffer Dall , stefano.stabellini@citrix.com, Andrii Tseglytskyi List-Id: xen-devel@lists.xenproject.org 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