Re: [kvm-ppc-devel] [PATCH] kvm(ppc)-userspace:

[Hollis Blanchard <hollisb@us.ibm.com>]

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 - <NULL> 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