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

[Anthony Liguori <aliguori@us.ibm.com>]

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 - <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. :(
>
>   

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