qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v2 4/7] block: take lock around bdrv_read implem


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH v2 4/7] block: take lock around bdrv_read implementations
Date: Sun, 06 Nov 2011 19:29:03 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110927 Thunderbird/7.0

On 11/06/2011 07:25 PM, Paolo Bonzini wrote:
> On 11/06/2011 03:27 PM, Avi Kivity wrote:
>> On 10/20/2011 01:16 PM, Paolo Bonzini wrote:
>>> This does the first part of the conversion to coroutines, by
>>> wrapping bdrv_read implementations to take the read side of the
>>> rwlock.
>>>
>>> Drivers that implement bdrv_read rather than bdrv_co_readv can
>>> then benefit from asynchronous operation (at least if the underlying
>>> protocol supports it, which is not the case for raw-win32), even
>>> though they still operate with a bounce buffer.
>>>
>>> raw-win32 does not need the lock, because it cannot yield.
>>> nbd also doesn't probably, but better be safe.
>>
>> This patch (2914caa088e3fbbd) breaks autotest when a guest reboots after
>> install; instead of rebooting, the guest is stuck in the bootloader or
>> kernel.
>
> Are any of these formats used by autotest?
>

It's configurable; in my case, qcow2.

>  block/bochs.c     |   13 ++++++++++++-
>  block/cloop.c     |   13 ++++++++++++-
>  block/cow.c       |   13 ++++++++++++-
>  block/dmg.c       |   13 ++++++++++++-
>  block/nbd.c       |   13 ++++++++++++-
>  block/parallels.c |   13 ++++++++++++-
>  block/vmdk.c      |   13 ++++++++++++-
>  block/vpc.c       |   13 ++++++++++++-
>  block/vvfat.c     |   13 ++++++++++++-
>  9 files changed, 108 insertions(+), 9 deletions(-)
>

So no.

> Perhaps the failure is only reproduced 80-90% of the time and this
> screws up the bisection.

I thought I checked the before/after commit, but looking at the
diffstat, that's doesn't make sense.

On a related note, booting with -cdrom http://blah seems broken.

-- 
error compiling committee.c: too many arguments to function




reply via email to

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