From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:53254) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TKCDO-0008Ao-FG for qemu-devel@nongnu.org; Fri, 05 Oct 2012 14:01:35 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TKCDN-0001pc-0E for qemu-devel@nongnu.org; Fri, 05 Oct 2012 14:01:34 -0400 Received: from david.siemens.de ([192.35.17.14]:29317) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TKCDM-0001pT-Mo for qemu-devel@nongnu.org; Fri, 05 Oct 2012 14:01:32 -0400 Message-ID: <506F207A.70805@siemens.com> Date: Fri, 05 Oct 2012 20:01:30 +0200 From: Jan Kiszka MIME-Version: 1.0 References: <506F1934.5000002@siemens.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] versatile: Push lsi initialization to the end List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: qemu-devel On 2012-10-05 19:42, Peter Maydell wrote: > On 5 October 2012 18:30, Jan Kiszka 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=, buf=, nb_sectors=, is_write=) at /data/qemu/block.c:1819 #3 0x00005555555f6b1b in bdrv_read_unthrottled (bs=0x5555564cc140, sector_num=, buf=, nb_sectors=) 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=) 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=, 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=, devfn=, multifunction=, name=) at /data/qemu/hw/pci.c:1615 #17 0x0000555555808f44 in versatile_init (ram_size=134217728, boot_device=, kernel_filename=0x5555564c9420 "zImage-qemuarm.bin", kernel_cmdline=0x5555558a0558 "", initrd_filename=0x0, cpu_model=, board_id=387) at /data/qemu/hw/arm/../versatilepb.c:325 #18 0x0000555555809100 in vpb_init (ram_size=, boot_device=, kernel_filename=, kernel_cmdline=, initrd_filename=, cpu_model=) at /data/qemu/hw/arm/../versatilepb.c:351 #19 0x000055555570bcc9 in main (argc=, argv=, envp=) 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