[Qemu-devel] virtio-net regression [was: syslinux vs. OVMF]

[Laszlo Ersek]

On 04/10/15 12:06, Laszlo Ersek wrote:
> On 04/10/15 10:14, Gerd Hoffmann wrote:
>>   Hi,
>>
>>> In summary, please ask Gerd to rebuild the ipxe binaries that are
>>> bundled with upstream qemu such that they include those two iPXE patches
>>> of ours (see the last reference).
>>
>> https://www.kraxel.org/cgit/qemu/log/?h=rebase/roms-next
>>
>> Can you give this a try?
> 
> Thank you for this update, I tested it.
> 
> (1) I reproduced the issue, so that I could be sure that the fix wasn't
> meaningless. Indeed the bug reproduces with the iPXE binaries bundled
> with upstream qemu.
> 
> I then checked out, built and installed your branch, and tried again,
> with virtio-net and then e1000.
> 
> (2) Virito-net results:
> - OVMF        loads shim.efi    via network
> - shim.efi    loads grubx64.efi via network
> - grubx64.efi loads grub.cfg    via network
> - grubx64.efi loads vmlinuz     via network
> 
> However, while grubx64.efi loads initrd.img via the network, qemu
> crashes the guest, with the following message:
> 
> qemu-system-x86_64: Guest moved used index from 46499 to 65534
> 
> This is a virtio protocol bug in the guest (efi-virtio.rom), *or* in
> QEMU. I don't know.
> 
> * e1000 results:
> - OVMF        loads shim.efi    via network
> - shim.efi    loads grubx64.efi via network
> - grubx64.efi loads grub.cfg    via network
> - grubx64.efi loads vmlinuz     via network
> - grubx64.efi loads initrd.img  via network
> - guest kernel boots
> 
> So, I think the update is fine in general; but maybe there's a new
> virtio-related bug in either "efi-virtio.rom" or in QEMU.
> 
> (When I originally wrote the (earlier versions of the) patches, I tested
> them with virtio-net using RHEL-7 qemu, so I guess this could be an
> upstream QEMU regression. The machine type I used for testing was
> pc-i440fx-2.3.)
> 
> (3) ... Confirmed, this is a qemu regression. Namely, I checked your new
> efi-virtio.rom with RHEL-7 qemu, and it works fine. CC'ing qemu-devel.

Small update, before I start bisecting it: the bug does not reproduce
with "-netdev bridge".

It seems to be specific to "-netdev tap". Further, "vhost=on" seems to
play no role, "-netdev tap" reproduces the error both with and without
vhost=on.

Thanks
Laszlo