Re: [Xen-devel] [PATCH v3 13/24] xen/arm: Implement hypercall PHYSDEVOP_{, un}map_pirq

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

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 <julien.grall@xxxxxxxxxx>
> > >>>> Cc: Jan Beulich <jbeulich@xxxxxxxx>
> > >>>>
> > >>>> ---
> > >>>>     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?



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel