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

[Pierre Morel]

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