From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [RFC 06/19] xen/arm: Implement hypercall PHYSDEVOP_map_pirq Date: Tue, 15 Jul 2014 14:01:00 +0100 Message-ID: <53C5260C.4010803@linaro.org> References: <1402935486-29136-1-git-send-email-julien.grall@linaro.org> <1402935486-29136-7-git-send-email-julien.grall@linaro.org> <53A2CBE1.1020403@linaro.org> <1404386851.17859.11.camel@kazak.uk.xensource.com> <53B54659.9090809@linaro.org> <1404391984.19893.5.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.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1X72Lw-0000hd-TI for xen-devel@lists.xenproject.org; Tue, 15 Jul 2014 13:01:05 +0000 Received: by mail-we0-f180.google.com with SMTP id k48so4644141wev.11 for ; Tue, 15 Jul 2014 06:01:03 -0700 (PDT) In-Reply-To: <1404391984.19893.5.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, stefano.stabellini@citrix.com, Stefano Stabellini List-Id: xen-devel@lists.xenproject.org Hi Ian, Sorry I forgot to answer to this mail. On 03/07/14 13:53, Ian Campbell wrote: > On Thu, 2014-07-03 at 13:02 +0100, Julien Grall wrote: >>>>> Handling virq != pirq will be more complex as we need to take into >>>>> account of the hotplug solution. >>> >>> What's the issue here? Something to do with irqdesc->irq-pending lookup? >>> >>> Seems like irqdesc needs to store the domain and virq number when the >>> irq is passed through. I assume it must store the dmain already. >> >> The issues are mostly: >> - we need to defer the vGIC IRQs allocation >> - Add a new hypercall to setup the number of IRQs >> - How do we handle hotplug? > > Those all sound like issues with having dynamic numbers of irqs, rather > than with a non-1:1 virq<->pirq mapping per-se. Yes. I will stick on a static allocation and 1:1 mapping for this first version. We could rework it when PCI passthrough will be added. >> >>> Do we think it is the case that we are eventually going to need a guest >>> cfg option pci = 0|1? I think the answer is yes. Assinging a pci device >>> would cause pci=1, or you can set pci=1 to enable hotplug of pci devices >>> later (i.e. mmio space is reserved, INTx interrupts are assigned etc). >> >> I'm not sure to understand what we would need a "pci" cfg option... For >> now, this series doesn't aim to support PCI. So I think we could defer >> this problem later. > > Yeah, we got onto PCI somehow. > > So long as we are happy not being able to hotplug platform devices I > think we don't need an equivalent option (the point would be to only > setup huge numbers of SPIs, reserve MMIO space etc if it was going to be > used). We can reuse the number of IRQs used by the HW. The current series allocates SPIs for guest even if we don't plan to passthrough a device. Are we fine with this drawback for Xen 4.5? Regards, -- Julien Grall