Re: [RFC PATCH 0/2] Boot time cpupools

[Juergen Gross <jgross@xxxxxxxx>]

On 17.11.21 12:16, Bertrand Marquis wrote:
> Hi Julien,
>
> > On 17 Nov 2021, at 10:26, Julien Grall <julien@xxxxxxx> wrote:
> >
> > Hi Luca,
> >
> > On 17/11/2021 09:57, Luca Fancellu wrote:
> > > Currently Xen creates a default cpupool0 that contains all the cpu brought up
> > > during boot and it assumes that the platform has only one kind of CPU.
> > > This assumption does not hold on big.LITTLE platform, but putting different
> > > type of CPU in the same cpupool can result in instability and security issues
> > > for the domains running on the pool.
> > I agree that you can't move a LITTLE vCPU to a big pCPU. However...
> >
> > > For this reason this serie introduces an architecture specific way to create
> > > different cpupool at boot time, this is particularly useful on ARM big.LITTLE
> > > platform where there might be the need to have different cpupools for each type
> > > of core, but also systems using NUMA can have different cpu pool for each node.
> > ... from my understanding, all the vCPUs of a domain have to be in the same 
> > cpupool. So with this approach it is not possible:
> >    1) to have a mix of LITTLE and big vCPUs in the domain
> >    2) to create a domain spanning across two NUMA nodes
> >
> > So I think we need to make sure that any solutions we go through will not 
> > prevent us to implement those setups.
> The point of this patch is to make all cores available without breaking the 
> current behaviour of existing system.
May I suggest to add a boot parameter for being able to control this
behavior by other means than compile time configuration?

> Someone not using cpupool will keep running on the same cores as before.
> Someone wanting to use the other cores could assign a guest to the other(s) 
> cpupool (big.LITTLE is just an example with 2 but there are now cores with 3 
> types of cores).
> Someone wanting to build something different can now create new cpupools in 
> Dom0 and assign the cores they want to is to build a guest having access to 
> different types of cores.
>
> The point here is just to make the “other” cores accessible and park them in 
> cpupools so that current behaviour is not changed.
>
> > I can see two options here:
> >   1) Allowing a domain vCPUs to be on a different cpupool
> >   2) Introducing CPU class (see [1])
> >
> > I can't remember why Dario suggested 2) rather than 1) in the past. @Dario, do 
> > you remember it?
> I think 1) is definitely interesting and something that could be looked at in 
> the future.
From scheduler point of view this is IMO a nightmare.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature