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: Thu, 29 Jan 2015 12:26:49 +0000 Message-ID: <54CA2709.9080409@linaro.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1YGoBs-00032E-LH for xen-devel@lists.xenproject.org; Thu, 29 Jan 2015 12:27:20 +0000 Received: by mail-wi0-f181.google.com with SMTP id fb4so23832826wid.2 for ; Thu, 29 Jan 2015 04:27:18 -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 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. >>> >>> >>>> 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. > > That's not very useful. I think that the vIRQ passed to PHYSDEV_map_pirq > should be a vIRQ in the destination domain, not the source domain. > > In fact on x86 the pirq parameter to PHYSDEV_map_pirq is interpreted as > pirq in the destination domain too. I'm talking about the index parameter. It's a vIRQ in the domain issue the hypercall not the real IRQ. >> 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. > > That's bad. I plan to support it for the next series. This change shouldn't impact the other patches of the series, so I decided to send a new version to gather some comments. Regards, -- Julien Grall