Re: [Qemu-devel] [PATCH] versatile: Push lsi initialization to the end

[Jan Kiszka]

On 2012-10-05 19:42, Peter Maydell wrote:
> On 5 October 2012 18:30, Jan Kiszka <address@hidden> wrote:
>> This is nasty, but there is no better way given current mux logic:
>>
>> As setting up the block device will trigger a qemu_bh_poll while there
>> are qemu_chr open events in the queue, we have to register the UARTs
>> and everything else that might be mux'ed first so that the right active
>> frontend is already registered when the bottom-half is finally
>> processed.
> 
> Yuck. I really don't like this -- why should the board model have
> to care about implementation internals of lsi53c895a? It's just
> plugging in a PCI card. And why only this device and not every
> storage device in every board?
> 
> Nothing should actually start happening until the whole machine model
> is completely set up and we've returned control to vl.c (and probably
> not until we've done our first system reset). Any device which is
> doing stuff early is broken and needs fixing.

Here is the backtrace that bites:

(gdb) bt
#0  qemu_bh_poll () at /data/qemu/async.c:56
#1  0x00005555555de819 in qemu_aio_wait () at /data/qemu/aio.c:118
#2  0x00005555555f6635 in bdrv_rw_co (bs=0x5555564cc140, sector_num=<optimized 
out>, buf=<optimized out>, nb_sectors=<optimized out>, is_write=<optimized 
out>) at /data/qemu/block.c:1819
#3  0x00005555555f6b1b in bdrv_read_unthrottled (bs=0x5555564cc140, 
sector_num=<optimized out>, buf=<optimized out>, nb_sectors=<optimized out>) at 
/data/qemu/block.c:1841
#4  0x0000555555637a8a in guess_disk_lchs (bs=0x5555564cc140, 
pcylinders=0x7fffffffd434, pheads=0x7fffffffd430, psectors=0x7fffffffd42c) at 
/data/qemu/hw/hd-geometry.c:68
#5  0x0000555555637c10 in hd_geometry_guess (bs=0x5555564cc140, 
pcyls=0x5555565dbbac, pheads=0x5555565dbbb0, psecs=0x5555565dbbb4, ptrans=0x0) 
at /data/qemu/hw/hd-geometry.c:125
#6  0x000055555562d0da in blkconf_geometry (conf=0x5555565dbb90, ptrans=0x0, 
cyls_max=65535, heads_max=255, secs_max=255) at /data/qemu/hw/block-common.c:43
#7  0x0000555555648dea in scsi_initfn (dev=0x5555565dbaf0) at 
/data/qemu/hw/scsi-disk.c:2061
#8  0x00005555556452e6 in scsi_device_init (s=0x5555565dbaf0) at 
/data/qemu/hw/scsi-bus.c:42
#9  scsi_qdev_init (qdev=<optimized out>) at /data/qemu/hw/scsi-bus.c:183
#10 0x0000555555641e7f in qdev_init (dev=0x5555565dbaf0) at 
/data/qemu/hw/qdev.c:160
#11 0x00005555556428c3 in scsi_bus_legacy_add_drive (bus=<optimized out>, 
bdrv=0x5555564cc140, unit=0, removable=false, bootindex=-1) at 
/data/qemu/hw/scsi-bus.c:228
#12 0x00005555556429d8 in scsi_bus_legacy_handle_cmdline (bus=0x5555565d92b8) 
at /data/qemu/hw/scsi-bus.c:246
#13 0x00005555556c1a46 in pci_qdev_init (qdev=0x5555565d8b00) at 
/data/qemu/hw/pci.c:1556
#14 0x0000555555641e7f in qdev_init (dev=0x5555565d8b00) at 
/data/qemu/hw/qdev.c:160
#15 0x0000555555641fd1 in qdev_init_nofail (dev=0x5555565d8b00) at 
/data/qemu/hw/qdev.c:261
#16 0x00005555556c25b8 in pci_create_simple_multifunction (bus=<optimized out>, 
devfn=<optimized out>, multifunction=<optimized out>, name=<optimized out>) at 
/data/qemu/hw/pci.c:1615
#17 0x0000555555808f44 in versatile_init (ram_size=134217728, 
boot_device=<optimized out>, 
    kernel_filename=0x5555564c9420 "zImage-qemuarm.bin", 
kernel_cmdline=0x5555558a0558 "", initrd_filename=0x0, 
    cpu_model=<optimized out>, board_id=387) at 
/data/qemu/hw/arm/../versatilepb.c:325
#18 0x0000555555809100 in vpb_init (ram_size=<optimized out>, 
boot_device=<optimized out>, kernel_filename=<optimized out>, 
kernel_cmdline=<optimized out>, initrd_filename=<optimized out>, 
    cpu_model=<optimized out>) at /data/qemu/hw/arm/../versatilepb.c:351
#19 0x000055555570bcc9 in main (argc=<optimized out>, argv=<optimized out>, 
envp=<optimized out>) at /data/qemu/vl.c:3627

There are earlier calls to qemu_bh_poll, but likely before chardev
creation.

I'm not a fan of this either, but the alternatives are way more
complicated. We either need to rewrite the chardev subsystem,
specifically how mux'ed devices are registered and how the active one is
selected. Or we need to avoid flushing "unrelated" BHs for block
devices. Not sure of those read requests can be postponed.

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SDP-DE
Corporate Competence Center Embedded Linux