Re: [Qemu-devel] Preconfig state reachable without --preconfig given

[Igor Mammedov]

On Wed, 6 Jun 2018 12:35:07 +0200
Max Reitz <address@hidden> wrote:

> On 2018-06-04 22:24, Igor Mammedov wrote:
> > On Mon, 4 Jun 2018 16:04:33 +0200
> > Max Reitz <address@hidden> wrote:
> >   
> >> On 2018-06-02 12:46, Michal Privoznik wrote:  
> >>> On 06/01/2018 03:28 PM, Max Reitz wrote:    
> >>>> Hi,
> >>>>
> >>>> The @preconfig RunState documentation states:
> >>>>    
> >>>>> The state is reachable only if the --preconfig CLI option is used.    
> >>>>
> >>>> However, this is not true:
> >>>>
> >>>> $ echo | x86_64-softmmu/qemu-system-x86_64 -monitor stdio
> >>>> QEMU 2.12.50 monitor - type 'help' for more information
> >>>> (qemu)
> >>>> HMP not available in preconfig state, use QMP instead    
> >>>
> >>> Not sure if this is the same bug, but I've noticed libvirt having
> >>> troubles detecting capabilities of qemu and debugging lead to this patch:
> >>>
> >>> http://lists.nongnu.org/archive/html/qemu-devel/2018-06/msg00367.html
> >>>
> >>> (which by no means I claim is proper solution. It might be viewed as
> >>> workaround by expert qemu devels)    
> >>
> >> I haven't investigated further, but that patch breaks iotest 091 (which
> >> tests migration).  It just stops now after the migration has started, so
> >> it never completes.
> >>
> >> Actually, it seems to break all migration iotests (but 203, which
> >> migrates to /dev/null), so I suspect it breaks migration as a whole.  
> > Manual migration to file and restore from it, was tested manually and
> > worked fine, migration-test  from 'make check' is ok as well.
> > It's probably due broken to "echo foo | $QEMU"  
> 
> I highly doubt that, because four of the failing migration iotests are
> written in Python and thus use QMP.  (169, 194, 196, 199)
> 
> They work on master, but fail after that patch.
Indeed, this patch breaks migration. There is fixed version on list [CCed]

[PATCH v3 1/2] cli: Don't run early event loop if no  --preconfig was specified

that passes all iotests, some of tests I had to run several times
due to transient failures not related to the topic (some timing issues)

> 
> Max
> 
> > There is another issue with -nodefaults option leading to indefinite
> > timeout even if --preconfig wasn't used. I've just posted fix for that
> > so that it won't be masked out by Michal/Daniel's fix.
> > But I've run iotests  and -nodefaults fix doesn't affect outcome of the
> > tests (the same 4 failures).   
>