From: julien.grall@citrix.com (Julien Grall)
To: linux-arm-kernel@lists.infradead.org
Subject: [Xen-devel] xen,arm: enable cpu_hotplug
Date: Thu, 15 Oct 2015 10:58:56 +0100 [thread overview]
Message-ID: <561F78E0.2070004@citrix.com> (raw)
In-Reply-To: <561F78A4.7060507@citrix.com>
On 15/10/15 10:57, Julien Grall wrote:
> Hi Ian,
>
> On 15/10/15 09:39, Ian Campbell wrote:
>> On Thu, 2015-10-15 at 00:23 +0100, Julien Grall wrote:
>>> My second point is related to how Xen is handling interrupt with vCPU.
>>> When PSCI off is called, we will set the _VFP_down flag. This flag is
>>> used in vgic_vcpu_inject_irq and when it's set the interrupt will be
>>> ignored and stay active on the HW GIC forever. If the vCPU is coming
>>> back online, this interrupt will never be received. AFAIU the spec, the
>>> interrupt is expected to stay pending on the distributor side and will
>>> be receive when the vCPU will come back or migrate to another vCPU. A
>>> similar problem can happen when the vCPU is powered on again because we
>>> clear all the interrupt state related to vCPU (see
>>> vgic_clear_pending_irqs).
>>
>> Is there also an interaction with our implementation of ITARGETSR of
>> picking the lowest set bit? e.g. if an IRQ has target 0x6 (targeting CPU 1
>> and CPU2) we will choose CPU 1. If CPU 1 is then unplugged, will we end up
>> targeting CPU 2 or the now-offline CPU 1? In the latter case the lack of
>> interrupts might be considered surprising?
>
> I though about it when I wrote the mail yesterday night.
>
> From the spec section 1.4.3 (ARM IHI 0048B.b):
>
> "The ARM GIC architecture does not guarantee that a 1-N interrupt is
> presented to:
> ? all processors listed in the target processor list
> ? an enabled interface, where at least one interface is enabled."
>
> AFAIU this paragraph, it means that there is no guarantee to receive an
> interrupt if the target mask contain a vCPU offline.
Hmmm I may not have been clear here. I meant that the interrupt will
stay pending in the distributor but not received by the guest.
--
Julien Grall
WARNING: multiple messages have this Message-ID (diff)
From: Julien Grall <julien.grall@citrix.com>
To: Ian Campbell <ian.campbell@citrix.com>,
Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
xen-devel@lists.xensource.com
Cc: linux-arm-kernel@lists.infradead.org
Subject: Re: [Xen-devel] xen,arm: enable cpu_hotplug
Date: Thu, 15 Oct 2015 10:58:56 +0100 [thread overview]
Message-ID: <561F78E0.2070004@citrix.com> (raw)
In-Reply-To: <561F78A4.7060507@citrix.com>
On 15/10/15 10:57, Julien Grall wrote:
> Hi Ian,
>
> On 15/10/15 09:39, Ian Campbell wrote:
>> On Thu, 2015-10-15 at 00:23 +0100, Julien Grall wrote:
>>> My second point is related to how Xen is handling interrupt with vCPU.
>>> When PSCI off is called, we will set the _VFP_down flag. This flag is
>>> used in vgic_vcpu_inject_irq and when it's set the interrupt will be
>>> ignored and stay active on the HW GIC forever. If the vCPU is coming
>>> back online, this interrupt will never be received. AFAIU the spec, the
>>> interrupt is expected to stay pending on the distributor side and will
>>> be receive when the vCPU will come back or migrate to another vCPU. A
>>> similar problem can happen when the vCPU is powered on again because we
>>> clear all the interrupt state related to vCPU (see
>>> vgic_clear_pending_irqs).
>>
>> Is there also an interaction with our implementation of ITARGETSR of
>> picking the lowest set bit? e.g. if an IRQ has target 0x6 (targeting CPU 1
>> and CPU2) we will choose CPU 1. If CPU 1 is then unplugged, will we end up
>> targeting CPU 2 or the now-offline CPU 1? In the latter case the lack of
>> interrupts might be considered surprising?
>
> I though about it when I wrote the mail yesterday night.
>
> From the spec section 1.4.3 (ARM IHI 0048B.b):
>
> "The ARM GIC architecture does not guarantee that a 1-N interrupt is
> presented to:
> — all processors listed in the target processor list
> — an enabled interface, where at least one interface is enabled."
>
> AFAIU this paragraph, it means that there is no guarantee to receive an
> interrupt if the target mask contain a vCPU offline.
Hmmm I may not have been clear here. I meant that the interrupt will
stay pending in the distributor but not received by the guest.
--
Julien Grall
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2015-10-15 9:58 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-14 17:49 xen,arm: enable cpu_hotplug Stefano Stabellini
2015-10-14 17:49 ` Stefano Stabellini
2015-10-14 17:49 ` [PATCH 1/3] xen/arm: Enable cpu_hotplug.c Stefano Stabellini
2015-10-14 17:49 ` Stefano Stabellini
2015-10-14 18:05 ` [Xen-devel] " Konrad Rzeszutek Wilk
2015-10-14 18:05 ` Konrad Rzeszutek Wilk
2015-10-14 18:17 ` Stefano Stabellini
2015-10-14 18:17 ` Stefano Stabellini
2015-10-16 15:21 ` Stefano Stabellini
2015-10-16 15:21 ` Stefano Stabellini
2015-10-14 22:51 ` Julien Grall
2015-10-14 22:51 ` Julien Grall
2015-10-16 15:23 ` Stefano Stabellini
2015-10-16 15:23 ` Stefano Stabellini
2015-10-14 17:49 ` [PATCH 2/3] xen, cpu_hotplug: call device_offline instead of cpu_down Stefano Stabellini
2015-10-14 17:49 ` Stefano Stabellini
2015-10-14 17:49 ` [PATCH 3/3] xen/arm: don't try to re-register vcpu_info on cpu_hotplug Stefano Stabellini
2015-10-14 17:49 ` Stefano Stabellini
2015-10-14 22:32 ` Julien Grall
2015-10-14 22:32 ` Julien Grall
2015-10-16 15:31 ` Stefano Stabellini
2015-10-16 15:31 ` Stefano Stabellini
2015-10-14 23:23 ` xen,arm: enable cpu_hotplug Julien Grall
2015-10-14 23:23 ` Julien Grall
2015-10-15 8:39 ` [Xen-devel] " Ian Campbell
2015-10-15 8:39 ` Ian Campbell
2015-10-15 9:57 ` Julien Grall
2015-10-15 9:57 ` Julien Grall
2015-10-15 9:58 ` Julien Grall [this message]
2015-10-15 9:58 ` Julien Grall
2015-10-16 15:44 ` Stefano Stabellini
2015-10-16 15:44 ` Stefano Stabellini
2015-10-16 15:41 ` Stefano Stabellini
2015-10-16 15:41 ` Stefano Stabellini
2015-10-16 15:45 ` Julien Grall
2015-10-16 15:45 ` Julien Grall
2015-10-16 15:45 ` Stefano Stabellini
2015-10-16 15:45 ` 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=561F78E0.2070004@citrix.com \
--to=julien.grall@citrix.com \
--cc=linux-arm-kernel@lists.infradead.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.