On Mon, Jan 2, 2012 at 5:19 AM, Ying-Shiuan Pan
<yingshiuan....@gmail.com> wrote:
> 2011/12/30 Stefan Hajnoczi <stefa...@gmail.com>
>>
>> On Wed, Dec 28, 2011 at 06:16:42PM +0800, Ying-Shiuan Pan wrote:
>> > I'm very interested in virtio-mmio Peter Maydell did for QEMU,
>> > (http://lists.nongnu.org/archive/html/qemu-devel/2011-11/msg01870.html)
>> >
>> > actually, I've tested the virtio-blk, and it is working.
>> > I applied those patch to QEMU-1.0 and brought the virtio_mmio.c from
>> > Linux-3.2-rc back to Linux-linaro-2.6.38.
>> >
>> > I also found a small bug in virito-mmio.c: virtio_mmio_write(),
>> > Peter forgot to break in each case of switch block.
>> > After fixed the small bug, the virtio-balloon works as well.
>>
>> PMM: Do you have a git branch where you could apply Ying-Shiuan's fix?
> hmm... I've sent Peter my patch :)
>>
>> > Then, when I attempted to enable the virtio-net, the initialization part is
>> > fine,
>> > however, the QEMU crashed and printed this message:
>> > "virtio-net header not in first element"
>> >
>> > It happens when the front-end virtio-net is invoking virtqueue_kick() at
>> > the end of try_fill_recv().
>> > Then, QEMU gets this message and invokes virtio_net_receive(), then the
>> > error happens.
>>
>> virtio-net is looking at a virtqueue element (a packet buffer provided
>> by the guest OS into which QEMU will copy the received packet) but the
>> virtqueue element does not have the expected format. You can check the
>> virtio specification for the details on the virtio-net buffer layout:
>> http://ozlabs.org/~rusty/virtio-spec/
>>
>> It sounds like the vring is corrupted or QEMU's virtio code is not
>> correctly reading the virtqueue element (which is basically an iovec
>> array).
>>
>> virtio-net is more advanced than virtio-blk in how it uses virtio so
>> it's not surprising that you've discovered an issue. Debugging this
>> comes down to looking at the vring descriptors and the virtqueue
>> elements that QEMU extracts.
>>
>> It sounds like there's a problem with the rx queue, you could try
>> indirect_desc=off to disable indirect vring descriptors to see if that
>> is part of the problem.
>>
>> Stefan
> I guessed that the problem was in adding header,
> virtio-net should insert its header to the ring buffer before its
> packet, correct me if I'm wrong.
>
> virtio-net driver (backend part) can use add_recvbuf_small() /
> add_recvbuf_big() / add_recvbuf_mergeable()
> depending on what features the virtio-net device (QEMU part) provides.
> I found that both small and big add the header, while the mergeable
> one does not.
> Besides, in that add_recvbuf_big(), the comments mentioned about a QEMU bug??
>
> Anyway, I found a workaround solution, that is disable the
> VIRTIO_NET_F_MRG_RXBUF feature
> and make virtio-net driver use add_recvbuf_big()
>
> However, I am still not clear about how the problem happened.
Can you confirm which "virtio-net header not in first element" error
is occurring? There are two instances in qemu/hw/virtio-net.c:
virtio_net_receive() and virtio_net_flush_tx().
If you are really seeing the error from virtio_net_receive() then
feature negotiation is broken. The guest will advertise mergeable
receive buffers and the host (QEMU) should detect this in
virtio_net_set_features(). This causes QEMU to set
VirtIONet->mergeable_rx_bufs to true.
If VirtIONet->mergeable_rx_bufs is true then the error you are seeing
in virtio_net_receive() cannot happen:
if (!n->mergeable_rx_bufs && elem.in_sg[0].iov_len != guest_hdr_len) {
error_report("virtio-net header not in first element");
exit(1);
}
The only explanation is that the guest and host did not negotiate the
mergeable receive buffers feature properly. That could mean Peter's
QEMU patches are not calling invoking virtio_net_set_features() at the
appropriate time or something else is broken - probably a virtio-mmio
issue.
AFAIK mergeable receive buffers are used by default and work correctly
under virtio-pci.
If you can debug this a little more we'll figure out what the problem is.
Stefan
