xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@linaro.org>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: julien.grall@citrix.com, xen-devel@lists.xensource.com,
	Ian.Campbell@citrix.com
Subject: Re: [PATCH v8 13/13] gic_remove_from_queues: take a lock on the right vcpu
Date: Thu, 22 May 2014 19:10:40 +0100	[thread overview]
Message-ID: <537E3DA0.7060007@linaro.org> (raw)
In-Reply-To: <alpine.DEB.2.02.1405221842140.14596@kaball.uk.xensource.com>



On 22/05/14 18:45, Stefano Stabellini wrote:
> On Thu, 22 May 2014, Julien Grall wrote:
>> Hi Stefano,
>>
>> On 22/05/14 13:32, Stefano Stabellini wrote:
>>> At the moment gic_remove_from_queues doesn't handle the case where the
>>> guest kernel disables an irq on a different vcpu compared to the one
>>> currently receiving the interrupt.
>>> Make sure to take the right vcpu lock before removing the irq from
>>> lr_queue.
>>
>> I see the same issue with vgic_enable_irqs. We may inject to the wrong VCPU
>> (i.e other than 0).
>>
>> I think we should have the same case in vgic_enable_irqs.
>
> I think it would make more sense to print a warning in
> vgic_distr_mmio_write GICD_ITARGETSR rather than vgic_enable_irqs.

IHMO the warning is not enougth. We may screw your state machine.


BTW, for your todo:

 > +    /* TODO: evict the irq from LRs */

We should not evict the IRQ from LRs. The guest may disable the IRQ 
while he is in the IRQ context (and before the IRQ has been EOI). If you 
drop the IRQs from the LRs, this can result to a maintenance interrupt:

"If the specified Interrupt does not exist in the
List registers, the GICH_HCR.EOIcount field is incremented, potentially 
generating a maintenance interrupt."

Regards,

-- 
Julien Grall

  reply	other threads:[~2014-05-22 18:10 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-22 12:31 [PATCH v8 0/13] remove maintenance interrupts Stefano Stabellini
2014-05-22 12:32 ` [PATCH v8 01/13] xen/arm: no need to set HCR_VI when using the vgic to inject irqs Stefano Stabellini
2014-05-22 12:32 ` [PATCH v8 02/13] xen/arm: remove unused virtual parameter from vgic_vcpu_inject_irq Stefano Stabellini
2014-05-22 12:32 ` [PATCH v8 03/13] xen/arm: set GICH_HCR_UIE if all the LRs are in use Stefano Stabellini
2014-05-22 12:32 ` [PATCH v8 04/13] xen/arm: support HW interrupts, do not request maintenance_interrupts Stefano Stabellini
2014-05-22 15:31   ` Julien Grall
2014-05-22 12:32 ` [PATCH v8 05/13] xen/arm: nr_lrs should be uint8_t Stefano Stabellini
2014-05-22 12:32 ` [PATCH v8 06/13] xen/arm: keep track of the GICH_LR used for the irq in struct pending_irq Stefano Stabellini
2014-05-22 15:37   ` Julien Grall
2014-05-22 12:32 ` [PATCH v8 07/13] xen/arm: s/gic_set_guest_irq/gic_raise_guest_irq Stefano Stabellini
2014-05-22 12:32 ` [PATCH v8 08/13] xen/arm: rename GIC_IRQ_GUEST_PENDING to GIC_IRQ_GUEST_QUEUED Stefano Stabellini
2014-05-22 15:39   ` Julien Grall
2014-06-06 15:15   ` Ian Campbell
2014-05-22 12:32 ` [PATCH v8 09/13] xen/arm: second irq injection while the first irq is still inflight Stefano Stabellini
2014-05-22 15:48   ` Julien Grall
2014-05-22 17:39     ` Stefano Stabellini
2014-05-22 18:05       ` Julien Grall
2014-05-23 14:50         ` Stefano Stabellini
2014-05-23 15:14           ` Julien Grall
2014-05-23 17:24             ` Stefano Stabellini
2014-05-25 18:46               ` Julien Grall
2014-05-27 16:53                 ` Stefano Stabellini
2014-06-06 15:25   ` Ian Campbell
2014-06-09 10:34     ` Stefano Stabellini
2014-05-22 12:32 ` [PATCH v8 10/13] xen/arm: don't protect GICH and lr_queue accesses with gic.lock Stefano Stabellini
2014-05-22 16:04   ` Julien Grall
2014-05-22 12:32 ` [PATCH v8 11/13] xen/arm: gic_events_need_delivery and irq priorities Stefano Stabellini
2014-05-22 12:32 ` [PATCH v8 12/13] xen/arm: introduce GIC_PRI_TO_GUEST macro Stefano Stabellini
2014-05-22 12:32 ` [PATCH v8 13/13] gic_remove_from_queues: take a lock on the right vcpu Stefano Stabellini
2014-05-22 16:10   ` Julien Grall
2014-05-22 17:45     ` Stefano Stabellini
2014-05-22 18:10       ` Julien Grall [this message]
2014-05-23 17:33         ` Stefano Stabellini
2014-05-23 17:46           ` Julien Grall
2014-05-25 15:39             ` Stefano Stabellini
2014-05-25 17:37               ` Julien Grall
2014-05-25 17:44                 ` Stefano Stabellini
2014-05-25 17:54                   ` Stefano Stabellini

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=537E3DA0.7060007@linaro.org \
    --to=julien.grall@linaro.org \
    --cc=Ian.Campbell@citrix.com \
    --cc=julien.grall@citrix.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xensource.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).