qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] vhost-net issue: does not survive reboot on ppc64


From: Alexey Kardashevskiy
Subject: Re: [Qemu-devel] vhost-net issue: does not survive reboot on ppc64
Date: Mon, 23 Dec 2013 01:46:25 +1100
User-agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0

On 12/22/2013 09:56 PM, Michael S. Tsirkin wrote:
> On Sun, Dec 22, 2013 at 02:01:23AM +1100, Alexey Kardashevskiy wrote:
>> Hi!
>>
>> I am having a problem with virtio-net + vhost on POWER7 machine - it does
>> not survive reboot of the guest.
>>
>> Steps to reproduce:
>> 1. boot the guest
>> 2. configure eth0 and do ping - everything works
>> 3. reboot the guest (i.e. type "reboot")
>> 4. when it is booted, eth0 can be configured but will not work at all.
>>
>> The test is:
>> ifconfig eth0 172.20.1.2 up
>> ping 172.20.1.23
>>
>> If to run tcpdump on the host's "tap-id3" interface, it shows no trafic
>> coming from the guest. If to compare how it works before and after reboot,
>> I can see the guest doing an ARP request for 172.20.1.23 and receives the
>> response and it does the same after reboot but the answer does not come.
> 
> So you see the arp packet in guest but not in host?

Yes.


> One thing to try is to boot debug kernel - where pr_debug is
> enabled - then you might see some errors in the kernel log.

Tried and added lot more debug printk myself, not clear at all what is
happening there.

One more hint - if I boot the guest and the guest does not bring eth0 up
AND wait more than 200 seconds (and less than 210 seconds), then eth0 will
not work at all. I.e. this script produces not-working-eth0:


ifconfig eth0 172.20.1.2 down
sleep 210
ifconfig eth0 172.20.1.2 up
ping 172.20.1.23

s/210/200/ - and it starts working. No reboot is required to reproduce.

No "vhost" == always works. The only difference I can see here is vhost's
thread which may get suspended if not used for a while after the start and
does not wake up but this is almost a blind guess.



>> If to remove vhost=on, it is all good. If to try Fedora19
>> (v3.10-something), it all good again - works before and after reboot.
>>
>>
>> And there 2 questions:
>>
>> 1. does anybody have any clue what might go wrong after reboot?
>>
>> 2. Is there any good material to read about what exactly and how vhost
>> accelerates?
>>
>> My understanding is that packets from the guest to the real network are
>> going as:
>> 1. guest's virtio-pci-net does ioport(VIRTIO_PCI_QUEUE_NOTIFY)
>> 2. QEMU's net/virtio-net.c calls qemu_net_queue_deliver()
>> 3. QEMU's net/tap.c calls tap_write_packet() and this is how the host knows
>> that there is a new packet.


What about the documentation? :) or the idea?


>>
>>
>> Thanks!
>>
>>
>> This how I run QEMU:
>> ./qemu-system-ppc64 \
>> -enable-kvm \
>> -m 2048 \
>> -machine pseries \
>> -initrd 1.cpio \
>> -kernel vml312_virtio_net_dbg \
>> -nographic \
>> -vga none \
>> -netdev
>> tap,id=id3,ifname=tap-id3,script=ifup.sh,downscript=ifdown.sh,vhost=on \
>> -device virtio-net-pci,id=id4,netdev=id3,mac=C0:41:49:4b:00:00
>>
>>
>> That is bridge config:
>> address@hidden ~]$ brctl show
>> bridge name  bridge id               STP enabled     interfaces
>> brtest               8000.00145e992e88       no      pin     eth4
>>
>>
>> The ifup.sh script:
>> ifconfig $1 hw ether ee:01:02:03:04:05
>> /sbin/ifconfig $1 up
>> /usr/sbin/brctl addif brtest $1


-- 
Alexey



reply via email to

[Prev in Thread] Current Thread [Next in Thread]