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. > 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. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
