Re: [RFC qemu-server v2 0/4] fix #7282: allow (NUMA aware) vCPU pinning

[Dominik Csapak <d.csapak@proxmox.com>]

I'm in the progress of looking through the code, but want
to give some high level feedback 'early'

I think the approach goes to far for what was intended:

The pinning setting now also influences memory behavior
but we already have the numaX options for that, the intention
was that this is just related to the virtual cores.
I'd prefer for it to stay that way.

If we want to modify the memory handling, we'll have to do
that in the memory/numa/etc. options (or a new separate
one) but don't conflate it with the CPU pinning.

Also, AFAIU this can also change the guest hardware
depending on the host topology no?
If yes, this is a no-go since this breaks live migration,
potentially suspend/resume and backup/restore.

It also can mess up the guest licensing when this is fixed
for some sockets for example.

In general such an options should never overwrite the
explicit values in the config.

Iff we want such a thing, this must be reflected in the
sockets/cores/etc config (e.g. by setting 'auto' or
some thing) and must be  live migration blocker.

In a first applied version I'd really like for it to focus
on pinning vcpus on specific cores (or sets of cores).

This should be opt-in and align with already existing options
(such as numa/memory/sockets/etc) and not break
live migration (e.g. it is ok to pin to different
cpus/hostnodes on another node, but the hardware must
stay the same)

Making memory hostnode selection automatic and inferring guest
topology can also make sense, but should be a separate
patch/series and isn't really what the bug was about.

Let's keep the focus narrow, this also will make the patches
smaller and more easily digestible ;)

I'll answer on the individual patches for style/code things too