From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Date: Tue, 01 Apr 2008 14:46:18 +0000 Subject: Re: [kvm-ppc-devel] [PATCH] kvm(ppc)-userspace: initialize Message-Id: <47F24ABA.3020404@us.ibm.com> List-Id: References: <47F225D2.9020409@linux.vnet.ibm.com> In-Reply-To: <47F225D2.9020409@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: kvm-ppc@vger.kernel.org Hollis Blanchard wrote: > On Tue, 2008-04-01 at 14:08 +0200, Christian Ehrhardt wrote: > >> FYI some output using virtio-block (still buggy on kvmppc) >> >> Initialization when booting guest (VIO = virtio drvier in guest, U-VIO = virtio emulation in host kvm userspace) >> >> PCI: Enabling device 0000:00:01.0 (0000 -> 0001) >> PCI: Enabling device 0000:00:02.0 (0000 -> 0001) >> U-VIO virtio_blk_update_config - vdev 0x10d0b008 >> VIO virtblk_probe - vdev 0xc8925200 >> U-VIO virtio_blk_get_features - vdev 0x10d0b008 >> U-VIO virtio_blk_get_features - vdev 0x10d0b008 >> U-VIO virtio_blk_get_features - vdev 0x10d0b008 >> blk_queue_max_hw_segments: set to minimum 1 >> vda:<3>VIO do_virtblk_request - request_queue 0xc8936000 >> VIO do_req - request_queue 0xc8936000 request 0xc8937320 virtio_blk 0xc880c000 (8secs@0x0 - Maj -929934324) >> U-VIO virtio_blk_handle_output - vdev 0x10d0b008 vq 0x10d0b20c >> VIO blk_done - vq 0xc88bcc00 >> VIO do_virtblk_request - request_queue 0xc8936000 >> >> >> >> We have no dynamic /dev so anyone who wants to test that will need to create /dev/vda for his needs. >> This is easy to check using /proc/partitions. >> Well I think that block size is broken here and using fdisk to check the partitions on that (unformatted) disk killed the guest kernel. >> This needs more debugging, but to enable it for our platform is the first step - comments are welcome. >> >> bash-3.00# cat /proc/partitions >> major minor #blocks name >> [...] >> 254 0 22517998136852480 vda <- ?broken? >> > > My guess is this is run-of-the-mill endianness mismatch. > 22517998136852480 = 0x00500000_00000000, which 64-bit byteswapped would > be 0x5000, and that's probably a reasonable number of 512-byte blocks. > Is your disk image 10MB? > > Why would we have a problem, since both guest and host are big-endian? > Because virtio is a PCI device, and PCI MMIO are LE, so > __virtio_config_val() in the guest is (correctly) using le64_to_cpu(). > > Why didn't we have problems with virtio-net? Because virtio-net doesn't > seem to have anything interesting in PCI config space. virtio-blk's > config space contains the capacity and a few other pieces of > information. > > The fix needs to be in qemu, and given the lack of qemu endianness > infrastructure, I'm afraid it will be a hack. See > http://svn.savannah.nongnu.org/viewvc/trunk/hw/e1000.c?root=qemu&r1@46&r2@45&pathrev@46 for reference. We all know that TARGET_WORDS_BIGENDIAN is totally wrong, but unfortunately it also seems to be the only (accidentally) working solution in qemu without major IO system rework. :( > > It's actually not so bad since the virtio config space is already read one byte at a time. The following should help. diff --git a/qemu/hw/virtio-blk.c b/qemu/hw/virtio-blk.c index 0f55d2a..492bd7f 100644 --- a/qemu/hw/virtio-blk.c +++ b/qemu/hw/virtio-blk.c @@ -134,8 +134,8 @@ static void virtio_blk_update_config(VirtIODevice *vdev, uin int64_t capacity; bdrv_get_geometry(s->bs, &capacity); - blkcfg.capacity = capacity; - blkcfg.seg_max = 128 - 2; + blkcfg.capacity = cpu_to_le64(capacity); + blkcfg.seg_max = cpu_to_le32(128 - 2); memcpy(config, &blkcfg, sizeof(blkcfg)); } ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ kvm-ppc-devel mailing list kvm-ppc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-ppc-devel