On Wed, Oct 18, 2017 at 04:27:47PM +0100, Daniel P. Berrange wrote: > On Wed, Oct 18, 2017 at 05:24:12PM +0200, Igor Mammedov wrote: > > On Wed, 18 Oct 2017 15:49:36 +0100 > > "Daniel P. Berrange" <berra...@redhat.com> wrote: > > > > > On Wed, Oct 18, 2017 at 04:44:35PM +0200, Igor Mammedov wrote: > > > > not sure I parse question but looking at libvirt's domain docs > > > > it mentions > > > > <numa> > > > > <cell id='0' cpus='0-3' memory='512000' unit='KiB'/> > > > > <cell id='1' cpus='4-7' memory='512000' unit='KiB' > > > > memAccess='shared'/> > > > > </numa> > > > > > > > > here libvirt assumes that there are cpus with cpu-index in range 0-7 > > > > /and probably duplicates logic that calculates cpu-index/ > > > > If libvirt would continue to duplicate logic we could skip on > > > > implementing early runtime QMP in QEMU and also drop support for > > > > query-hotpluggable-cpus as libvirt would be able to compute > > > > properties/values on it's own. > > > > > > From the POV of the XML, these CPU numbers are *not* required to be > > > the same as any QEMU CPU index. This is just saying that we've got > > > a <vcpus>8</vcpu> element, and we want the first 4 CPUs in one node > > > and the second 4 in the second node. > > > > > > If QEMU assigns CPU indexes 70-77 internally, that's not relevant to > > > the XML POV, which uses 0-7 regardless. If there ever was such a > > > disjoint representation of CPU indexes libvirt would have to remap > > > whats in the XML to match whats in QEMU > > that's what I'm saying, libvirt has to knows which cpu-indexes are valid > > to use so it is able to build CLI which works: > > "-numa node,nodeid=0,cpus=0-3 -numa node,nodeid=1cpus=4-7" > > and if algoritm that assigns cpu-indexes would change on QEMU side > > it would break libvirt. > > That's why I think QEMU should libvirt assign 'id' values to each > CPU, just like we do for other devices/object. That way QEMU can > have whatever CPU index numbering scheme it likes and it has no > effect on the mgmt app.
Adding an intermediate ID doesn't seem to be address the problem at all: you would still need to tell QEMU which socket/core/thread combination correspond to which ID, and the set of valid socket/core/thread IDs is defined by the machine-type. > > > now to newer interface > > "-numa cpu,node-id=0,socket-id=0 -numa cpu,node-id=1,socket-id=1" > > libvirt would had to know that socket-id and values 0-1 are valid, > > now moving to spapr > > "-numa cpu,node-id=0,core-id=0 -numa cpu,node-id=1,core-id=8" > > here valid values are not so obvious, core-id values are function > > of "-smp" > > > > this series was written so that mgmt won't have to duplicate logic > > to match the same logic in qemu as libvirt didn't want to maintain > > it, I'd assume because it's fragile. If libvirt would make up valid > > properties/values on it's own we can forget about this series. > > From libvirt POV we all we want to say is have N sockets, each with M > cores, each with O threads. That is architecture agnostic and what I > was trying to illustrate with my earlier proposed CLI syntax. The set of valid socket/core/thread IDs accepted by QEMU is currently machine-dependent. libvirt shouldn't expect them to be architecture agnostic. Defining architecture agnostic rules for them to avoid the need for query-hotpluggable-cpus would still be a valid proposal, but it needs to be written down instead of being just an implicit assumption from the libvirt side. -- Eduardo
