Re: [Qemu-devel] [PATCH] Disable AIO for Mac OS X

[Anthony Liguori <anthony@codemonkey.ws>]

Alexander Graf wrote:
>
> On 24.01.2009, at 22:25, Anthony Liguori wrote:
>
>> Alexander Graf wrote:
>>>
>>> On 24.01.2009, at 21:53, Anthony Liguori wrote:
>>>
>>>> Alexander Graf wrote:
>>>>>
>>>>> On 24.01.2009, at 21:28, Anthony Liguori wrote:
>>>>>
>>>>>> Alexander Graf wrote:
>>>>>>> While trying current svn, it looks like AIO support compiles on
>>>>>>> Mac OS X finally. Unfortunately it is broken and as soon as I want
>>>>>>> to run any image, it endless loops in block.c:1446 which is:
>>>>>>>
>>>>>>>  while (async_ret == NOT_DONE) {
>>>>>>>      qemu_aio_wait();
>>>>>>>  }
>>>>>>>
>>>>>>
>>>>>> Are you using cocoa?
>>>>>
>>>>> Yep. Nothing else works for x86_64 on Mac OS X ;-). Well - except 
>>>>> for vnc.
>>>>>
>>>>>> I don't think the AIO code is broken here.  I think something 
>>>>>> else is broken and disabling AIO hides the symptom.  Can you dig 
>>>>>> more into this?
>>>>>
>>>>> Hum - sounds like an idea. I'm open for hints on how to dig in 
>>>>> here. I can disable cocoa for starters of course.
>>>>
>>>> My guess would be that the completion signal isn't being 
>>>> delivered.  I'd start by disabling cocoa and then annotate things 
>>>> to see if the completion signal every makes it to the aio system.
>>>
>>> So disabling cocoa doesn't really help. I recompiled with cocoa=no 
>>> and still have the same issue:
>>>
>>> (gdb) thread apply all bt
>>>
>>> Thread 1 (process 38766 thread 0x10b):
>>> #0  0x91b846f2 in select$DARWIN_EXTSN ()
>>> #1  0x00081526 in qemu_aio_wait () at aio.c:158
>>> #2  0x00081055 in bdrv_read_em (bs=0x4, sector_num=0, buf=0x4 
>>> <Address 0x4 out of bounds>, nb_sectors=4) at block.c:1447
>>> #3  0x0007fb29 in bdrv_guess_geometry (bs=0x806a00, 
>>> pcyls=0xbfffdfcc, pheads=0xbfffdfc8, psecs=0xbfffdfc4) at block.c:773
>>> #4  0x0002a398 in ide_init2 (ide_state=<value temporarily 
>>> unavailable, due to optimizations>, hd0=0x806a00, hd1=0x0, 
>>> irq=0x402a18) at /Users/alex/work/qemu-osx/qemu/hw/ide.c:2844
>>> #5  0x0002b08d in pci_piix3_ide_init (bus=0x4, hd_table=0xbfffeaf0, 
>>> devfn=4, pic=0x402930) at /Users/alex/work/qemu-osx/qemu/hw/ide.c:3435
>>> #6  0x000442f9 in pc_init1 (ram_size=<value temporarily unavailable, 
>>> due to optimizations>, vga_ram_size=8388608, boot_device=0x11da16 
>>> "cad", kernel_filename=0x0, kernel_cmdline=0x11d40c "", 
>>> initrd_filename=0x0, pci_enabled=1, cpu_model=0x0) at 
>>> /Users/alex/work/qemu-osx/qemu/hw/pc.c:1027
>>> #7  0x000068d1 in main (argc=5, argv=0xbffff360, envp=0xbffff378) at 
>>> /Users/alex/work/qemu-osx/qemu/vl.c:5520
>>>
>>> It's actually hanging in its first select() call.
>>
>> Is posix-aio init getting called?
>
> Yes, several times:
>
> haruka:qemu alex$ ./i386-softmmu/qemu -vnc :0 -snapshot 
> ~/Downloads/worms/worms-united.qcow2
> posix_aio_init
> AIO rd = 5
> AIO wr= 6
> posix_aio_init
> posix_aio_init
> posix_aio_init
> posix_aio_init
> posix_aio_init
> add rd(5)...
> selecting...
>
>
>>  What is being passed to select?
>
> The AIO rd fd.
>
>>  It's waiting for the signalfd to become readable and it's never 
>> becoming readable.  That could be because you never get the 
>> completion signal.
>
> So who sends the signal?

posix-aio-compat.c:aio_thread() ... kill(getpid(), )

I'd add a printf to see if the signal is getting sent (means op has 
completed) and then another one in 
block-raw-posix.c:aio_signal_handler() to see if we're receiving the signal.

If for some crazy reason the OS X port spawns another thread somewhere 
without masking SIGUSR2 correctly, it could be that the signal is 
getting lost.

Regards,

Anthony Liguori

>> FWIW, at this point, we could drop the signal entirely and just use a 
>> pipe for communication.  Right now we use a signal that we catch and 
>> then write to a pipe from the signal handler.  We did this because 
>> that's how posix-aio worked but since we don't use posix-aio anymore, 
>> we're no longer limited by that.
>
> Hum - sounds like more effort and more probable breakage than tracking 
> this down ;-).

> Alex