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

[Julien Grall <julien.grall@xxxxxxx>]

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.
Cheers,

--
Julien Grall

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