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: Tue, 09 Sep 2014 12:34:21 -0700 Message-ID: <540F563D.5080202@linaro.org> References: <1406818852-31856-1-git-send-email-julien.grall@linaro.org> <1410273261.8217.212.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.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1XRRBJ-0008Dn-E1 for xen-devel@lists.xenproject.org; Tue, 09 Sep 2014 19:34:25 +0000 Received: by mail-qa0-f42.google.com with SMTP id dc16so12254434qab.15 for ; Tue, 09 Sep 2014 12:34:22 -0700 (PDT) In-Reply-To: <1410273261.8217.212.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 List-Id: xen-devel@lists.xenproject.org (Adding Christoffer) Hi Ian, On 09/09/14 07:34, Ian Campbell wrote: > On Thu, 2014-07-31 at 16:00 +0100, Julien Grall wrote: >> - Only common device properties (interrupts, regs) are written to >> the guest device tree. Device that needs other properties may not work. > > So I've glanced through the later (more toolstack oriented) bits from > towards the end but I think there's a question of the target users which > needs thinking about before I can have a sensible opinion on those. > > As I see it the main purpose of this series is to get the underlying > plumbing in place (wiring up iommus, routing IRQs etc) to support guests > with passthrough devices, for embedded folks to use and to provide a > basis for eventual PCI passthrough functionality. I really want to see > this stuff in 4.5 > > What I'm concerned about is the toolstack side. TBH I'm not very keen on > the thing with exposing very DT specific stuff like compatible strings > down from the hypervisor via domctls. > It's not really clear how best to expose this functionality, I have a > feeling that this series either goes too far or not far enough and ends > up not really satisfying anyone. I don't see many other solutions to get the compatible strings. There is no easy way to get the property from DOM0, unless we introduce a new driver in Linux. > 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). > and perhaps a back door > to allow the injection a blob of DT into the guest's DT to describe > them. i.e. enough to actually get stuff done but not pretending to be > too finely integrated. I would be fine with this solution for Xen 4.5. I will give a look to see what could be done. > Then we can revisit the "proper" toolstack side for 4.6. Otherwise I > fear that by the time we get the toolstack side sorted out to our > satisfaction the basic functionality (which seems to be largely done) > will have missed 4.5. Depending of the use cases, your solution based on "iomem", "irq" and DT blob might be enough for device platform passthrough. Regards, -- Julien Grall