On Wed, 20 Oct 2021 16:15:29 +0200
Michal Prívozník <mprivozn@xxxxxxxxxx> wrote:
> On 10/20/21 1:18 PM, Peter Krempa wrote:
> > On Wed, Oct 20, 2021 at 13:07:59 +0200, Michal Prívozník wrote:
> >> On 10/6/21 3:32 PM, Igor Mammedov wrote:
> >>> On Thu, 30 Sep 2021 14:08:34 +0200
> >>> Peter Krempa <pkrempa@xxxxxxxxxx> wrote:
> >
> > [...]
> >
> >> 2) In my experiments I try to mimic what libvirt does. Here's my cmd
> >> line:
> >>
> >> qemu-system-x86_64 \
> >> -S \
> >> -preconfig \
> >> -cpu host \
> >> -smp 120,sockets=2,dies=3,cores=4,threads=5 \
> >> -object '{"qom-type":"memory-backend-memfd","id":"ram-node0","size":4294967296,"host-nodes":[0],"policy":"bind"}' \
> >> -numa node,nodeid=0,memdev=ram-node0 \
> >> -no-user-config \
> >> -nodefaults \
> >> -no-shutdown \
> >> -qmp stdio
> >>
> >> and here is my QMP log:
> >>
> >> {"QMP": {"version": {"qemu": {"micro": 50, "minor": 1, "major": 6}, "package": "v6.1.0-1552-g362534a643"}, "capabilities": ["oob"]}}
> >>
> >> {"execute":"qmp_capabilities"}
> >> {"return": {}}
> >>
> >> {"execute":"query-hotpluggable-cpus"}
> >> {"return": [{"props": {"core-id": 3, "thread-id": 4, "die-id": 2, "socket-id": 1}, "vcpus-count": 1, "type": "host-x86_64-cpu"}, {"props": {"core-id": 3, "thread-id": 3, "die-id": 2, "socket-id": 1}, "vcpus-count": 1, "type": "host-x86_64-cpu"}, {"props": {"core-id": 3, "thread-id": 2, "die-id": 2, "socket-id": 1}, "vcpus-count": 1, "type": "host-x86_64-cpu"}, {"props": {"core-id": 3, "thread-id": 1, "die-id": 2, "socket-id": 1}, "vcpus-count": 1, "type": "host-x86_64-cpu"}, {"props": {"core-id": 3, "thread-id": 0, "die-id": 2, "socket-id": 1}, "vcpus-count": 1, "type": "host-x86_64-cpu"}, {"props": {"core-id": 2, "thread-id": 4, "die-id": 2, "socket-id": 1}, "vcpus-count": 1, "type": "host-x86_64-cpu"},
> >> <snip/>
> >> {"props": {"core-id": 0, "thread-id": 0, "die-id": 0, "socket-id": 0}, "vcpus-count": 1, "type": "host-x86_64-cpu"}]}
> >>
> >>
> >> I can see that query-hotpluggable-cpus returns an array. Can I safely
> >> assume that vCPU ID == index in the array? I mean, if I did have -numa
> >
> > No, this assumption would be incorrect on the aforementioned PPC
> > platform where one entry in the returned array can describe multiple
> > cores.
> >
> > qemuDomainFilterHotplugVcpuEntities is the code that cross-references
> > the libvirt "index" with the data returned by query-hotpluggable cpus.
> >
> > The important bit is the 'vcpus-count' property. The code which deals
> > with hotplug is already fetching everything that's needed.
>
> Ah, I see. So my assumption would be correct if vcpus-count would be 1
> for all entries. If it isn't then I need to account for how much
only for some boards.
An entry in array describes an single entity that should be handled
as a single device by user (-device/plug/unplug/other mapping options)
(and the entity might have 1 or more vCPUs (threads) depending on
target arch/board).
> vcpus-count is in each entity. Fair enough. But
> qemuDomainFilterHotplugVcpuEntities() doesn't really do vCPU ID ->
> [socket, core, thread] translation, does it?
>
>
> But even if it did, I am still wondering what the purpose of this whole
> exercise is. QEMU won't be able to drop ID -> [socket, core, thread]
> mapping. The only thing it would be able to drop is a few lines of code
> handling command line. Am I missing something obvious?
I described in other email why QEMU is dropping cpu_idex on external
interfaces (it's possible to drop it internally too, but I don't see
much gain there vs effort such refactoring would require).
Sure thing, you can invent/maintain libvirt internal
"vCPU ID" -> [topo props]
mapping if it's necessary.
However using just a "vCPU ID" will obscure topology information
from upper layers.
Maybe providing a list of CPUs as an external interface would be better,
then user can pick up which CPUs they wish to add/delete/assign/...
using items from that list.
> Michal
>
