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

[Julien Grall <julien.grall@xxxxxxxxxx>]

Hi Ian,

On 20/02/15 16:53, Ian Campbell wrote:
> 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.

That would happen if we decide to implement an interrupt controller
which doesn't support virtualization.

Regards,

-- 
Julien Grall

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