[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |