Re: [PATCH v14 08/11] qapi/s390/cpu topology: change-topology monitor command

[Pierre Morel <pmorel@linux.ibm.com>]

On 1/11/23 11:09, Thomas Huth wrote:
> On 05/01/2023 15.53, Pierre Morel wrote:
>> The modification of the CPU attributes are done through a monitor
>> commands.
> 
> s/commands/command/

thx

> 
>> It allows to move the core inside the topology tree to optimise
>> the cache usage in the case the host's hypervizor previously
> 
> s/hypervizor/hypervisor/

yes, thx

> 
>> moved the CPU.
>>
>> The same command allows to modifiy the CPU attributes modifiers
> 
> s/modifiy/modify/

thx

> 
>> like polarization entitlement and the dedicated attribute to notify
>> the guest if the host admin modified scheduling or dedication of a vCPU.
>>
>> With this knowledge the guest has the possibility to optimize the
>> usage of the vCPUs.
> 
> Hmm, who is supposed to call this QMP command in the future? Will there 
> be a new daemon monitoring the CPU changes in the host? Or will there be 
> a libvirt addition for this? ... Seems like I still miss the big picture 
> here...
> 
>   Thomas
> 

The first idea is to provide a daemon that could get the information on 
real CPU from the host sysfs and to specify the vCPU topology according 
to the real CPU.

There could be a libvirt command for this too.

The big picture is to provide the guest OS with the real topology so 
that the guest OS can make decisions on the scheduling.

I think that a daemon is perfect I can not imagine anything else than 
the alternative:

1) Do not specify anything and let things go more or less random as 
today by setting the cores in socket,book,drawer in an incremental way.

2) specifying the exact topology

So I do not see the point to let the user or even libvirt specify a 
random topology if it is specified it must be exact.

Regards,
Pierre



-- 
Pierre Morel
IBM Lab Boeblingen