[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 0/7] xen/arm: CPU hotplug fixes

Hi Mirela,

On 16/04/18 15:06, Mirela Simonovic wrote:
On Mon, Apr 16, 2018 at 1:33 PM, Julien Grall <julien.grall@xxxxxxx> wrote:
On 13/04/18 11:19, Mirela Simonovic wrote:
On Thu, Apr 12, 2018 at 10:43 AM, Julien Grall <julien.grall@xxxxxxx>
On 11/04/18 17:37, Mirela Simonovic wrote:
On Wed, Apr 11, 2018 at 6:02 PM, Julien Grall <julien.grall@xxxxxxx
<mailto:julien.grall@xxxxxxx>> wrote:
So this cover interrupt routed to a virtual CPU. However, this does not
handle interrupts used by Xen. How do you handle them?

For instance SMMUs IRQ might be routed to other interrupt than CPU #0.

Interrupts used by Xen should not wake-up the system and will be
disabled when we suspend the devices used by Xen.

Here you only speak about the suspend use case. While I understand your
ultimate goal is suspend/resume, this series is about CPU hotplug.

AFAIK, the only way and occasion to hotplug a CPU is using > 
disable/enable_nonboot_cpus() within the Xen suspend/resume procedure.

As I mention in a previous e-mail, suspend/resume is not the only way to hotplug a CPU. There are an interface (see XEN_SYSCTL_cpu_hotplug) to allow that from the userland.

But I agree that it is not implemented on Arm, so suspend/resume would be the only way to so far. To be clear, I am not asking you to implement XEN_SYSCTL_cpu_hotplug. Althougth it should be easy to do it and easy for testing CPU offline/online.

We are implementing CPU hotplug only to enable Xen suspend/resume.
This is how it is also done for x86 and we wanted to implement the
equivalent behavior for ARM.
If the cover-letter is misleading please let me know what would be
more appropriate title.

We have multiple places in Xen that could use cpu_up/cpu_down helpers. From the cover letter, it is quite unclear that you are only looking after suspend/resume.

The SYSCTL interface is one of the other use case. While most of the code can be shared, some of them may not make sense.

For instance, in the suspend/resume case routing the interrupt assigned to Xen to CPU#0 may not be necessary because all CPUs should come back later on. However, this should be necessary when offlining a vCPU with SYSCTL interface.

That's why I asked it and I think it should be clarified in the cover letter.


Julien Grall

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.