From: julien.grall@citrix.com (Julien Grall)
To: linux-arm-kernel@lists.infradead.org
Subject: xen,arm: enable cpu_hotplug
Date: Thu, 15 Oct 2015 00:23:17 +0100 [thread overview]
Message-ID: <561EE3E5.2000105@citrix.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1510081443100.1179@kaball.uk.xensource.com>
On 14/10/2015 18:49, Stefano Stabellini wrote:
> Hi all,
Hi Stefano,
> this small patch series enable cpu_hotplug in ARM and ARM64 guests,
> using the PV path to plug and unplug the cpus and psci to enable/disable
> them.
That's a cool things to have on ARM!
I've got few questions related to CPU hotplug on Xen side.
Firstly, when we create the device tree we are using max_vcpus to
populate the "/cpus" node. AFAIU, Linux will always start all the vCPU
because they are marked present. That means that it would not be
possible to honor vcpus="N" where N is < max_vcpus. Did I miss something?
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).
That brings me a third one related to migration (and not to this series
specifically). If the interrupt is edge type, it means that same
interrupt can come while it's still active in the LR register. If the
guest has to migrate the IRQ it won't happen because the interrupt is
already active and in the LR, so we will set the pending bit on the
current vCPU.
Regards,
--
Julien Grall
WARNING: multiple messages have this Message-ID (diff)
From: Julien Grall <julien.grall@citrix.com>
To: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
xen-devel@lists.xensource.com
Cc: linux-arm-kernel@lists.infradead.org
Subject: Re: xen,arm: enable cpu_hotplug
Date: Thu, 15 Oct 2015 00:23:17 +0100 [thread overview]
Message-ID: <561EE3E5.2000105@citrix.com> (raw)
In-Reply-To: <alpine.DEB.2.02.1510081443100.1179@kaball.uk.xensource.com>
On 14/10/2015 18:49, Stefano Stabellini wrote:
> Hi all,
Hi Stefano,
> this small patch series enable cpu_hotplug in ARM and ARM64 guests,
> using the PV path to plug and unplug the cpus and psci to enable/disable
> them.
That's a cool things to have on ARM!
I've got few questions related to CPU hotplug on Xen side.
Firstly, when we create the device tree we are using max_vcpus to
populate the "/cpus" node. AFAIU, Linux will always start all the vCPU
because they are marked present. That means that it would not be
possible to honor vcpus="N" where N is < max_vcpus. Did I miss something?
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).
That brings me a third one related to migration (and not to this series
specifically). If the interrupt is edge type, it means that same
interrupt can come while it's still active in the LR register. If the
guest has to migrate the IRQ it won't happen because the interrupt is
already active and in the LR, so we will set the pending bit on the
current vCPU.
Regards,
--
Julien Grall
next prev parent reply other threads:[~2015-10-14 23:23 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 ` Julien Grall [this message]
2015-10-14 23:23 ` xen,arm: enable cpu_hotplug 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
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=561EE3E5.2000105@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.