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

Re: [PATCH v3 4/6] xen/cpupool: Create different cpupools at boot time



Hi,

On 22/03/2022 08:47, Bertrand Marquis wrote:
Hi Julien,

On 22 Mar 2022, at 09:35, Bertrand Marquis <bertrand.marquis@xxxxxxx> wrote:

Hi Julien,

On 21 Mar 2022, at 18:44, Julien Grall <julien@xxxxxxx> wrote:

Hi Bertrand,

On 21/03/2022 17:19, Bertrand Marquis wrote:
On 21 Mar 2022, at 17:36, Julien Grall <julien@xxxxxxx> wrote:
So I don’t know why on x86 we must have cpu0 in cpupool0, maybe x86 maintainer 
have more knowledge about that and
I can put a comment here.

On Arm, we are not yet supporting all the CPU features that x86 supports (e.g. 
CPU hotplug, suspend/resume...). So I a am bit concerned that the restriction 
is just not there yet (or possibly hidden).

Therefore, before lifting the restriction on Arm (and other arch), I would like 
us to understand why it is necessary on x86.

We may not have the answer quickly, so is it going to be a problem to keep the 
restriction on Arm?
I am ok to keep the limitation to have dom0 always running on cpu0.
Only limitation I can see is that on a big little system, dom0 needs to stay on 
the type of core of the first booted core.

Where does this limitation come from?

If dom0 must run on core0 and core0 is Little then you cannot build a system 
where dom0 is running on big cores.
If the limitation is not there, you can build such a configuration without any 
dependency to the boot core type.

This might not be completely clear so let me rephrase:
In the current system:
- dom0 must run on cpupool-0

I don't think we need this restriction. In fact, with this series it will become more a problem because the cpupool ID will based on how we parse the Device-Tree.

So for dom0, we need to specify explicitely the cpupool to be used.

- cpupool-0 must contain the boot core
- consequence: dom0 must run on the boot core

If boot core is little, you cannot build as system where dom0 runs only on the 
big cores.
Removing the second limitation (which is not required on arm) is making it 
possible.

IMHO removing the second restriction is a lot more risky than removing the first one.

Cheers,

--
Julien Grall



 


Rackspace

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