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: Wed, 28 Jan 2015 19:04:31 +0000 Message-ID: <54C932BF.5070009@linaro.org> References: <1421159133-31526-1-git-send-email-julien.grall@linaro.org> <1421159133-31526-14-git-send-email-julien.grall@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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 1YGXvA-0005Vg-Ft for xen-devel@lists.xenproject.org; Wed, 28 Jan 2015 19:05:00 +0000 Received: by mail-wi0-f171.google.com with SMTP id l15so14154421wiw.4 for ; Wed, 28 Jan 2015 11:04:58 -0800 (PST) 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, Jan Beulich , tim@xen.org, ian.campbell@citrix.com, stefano.stabellini@citrix.com List-Id: xen-devel@lists.xenproject.org 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. > > >> TODO: This patch is lacking of support of vIRQ != IRQ. I plan to >> handle it correctly on the next version. > > Why do you say that? From the code in this patch it looks like it > supports vIRQ != IRQ already. Because PHYSDEV_map_pirq is taking a vIRQ number in parameter. This vIRQ is only valid for the domain which issue the hypercall. In our use case, it's DOM0. DOM0 may not have all the time vIRQ == IRQ. Futhermore, on PHYSDEV_unmap_pirq I assume the DOM0 virq == guest virq. > >> Changes in v3: >> - Functions to allocate/release/reserved a VIRQ has been moved >> in a separate patch > > That might be a good idea, but then you need to move that patch before > this one, otherwise it won't compile. As is it would break the build. This patch belongs to a separate patch series. FIY, on the cover letter I explicitly wrote the dependency in other to apply this series. Regards, -- Julien Grall