From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hollis Blanchard Date: Tue, 01 Apr 2008 14:33:50 +0000 Subject: Re: [kvm-ppc-devel] [PATCH] kvm(ppc)-userspace: Message-Id: <1207060430.6214.12.camel@basalt> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: kvm-ppc@vger.kernel.org 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. :( -- Hollis Blanchard IBM Linux Technology Center ------------------------------------------------------------------------- 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