Re: [Qemu-devel] [RFC 0/6] enable numa configuration before machine_init() from HMP/QMP

["Daniel P. Berrange" <berrange@redhat.com>]

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" <berrange@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 :|