Re: [RFC PATCH]vhost-blk: In-kernel accelerator for virtio block device

[Badari Pulavarty <pbadari@us.ibm.com>]

On 8/10/2011 8:19 PM, Liu Yuan wrote:
> On 08/11/2011 11:01 AM, Liu Yuan wrote:
>>
>>> It looks like the patch wouldn't work for testing multiple devices.
>>>
>>> vhost_blk_open() does
>>> +       used_info_cachep = KMEM_CACHE(used_info, SLAB_HWCACHE_ALIGN |
>>> SLAB_PANIC);
>>>
>>
>> This is weird. how do you open multiple device?I just opened the 
>> device with following command:
>>
>> -drive file=/dev/sda6,if=virtio,cache=none,aio=native -drive 
>> file=~/data0.img,if=virtio,cache=none,aio=native -drive 
>> file=~/data1.img,if=virtio,cache=none,aio=native
>>
>> And I didn't meet any problem.
>>
>> this would tell qemu to open three devices, and pass three FDs to 
>> three instances of vhost_blk module.
>> So KMEM_CACHE() is okay in vhost_blk_open().
>>
>
> Oh, you are right. KMEM_CACHE() is in the wrong place. it is three 
> instances vhost worker threads created. Hmmm, but I didn't meet any 
> problem when opening it and running it. So strange. I'll go to figure 
> it out.
>
>>> When opening second device, we get panic since used_info_cachep is
>>> already created. Just to make progress I moved this call to
>>> vhost_blk_init().
>>>
>>> I don't see any host panics now. With single block device (dd),
>>> it seems to work fine. But when I start testing multiple block
>>> devices I quickly run into hangs in the guest. I see following
>>> messages in the guest from virtio_ring.c:
>>>
>>> virtio_blk virtio2: requests: id 0 is not a head !
>>> virtio_blk virtio1: requests: id 0 is not a head !
>>> virtio_blk virtio4: requests: id 1 is not a head !
>>> virtio_blk virtio3: requests: id 39 is not a head !
>>>
>>> Thanks,
>>> Badari
>>>
>>>
>>
>> vq->data[] is initialized by guest virtio-blk driver and vhost_blk is 
>> unware of it. it looks like used ID passed
>> over by vhost_blk to guest virtio_blk is wrong, but, it should not 
>> happen. :|
>>
>> And I can't reproduce this on my laptop. :(

I spent lot time looking at the code on how we can pass the wrong ID and 
corrupt vq->data[]. I can't seem
to spot the bug :(

I hacked vhost_blk to return success immediately, without doing any IO - 
to see if its a generic problem.
With the hack (of not doing any IO), I can't reproduce the problem. So, 
its some thing in the IO completion
handling code causing this. I will keep looking..

Thanks,
Badari


Thanks,
Badari