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

[Julien Grall <julien.grall@xxxxxxxxxx>]

On 19/01/15 16:54, Jan Beulich wrote:
>>>> On 13.01.15 at 15:25, <julien.grall@xxxxxxxxxx> 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'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

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