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

[Julien Grall <julien.grall@arm.com>]

Hi Mirela,

On 16/04/18 15:06, Mirela Simonovic wrote:
> On Mon, Apr 16, 2018 at 1:33 PM, Julien Grall <julien.grall@arm.com> wrote:
>> On 13/04/18 11:19, Mirela Simonovic wrote:
>>> On Thu, Apr 12, 2018 at 10:43 AM, Julien Grall <julien.grall@arm.com>
>>>> On 11/04/18 17:37, Mirela Simonovic wrote:
>>>>> On Wed, Apr 11, 2018 at 6:02 PM, Julien Grall <julien.grall@arm.com
>>>>> <mailto:julien.grall@arm.com>> 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.

Cheers,

-- 
Julien Grall

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel