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

[Eduardo Habkost]

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" <address@hidden> 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