[Top][All Lists]

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

Re: [Qemu-devel] [RFC] block: Removed coroutine ownership assumption

From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [RFC] block: Removed coroutine ownership assumption
Date: Thu, 28 Jun 2012 14:03:54 +0100

On Thu, Jun 28, 2012 at 4:17 AM, Peter Crosthwaite
<address@hidden> wrote:
>>> not at a valid yield point. But whats really wrong here is the block
>>> layer will be making assumption on re-entry of the coroutine, so I
>>> cant re-enter it witout wildly changing the behaviour of the block
>>> layer. If you adopt this "mark it as coroutine" poilcy, you end up
>>> with a system where half the functions in QEMU:
>>> A: may yield your coroutine
>>> B: if it does yield it, your not allowed to restart it
>>> Making them completely uncallable from coroutine context.
>> Please link to real code, I'm having trouble understanding the example
>> code and your argument.
> Hi Stefan,
> Please see:
> git://developer.petalogix.com/public/qemu.git for-stefan/fdt-generic.next
> Its a generic machine model that creates an arbitrary machine from a
> dtb. Yes, the work has many issues, some already discussed on the
> mailing list, but it illustrates the issue with block. Top commit I
> add some comments re this discussion. git diff HEAD^ will show you
> where to look in the code.

Thanks, that is very useful.

Why are you using coroutines to build the machine?  I think the answer
is because you are trying to do parallel init with a wait when a
dependency is hit.

The problem I see is:

FDTMachineInfo *fdt_generic_create_machine()
    while (qemu_co_queue_enter_next(fdti->cq));

The problem you have is not that the block layer is yielding.  The
problem is that you need to run aio processing (i.e. the main loop) in
order for that bdrv_read() to make progress.  Please try:

while (qemu_co_queue_enter_next(fdti->cq)) {


reply via email to

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