All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@linaro.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: xen-devel@lists.xenproject.org, tim@xen.org,
	ian.campbell@citrix.com, stefano.stabellini@citrix.com
Subject: Re: [PATCH v2 09/21] xen/arm: Release IRQ routed to a domain when it's destroying
Date: Wed, 06 Aug 2014 18:09:53 +0100	[thread overview]
Message-ID: <53E26161.6060206@linaro.org> (raw)
In-Reply-To: <alpine.DEB.2.02.1408061749010.2293@kaball.uk.xensource.com>

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@linaro.org>
>>>>
>>>> ---
>>>>     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

  reply	other threads:[~2014-08-06 17:10 UTC|newest]

Thread overview: 119+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-31 15:00 [PATCH v2 00/21] xen/arm: Add support for non-pci passthrough Julien Grall
2014-07-31 15:00 ` [PATCH v2 01/21] xen/common: do not implicitly permit access to mapped I/O memory Julien Grall
2014-07-31 15:22   ` Julien Grall
2014-07-31 15:00 ` [PATCH v2 02/21] xen: guestcopy: Provide an helper to safely copy string from guest Julien Grall
2014-08-01  8:40   ` Jan Beulich
2014-08-06 14:18     ` Julien Grall
2014-09-09 12:52     ` Ian Campbell
2014-09-09 13:17       ` Jan Beulich
2014-09-09 13:40         ` Ian Campbell
2014-08-06 13:56   ` Stefano Stabellini
2014-08-06 14:22     ` Julien Grall
2014-08-06 16:06   ` Daniel De Graaf
2014-07-31 15:00 ` [PATCH v2 03/21] xen/arm: vgic: Rename nr_lines into nr_spis Julien Grall
2014-08-06 13:58   ` Stefano Stabellini
2014-07-31 15:00 ` [PATCH v2 04/21] xen/arm: vgic: Introduce a function to initialize pending_irq Julien Grall
2014-08-06 14:06   ` Stefano Stabellini
2014-08-06 14:52     ` Julien Grall
2014-08-06 14:57       ` Stefano Stabellini
2014-07-31 15:00 ` [PATCH v2 05/21] xen/arm: follow-up to allow DOM0 manage IRQ and MMIO Julien Grall
2014-09-09 13:07   ` Ian Campbell
2014-09-11 22:32     ` Julien Grall
2014-09-12 10:13       ` Ian Campbell
2014-09-12 19:04         ` Julien Grall
2014-07-31 15:00 ` [PATCH v2 06/21] xen/arm: Allow virq != irq Julien Grall
2014-08-06 14:50   ` Stefano Stabellini
2014-08-06 15:07     ` Julien Grall
2014-08-06 16:48       ` Stefano Stabellini
2014-09-09 13:29   ` Ian Campbell
2014-09-09 18:42     ` Julien Grall
2014-09-11 22:50       ` Julien Grall
2014-09-12 10:13         ` Ian Campbell
2014-09-12 10:19         ` Ian Campbell
2014-07-31 15:00 ` [PATCH v2 07/21] xen/arm: route_irq_to_guest: Check validity of the IRQ Julien Grall
2014-08-06 14:56   ` Stefano Stabellini
2014-07-31 15:00 ` [PATCH v2 08/21] xen/arm: Initialize the virtual GIC later Julien Grall
2014-08-06 15:35   ` Stefano Stabellini
2014-09-09 13:35     ` Ian Campbell
2014-09-09 18:57       ` Julien Grall
2014-09-10 10:08         ` Ian Campbell
2014-09-11 23:01     ` Julien Grall
2014-09-12 10:14       ` Ian Campbell
2014-08-06 17:06   ` Daniel De Graaf
2014-08-29 13:09   ` Andrii Tseglytskyi
2014-08-29 18:57     ` Julien Grall
2014-08-29 19:49       ` Andrii Tseglytskyi
2014-08-29 20:04         ` Julien Grall
2014-08-29 20:14           ` Andrii Tseglytskyi
2014-09-09 13:33           ` Ian Campbell
2014-09-09 19:11             ` Julien Grall
2014-09-10  9:45               ` Andrii Tseglytskyi
2014-09-09 13:37   ` Ian Campbell
     [not found]   ` <CAAHg+HhhsZonrEDdHET93dy=dR1+YF-VPGJ=VwB20RRxWqdSYA@mail.gmail.com>
2014-10-06 16:04     ` Julien Grall
2014-07-31 15:00 ` [PATCH v2 09/21] xen/arm: Release IRQ routed to a domain when it's destroying Julien Grall
2014-08-06 15:49   ` Stefano Stabellini
2014-08-06 16:01     ` Julien Grall
2014-08-06 16:53       ` Stefano Stabellini
2014-08-06 17:09         ` Julien Grall [this message]
2014-08-07 15:36           ` Stefano Stabellini
2014-08-07 15:40             ` Julien Grall
2014-08-07 16:31               ` Stefano Stabellini
2014-08-07 16:35                 ` Julien Grall
2014-08-07 16:39                   ` Stefano Stabellini
2014-09-09 13:53                     ` Ian Campbell
2014-09-09 22:29                       ` Stefano Stabellini
2014-07-31 15:00 ` [PATCH v2 10/21] xen/arm: Implement hypercall PHYSDEVOP_{, un}map_pirq Julien Grall
2014-08-06 16:10   ` Stefano Stabellini
2014-08-29 12:34   ` Andrii Tseglytskyi
2014-08-29 19:08     ` Julien Grall
2014-08-29 19:44       ` Andrii Tseglytskyi
2014-07-31 15:00 ` [PATCH v2 11/21] xen/dts: Use unsigned int for MMIO and IRQ index Julien Grall
2014-08-06 16:12   ` Stefano Stabellini
2014-07-31 15:00 ` [PATCH v2 12/21] xen/dts: Provide an helper to get a DT node from a path provided by a guest Julien Grall
2014-09-09 13:55   ` Ian Campbell
2014-07-31 15:00 ` [PATCH v2 13/21] xen/dts: Add hypercalls to retrieve device node information Julien Grall
2014-08-01  8:50   ` Jan Beulich
2014-08-06 15:17     ` Julien Grall
2014-08-06 15:47       ` Jan Beulich
2014-07-31 15:00 ` [PATCH v2 14/21] xen/passthrough: Introduce iommu_construct Julien Grall
2014-08-01  8:55   ` Jan Beulich
2014-07-31 15:00 ` [PATCH v2 15/21] xen/passthrough: Call arch_iommu_domain_destroy before calling iommu_teardown Julien Grall
2014-08-01  9:00   ` Jan Beulich
2014-07-31 15:00 ` [PATCH v2 16/21] xen/passthrough: iommu_deassign_device_dt: By default reassign device to nobody Julien Grall
2014-08-06 16:23   ` Stefano Stabellini
2015-01-12 16:33     ` Julien Grall
2014-07-31 15:00 ` [PATCH v2 17/21] xen/iommu: arm: Wire iommu DOMCTL for ARM Julien Grall
2014-08-06 16:24   ` Stefano Stabellini
2014-07-31 15:00 ` [PATCH v2 18/21] xen/passthrough: dt: Add new domctl XEN_DOMCTL_assign_dt_device Julien Grall
2014-08-01  9:05   ` Jan Beulich
2014-07-31 15:00 ` [PATCH v2 19/21] xen/arm: Reserve region in guest memory for device passthrough Julien Grall
2014-08-06 16:27   ` Stefano Stabellini
2014-08-06 16:33     ` Julien Grall
2014-08-06 16:44       ` Stefano Stabellini
2014-08-06 16:45         ` Stefano Stabellini
2014-08-06 16:55           ` Julien Grall
2014-08-06 16:57             ` Stefano Stabellini
2014-08-06 16:47         ` Julien Grall
2014-07-31 15:00 ` [PATCH v2 20/21] libxl: Add support for non-PCI passthrough Julien Grall
2014-08-06 16:44   ` Stefano Stabellini
2014-08-06 16:50     ` Julien Grall
2014-08-06 16:58       ` Stefano Stabellini
2014-08-08 14:15         ` Julien Grall
2014-09-09 19:12         ` Julien Grall
2014-09-10 10:08           ` Ian Campbell
2014-07-31 15:00 ` [PATCH v2 21/21] xl: Add new option dtdev Julien Grall
2014-09-09 14:34 ` [PATCH v2 00/21] xen/arm: Add support for non-pci passthrough Ian Campbell
2014-09-09 19:34   ` Julien Grall
2014-09-10  9:22     ` Christoffer Dall
2014-09-10 10:51       ` Ian Campbell
2014-09-10 11:45         ` Christoffer Dall
2014-09-10 12:05           ` Ian Campbell
2014-09-10 22:03           ` Stefano Stabellini
2014-09-11  4:03             ` Christoffer Dall
2014-09-11  8:56               ` Ian Campbell
2014-09-12 19:16         ` Julien Grall
2014-09-10 10:11     ` Ian Campbell
2014-09-10 18:45       ` Julien Grall
2014-09-11  8:58         ` Ian Campbell
2014-09-11 19:11           ` Julien Grall
2014-09-12 10:16             ` Ian Campbell

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53E26161.6060206@linaro.org \
    --to=julien.grall@linaro.org \
    --cc=ian.campbell@citrix.com \
    --cc=stefano.stabellini@citrix.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=tim@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.