qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 4/6] hmp: Add info commands for preconfig


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH 4/6] hmp: Add info commands for preconfig
Date: Fri, 08 Jun 2018 07:41:41 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)

Igor Mammedov <address@hidden> writes:

> On Thu, 07 Jun 2018 14:22:34 +0200
> Markus Armbruster <address@hidden> wrote:
>
>> Peter Xu <address@hidden> writes:
>> 
>> > On Tue, Jun 05, 2018 at 01:26:34PM +0100, Dr. David Alan Gilbert (git) 
>> > wrote:  
>> >> From: "Dr. David Alan Gilbert" <address@hidden>
>> >> 
>> >> Allow a bunch of the info commands to be used in preconfig.
>> >> Could probably add most of them.  
>> >
>> > I guess some of them may not work yet during preconfig.  E.g.:
>> >
>> > $ ./x86_64-softmmu/qemu-system-x86_64 -preconfig -monitor stdio
>> > QEMU 2.12.50 monitor - type 'help' for more information
>> > (qemu) info mtree
>> > address-space: memory
>> >   0000000000000000-ffffffffffffffff (prio 0, i/o): system
>> >
>> > address-space: I/O
>> >   0000000000000000-000000000000ffff (prio 0, i/o): io
>> >
>> > But it's fine to enable that I guess.
>> >
>> > (Which "info" command would you want to use during preconfig?)
>> >  
>> >> 
>> >> Signed-off-by: Dr. David Alan Gilbert <address@hidden>  
>> >
>> > Reviewed-by: Peter Xu <address@hidden>  
>> 
>> The reason for having -preconfig is us despairing of making -S do the
>> right thing.  We'd have to *understand* the tangled mess that is our
>> startup, and rearrange it so QMP becomes available early enough for
>> configuring NUMA (and other things), yet late enough for everything to
>> work.
> We solve concrete NUMA problem at -S time as was demonstrated by thread:
> "RFC v2 0/4] enable numa configuration before machine  is running from 
> HMP/QMP"
> were pros and cons are were summarized. But that won't scale to other things.
>  
>> -preconfig is a cheap hack to avoid this headache, by bypassing almost
>> all of "everything".
> hack should allow to move configuration steps to early stage one by one
> until the point we could obsolete -S (from configuration point)
> without breaking current -S users and clean up start up mess in process.

Sometimes a hack is the only practical way forward.

>> Now you bring back some of "everything".  Dangerous.  You better show it
>> actually works.  Until you do:
> Tested v2, works as expected so far.

See my reply to Dave.

>> 
>> NAK
>> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]