[Top][All Lists]

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

Re: [Qemu-devel] [PATCH] ide: Set BSY bit during FLUSH

From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH] ide: Set BSY bit during FLUSH
Date: Tue, 28 May 2013 11:59:14 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

Am 28.05.2013 um 11:48 hat Paolo Bonzini geschrieben:
> Il 28/05/2013 11:36, Kevin Wolf ha scritto:
> > Am 28.05.2013 um 11:24 hat Paolo Bonzini geschrieben:
> >> Il 28/05/2013 11:18, Kevin Wolf ha scritto:
> >>>>> The other part why I haven't sent a fix yet is that I don't have a test
> >>>>> case for it.
> >>>>
> >>>> Temporarily add a sleep(31) in qemu_fdatasync()?
> >>>>
> >>>> I was lazy in testing with -snapshot to not corrupt my disk image, which
> >>>> would not trigger the same issue since qcow2-backed AFAIU.
> >>>>
> >>>>> I guess I need to extend blkdebug first before this can be
> >>>>> reliably tested by qtest.
> >>>>
> >>>> It can't, since it's not a pure device emulation issue but depends on
> >>>> the relative timing of filesystem operations and subsequent commands.
> >>>
> >>> That's why you need to take influence on the timing. It's no excuse for
> >>> merging without a test case. If we only ever tested devices that have no
> >>> relation to the outside world, our testing would be pretty useless and
> >>> always stay as bad as it is today in many areas.
> >>
> >> I don't think the qtest would be timing dependent.  The Linux testcase
> >> is timing dependent, but for the qtest all you need to check is "is BUSY
> >> set during a flush?".  This can be done with blkdebug suspend/resume,
> >> except that there is no way to call bdrv_debug_resume from QEMU.
> > 
> > That's exactly what I was talking about, suspending a request is taking
> > influence on its timing. I'm looking into this right now. (And it's not
> > just resume, bdrv_debug_suspend can't be called from QEMU either)
> It can be called from the rules file though, can't it?

No, you can only define ACTION_INJECT_ERROR and ACTION_SET_STATE from
the config file, but not ACTION_SUSPEND. Maybe we should add it, but it
would still require a manual resume.

So far all test cases suspend requests with explicit qemu-io commands.

> > In fact, I'm checking whether we can have a monitor command to issue
> > qemu-io commands, which will be more generally useful for test cases. We
> > just need to make obvious that it doesn't become an ABI. Maybe prefix it
> > with "__org.qemu.debug-" or something like that.
> Makes sense.  I'm not sure why you'd want to read or write from
> testcases, but bdrv_drain(_all) can also be useful from testcases.

I imagine writing could be very useful for block job test cases.


reply via email to

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