Re: [Qemu-devel] [PATCH v4 0/9] enable numa configuration before machine_init() from QMP

[Igor Mammedov]

On Wed, 18 Apr 2018 09:08:30 +0200
Markus Armbruster <address@hidden> wrote:

> Eduardo Habkost <address@hidden> writes:
> 
> > On Tue, Apr 17, 2018 at 05:41:10PM +0200, Igor Mammedov wrote:  
> >> On Tue, 17 Apr 2018 11:27:39 -0300
> >> Eduardo Habkost <address@hidden> wrote:
> >>   
> >> > On Tue, Apr 17, 2018 at 04:13:34PM +0200, Markus Armbruster wrote:  
> >> > > Igor Mammedov <address@hidden> writes:
> >> > > 
> >> > > [...]    
> >> > > > Series allows to configure NUMA mapping at runtime using QMP
> >> > > > interface. For that to happen it introduces a new '-preconfig' CLI 
> >> > > > option
> >> > > > which allows to pause QEMU before machine_init() is run and
> >> > > > adds new set-numa-node QMP command which in conjunction with
> >> > > > query-hotpluggable-cpus allows to configure NUMA mapping for cpus.
> >> > > >
> >> > > > Later we can modify other commands to run early, for example 
> >> > > > device_add.
> >> > > > I recall SPAPR had problem when libvirt started QEMU with -S and, 
> >> > > > while it's
> >> > > > paused, added CPUs with device_add. Intent was to coldplug CPUs (but 
> >> > > > at that
> >> > > > stage it's considered hotplug already), so SPAPR had to work around 
> >> > > > the issue.    
> >> > > 
> >> > > That instance is just stupidity / laziness, I think: we consider any
> >> > > plug after machine creation a hot plug.  Real machines remain cold 
> >> > > until
> >> > > you press the power button.  Our virtual machines should remain cold
> >> > > until they start running, i.e. with -S until the first "cont".  
> >> It probably would be too risky to change semantics of -S from hotplug to 
> >> coldplug.
> >> But even if we were easy it won't matter in case if dynamic configuration
> >> done properly. More on it below.
> >>   
> >> > > I vaguely remember me asking this before, but your answer didn't make 
> >> > > it
> >> > > into this cover letter, which gives me a pretext to ask again instead 
> >> > > of
> >> > > looking it up in the archives: what exactly prevents us from keeping 
> >> > > the
> >> > > machine cold enough for numa configuration until the first "cont"?    
> >> > 
> >> > I also think this would be better, but it seems to be difficult
> >> > in practice, see:
> >> > http://mid.mail-archive.com/address@hidden  
> >> 
> >> In addition to Eduardo's reply, here is what I've answered back
> >> when you've asked question the 1st time (v2 late at -S pause point 
> >> reconfig):
> >> https://www.mail-archive.com/address@hidden/msg504140.html
> >> 
> >> In short:
> >> I think it's wrong in general doing fixups after machine is build
> >> instead of getting correct configuration before building machine.
> >> That's going to be complex and fragile and might be hard to do at
> >> all depending on what we are fixing up.  
> >
> > What "building the machine" should mean, exactly, for external
> > users?
under "building machine", I've meant machine_run_board_init()
and all follow up steps to machine_done stage.

> > The main question I'd like to see answered is: why exactly we
> > must "build" the machine before the first "cont" is issued when
> > using -S?  Why can't we delay everything to "cont" when using -S?  
Nor sure what question is about,
Did you mean if it were possible to postpone machine_run_board_init()
and all later steps to -S/cont time?
 
> > Is it just because it's a long and complex task?  Does that mean
> > we might still do that eventually, and eliminate the
> > prelaunch/preconfig distinction in the distant future?  
> 
> Why would anyone want to use -S going forward?  For reasons other "we've
> always used -S, and can't be bothered to change".
We should be able to deprecate/remove -S once we can do all
initial configuration that's possible to do there at
preconfig time.
 
> > Even if we follow your approach, we need to answer these
> > questions.  I'm sure we will try to reorder initialization steps
> > between the preconfig/prelaunch states in the future, and we
> > shouldn't break any expectations from external users when doing
> > that.
As minimum I expect -preconfig to be a runtime equivalent to CLI,
with difference that it will be interactive and use QMP interface.
As long as it sits between CLI parsing and the rest of initialization
it shouldn't break that.

> Moreover, the questions need to be answered in Git.  Commit message,
> comments, docs/, use your judgement.
I've thought that commit messages/patches were describing introduced
changes sufficiently. But I've been sitting on these patches for
a long time and what's obvious to me might be not so clear to others.
I might just not see what's missing. Any suggestions to improve it
are welcome.