[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] virtio-net regression [was: syslinux vs. OVMF]
From: |
Laszlo Ersek |
Subject: |
[Qemu-devel] virtio-net regression [was: syslinux vs. OVMF] |
Date: |
Fri, 10 Apr 2015 13:04:39 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 |
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