On Mon, Sep 13, 2010 at 04:25:13PM +0200, Dhaval Giani wrote: > (BTW, this is a regression from 2.6.35 at least. I will try to figure > out the last working version if you would like a bisect!) Sure, that's helpful. BTW, does latest upstream qemu-kvm have this issue as well for you? > On Sun, Sep 12, 2010 at 4:40 PM, Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > > On Sun, Sep 12, 2010 at 04:39:29PM +0200, Dhaval Giani wrote: > >> On Sun, Sep 12, 2010 at 2:05 PM, Michael S. Tsirkin <mst@xxxxxxxxxx> wrote: > >> > On Fri, Sep 10, 2010 at 03:37:36PM +0200, Dhaval Giani wrote: > >> >> Hi, > >> >> > >> >> I have been trying to get vhost+macvtap to work for me. I run it as > >> >> > >> >> /root/qemu-kvm-vhost-net/bin/qemu-system-x86_64 -hda $IMAGE -serial > >> >> stdio -monitor telnet::4444,server,nowait -vnc :4: -m 3G -net > >> >> nic,model=virtio,macaddr=$MACADDR,netdev=macvtap0 -netdev > >> >> tap,id=macvtap0,vhost=on,fd=3 3<> /dev/tap5 > >> >> > >> >> in 2.6.35, which worked just fine. On the other hand, with 2.6.36, i > >> >> don't have working networking. I am using the same image and same > >> >> macaddress. The qemu is the version from > >> >> git://git.kernel.org/pub/scm/linux/kernel/git/mst/qemu-kvm.git vhost . > >> > > >> > BTW, by now, all these patches are merged so upstream qemu-kvm should work > >> > just fine for you as well. > >> > > >> >> Any suggestions will be welcome! > >> >> > >> >> Thanks, > >> >> Dhaval > >> > > >> > You are running this as non-root user, correct? > >> > >> nope as root. > >> > >> > This could be the permission issue that got fixed > >> > by 87d6a412bd1ed82c14cabd4b408003b23bbd2880. > >> > Could you please check the latest master from Linus, > >> > and let me and the list know? Thanks! > >> > > >> > >> this is with git of friday evening CEST. > >> > >> > Another thing to try if this does *not* help: > >> > > >> > enable CONFIG_DYNAMIC_DEBUG in kernel, > >> > rebuild the kernel, > >> > mount debugfs: > >> > > >> > mount -t debugfs none /sys/kernel/debug > >> > > >> > and then enable debug for vhost_net as described in > >> > Documentation/dynamic-debug-howto.txt: > >> > > >> > >> I will give this a run on monday morning when i am at the lab again. > >> > > So nothing comes out with this. > > >> > echo 'module vhost_net +p' > /sys/kernel/debug/dynamic_debug/control > >> > > >> > Then start qemu, and after running a test, run dmesg and see if there > >> > are any messages from vhost_net. If yes please send them to > >> > me and to the list. > >> > > >> > Thanks! > >> > > >> > >> > >> thanks! > >> Dhaval > > > > Another thing to try check is generic net core issues. > > > > For this, try running tcpdump on both tap in host > > and on virtio net device in guest. Then > > send packets to host from guest and back, and check whether > > they appears on virtio and on tap. > > > > tcpdump -i macvtap0 on the host leads to nothing. > > tcpdump -i eth0 on the guest leads to ARP requests, with no responses. > > Anything more I can try? > > Thanks! > Dhaval So nothing is passed to tap, but no errors either. It might be helpful to enable function tracer and trace functions in our module. Alternatively, let's see if we get anything from the ring (don't forget to unload and reload vhost-net). diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c index 29e850a..6400cd5 100644 --- a/drivers/vhost/net.c +++ b/drivers/vhost/net.c @@ -152,6 +152,8 @@ static void handle_tx(struct vhost_net *net) ARRAY_SIZE(vq->iov), &out, &in, NULL, NULL); + printk(KERN_ERR "vhost_get_vq_desc returned %d\n", head); + /* On error, stop handling until the next kick. */ if (unlikely(head < 0)) break; -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
