From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: [PATCH v3 13/24] xen/arm: Implement hypercall PHYSDEVOP_{, un}map_pirq Date: Fri, 20 Feb 2015 16:53:44 +0000 Message-ID: <1424451224.30924.357.camel@citrix.com> References: <1421159133-31526-1-git-send-email-julien.grall@linaro.org> <1421159133-31526-14-git-send-email-julien.grall@linaro.org> <54C932BF.5070009@linaro.org> <54CA2709.9080409@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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 1YOrSb-0005a8-Fx for xen-devel@lists.xenproject.org; Fri, 20 Feb 2015 17:33:53 +0000 In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Stefano Stabellini Cc: xen-devel@lists.xenproject.org, Julien Grall , tim@xen.org, Jan Beulich , stefano.stabellini@citrix.com List-Id: xen-devel@lists.xenproject.org On Thu, 2015-01-29 at 12:33 +0000, Stefano Stabellini wrote: > On Thu, 29 Jan 2015, Julien Grall wrote: > > On 29/01/15 12:17, Stefano Stabellini wrote: > > > On Wed, 28 Jan 2015, Julien Grall wrote: > > >> Hi Stefano, > > >> > > >> On 28/01/15 18:52, Stefano Stabellini wrote: > > >>> On Tue, 13 Jan 2015, Julien Grall wrote: > > >>>> The physdev sub-hypercalls PHYSDEVOP_{,map}_pirq allow the toolstack to > > >>>> assign/deassign a physical IRQ to the guest (via the config options "irqs" > > >>>> for xl). The x86 version is using them with PIRQ (IRQ bound to an event > > >>>> channel). As ARM doesn't have a such concept, we could reuse it to bound > > >>>> a physical IRQ to a virtual IRQ. > > >>>> > > >>>> For now, we allow only SPIs to be mapped to the guest. > > >>>> The type MAP_PIRQ_TYPE_GSI is used for this purpose. > > >>>> > > >>>> Signed-off-by: Julien Grall > > >>>> Cc: Jan Beulich > > >>>> > > >>>> --- > > >>>> I'm not sure it's the best solution to reuse hypercalls for a > > >>>> different purpose. If x86 plan to have a such concept (i.e binding a > > >>>> physical IRQ to a virtual IRQ), we could introduce new hypercalls. > > >>>> Any thoughs? > > >>> > > >>> I think it is OK, as long as we write down very clearly what we are > > >>> doing. Would adding MAP_PIRQ_TYPE_PPI (even as an alias for TYPE_GSI) be helpful? I have a feeling not, since type is, I think, declaring the "namespace" of the index parameter, whereas the pirq is the one containing the vGIC provided virq (or the pirq-type evtchn on x86). Does that make sense? Are we absolutely 100% sure that we will never ever want to map hardware IRQs to guests on ARMs using pirq-type event channels? Because that is what we are essentially ruling out here. x86 is, I think, in the process of gaining vapic support and things like direct irq injection -- essentially the same as what we are doing here. In that case they clearly won't be able to use the same interfaces. The main issue is that physdevop is a stable ABI interface, once we use it one way we are stuck with it. Is there actually any need for this "map a physical irq to a hardware virtualised guest irq" to be a stable API (i.e. used from the dom0 kernel)? If not then I'm inclined to suggest that we can skirt all of these concerns by just adding a new domctl and be done with it. Internally it would perhaps share a lot of code with the map_pirq call, but externally it would give us more flexibility... Jan, do you have any feeling for how this is going to play out on x86 with the vapic stuff?