From mboxrd@z Thu Jan 1 00:00:00 1970 From: Julien Grall Subject: Re: [PATCH v3 13/24] xen/arm: Implement hypercall PHYSDEVOP_{, un}map_pirq Date: Tue, 20 Jan 2015 14:01:13 +0000 Message-ID: <54BE5FA9.2090508@linaro.org> References: <1421159133-31526-1-git-send-email-julien.grall@linaro.org> <1421159133-31526-14-git-send-email-julien.grall@linaro.org> <54BD44E20200007800056A4C@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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 1YDZNI-0000cN-HR for xen-devel@lists.xenproject.org; Tue, 20 Jan 2015 14:01:44 +0000 Received: by mail-we0-f179.google.com with SMTP id q59so13955687wes.10 for ; Tue, 20 Jan 2015 06:01:42 -0800 (PST) In-Reply-To: <54BD44E20200007800056A4C@mail.emea.novell.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: Jan Beulich Cc: xen-devel@lists.xenproject.org, stefano.stabellini@citrix.com, ian.campbell@citrix.com, tim@xen.org List-Id: xen-devel@lists.xenproject.org On 19/01/15 16:54, Jan Beulich wrote: >>>> On 13.01.15 at 15:25, 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'm not sure either - much depends on the possible confusion this > may cause to the callers (i.e. if they live in common code, they > may expect the hypercall to do a certain thing, whereas if the > callers are all [expected to be] in arch code, then I'd consider such > overloading okay). PHYSDEVOP_{,un}map_pirq hypercalls are used in common code such as libxl (tools/libxl/libxc_create.c and pci code). There is a similar problem with XEN_DOMCTL_irq_permission. AFAIK, Linux is also using PHYSDEVOP_{,un}map_pirq to map an interrupt into itself. It may have confusion, if we decide to implement PIRQ in ARM. I believe it will never happen because the interrupt can be delivered via a virtual interface. Regards, -- Julien Grall