[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v2 09/21] xen/arm: Release IRQ routed to a domain when it's destroying



On 08/06/2014 05:53 PM, Stefano Stabellini wrote:
> On Wed, 6 Aug 2014, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 08/06/2014 04:49 PM, Stefano Stabellini wrote:
>>> On Thu, 31 Jul 2014, Julien Grall wrote:
>>>> Xen has to release IRQ routed to a domain in order to reuse later. 
>>>> Currently
>>>> only SPIs can be routed to the guest so we only need to browse SPIs for a
>>>> specific domain.
>>>>
>>>> Futhermore, a guest can crash and let the IRQ in an incorrect state (i.e 
>>>> has
>>>> not being EOIed). Xen will have to reset the IRQ in order to be able to 
>>>> reuse
>>>> the IRQ later.
>>>>
>>>> Introduce 2 new functions for release an IRQ routed to a domain:
>>>>     - release_guest_irq: upper level to retrieve the IRQ, call the GIC
>>>>     code and release the action
>>>>     - gic_remove_guest_irq: Check if we can remove the IRQ, and reset
>>>>     it if necessary
>>>>
>>>> Signed-off-by: Julien Grall <julien.grall@xxxxxxxxxx>
>>>>
>>>> ---
>>>>     Changes in v2:
>>>>         - Drop the desc->handler = &no_irq_type in release_irq as it's
>>>>         buggy the IRQ is routed to Xen
>>>>         - Add release_guest_irq and gic_remove_guest_irq
>>>> ---
>>>>  xen/arch/arm/gic.c        |   36 ++++++++++++++++++++++++++++++++++
>>>>  xen/arch/arm/irq.c        |   48 
>>>> +++++++++++++++++++++++++++++++++++++++++++++
>>>>  xen/arch/arm/vgic.c       |   16 +++++++++++++++
>>>>  xen/include/asm-arm/gic.h |    4 ++++
>>>>  xen/include/asm-arm/irq.h |    2 ++
>>>>  5 files changed, 106 insertions(+)
>>>>
>>>> diff --git a/xen/arch/arm/gic.c b/xen/arch/arm/gic.c
>>>> index 8ef8764..22f331a 100644
>>>> --- a/xen/arch/arm/gic.c
>>>> +++ b/xen/arch/arm/gic.c
>>>> @@ -144,6 +144,42 @@ void gic_route_irq_to_guest(struct domain *d, 
>>>> unsigned int virq,
>>>>      p->desc = desc;
>>>>  }
>>>>  
>>>> +/* This function only works with SPIs for now */
>>>> +int gic_remove_irq_from_guest(struct domain *d, unsigned int virq,
>>>> +                              struct irq_desc *desc)
>>>> +{
>>>> +    struct pending_irq *p = irq_to_pending(d->vcpu[0], virq);
>>>
>>> Use vgic_get_target_vcpu to get the target vcpu of virq. You can pass
>>> d->vcpu[0] as first argument to vgic_get_target_vcpu.
>>
>> Why do I need to add vgic_get_target_vcpu? This function is only able to
>> handle SPIs which is shared between VCPU.
> 
> OK, in that case ASSERT(virq >= 32 && virq < nr_lines). I am fine either way.
> Also see below.

It's implicitly done by (p->desc == desc). p->desc is only set for SPIs
assigned to a guest. If desc is NULL, then it will fault a bit later.
If someone doesn't use this API to route an IRQ then it's his fault.

Hence, this as been checked in route_irq_guest. I don't think we should
bother to check again.

>>>
>>>> @@ -479,6 +480,53 @@ out:
>>>>      return retval;
>>>>  }
>>>>  
>>>> +int release_guest_irq(struct domain *d, unsigned int virq)
>>>> +{
>>>> +    struct irq_desc *desc;
>>>> +    struct irq_guest *info;
>>>> +    unsigned long flags;
>>>> +    struct pending_irq *p;
>>>> +    int ret;
>>>> +
>>>> +    if ( virq >= vgic_num_irqs(d) )
>>>> +        return -EINVAL;
>>>> +
>>>> +    p = irq_to_pending(d->vcpu[0], virq);
>>>> +    if ( !p->desc )
>>>> +        return -EINVAL;
>>>
>>> Same here: call vgic_get_target_vcpu.
>>> Also if this function is supposed to work only with SPIs, you should add
>>> a comment or explicitly check for it.
>>
>> route_irq_to_guest already check if we are able to route an IRQ or not.
>> For non-SPIs the function will bailout.
>>
>> So, here, it's impossible to have p->desc set to another value than NULL
>> for non-SPIs.
>>
>> Or Xen is buggy will likely fail in another place.
> 
> If you do:
> 
> p = irq_to_pending(d->vcpu[0], virq);
> 
> you are actually introducing more code that cannot cope with non-SGIs.
> So you should either:
> 
> 1) esplicitely check for it (add an ASSERT)

Already done in route_irq_to_guest. I don't think we have to add yet
another assert here.

> 2) replace it with code that can cope with non-SGIs, such us
> irq_to_pending(vgic_get_target_vcpu(d->vcpu[0], virq), virq)

This code won't cope with non-SGIs (here PPIs). As PPIs have an irq_desc
per CPU we will have to loop on every VCPU to unmap it.

But I doubt we will have PPIs in future, there is more issues to handle
(such as the number of VCPUs doesn't match the number of physical CPUs).

-- 
Julien Grall

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.