similar to: anyone willing to review a virtio-net guest driver for OVMF?

Patches before the last are small cleanups. In the last patch I'm trying to extract / generalize an idea from Stefan Hajnoczi's review of my virtio-net driver for OVMF. Unfortunately I can't find Stefan's email on any mailing list archive (sourceforge, gmane, mail-archive etc. all have only my response), so I'll quote it here. The patch Stefan was reviewing is

Patches before the last are small cleanups. In the last patch I'm trying to extract / generalize an idea from Stefan Hajnoczi's review of my virtio-net driver for OVMF. Unfortunately I can't find Stefan's email on any mailing list archive (sourceforge, gmane, mail-archive etc. all have only my response), so I'll quote it here. The patch Stefan was reviewing is

On Sat, Jun 8, 2013 at 7:39 PM, Laszlo Ersek <lersek at redhat.com> wrote: > Patches before the last are small cleanups. > > In the last patch I'm trying to extract / generalize an idea from Stefan > Hajnoczi's review of my virtio-net driver for OVMF. > > Unfortunately I can't find Stefan's email on any mailing list archive > (sourceforge, gmane,

Hello. I played with UEFI PXE booting the other day, and as usual, used qemu/kvm virtual machine for initial testing/debugging, because it is way easier and faster for this task than using a real hardware. However, it looks like either qemu or {pxe,sys}linux 6.03 is buggy, -- the two does not play well together. When booting, the system successfully loads syslinux.efi, at least the tftp server

Hi, "Appendix X: virtio-mmio" in the virtio spec says ? 0x040 | RW | QueuePFN [...] When the Guest stops using the queue it must write zero (0x0) to this register. [...] and Virtqueue Configuration [...] 2. Check if the queue is not already in use: read QueuePFN register, returned value should be zero (0x0). [...] I think this in itself is

Hi, "Appendix X: virtio-mmio" in the virtio spec says ? 0x040 | RW | QueuePFN [...] When the Guest stops using the queue it must write zero (0x0) to this register. [...] and Virtqueue Configuration [...] 2. Check if the queue is not already in use: read QueuePFN register, returned value should be zero (0x0). [...] I think this in itself is

Replying to http://www.syslinux.org/archives/2014-November/022804.html . After about half a year there's a solution to this problem, outlined here: http://lists.nongnu.org/archive/html/qemu-devel/2015-05/msg05348.html It looks like the bugs are in ipxe. The two patches for ipxe are now part of qemu source now so qemu should come with working ipxe roms which allows booting over network in

On Fri, Jul 21, 2017 at 06:17:15AM -0500, Brijesh Singh wrote: > > On 7/20/17 10:24 PM, Jason Wang wrote: > > > > > > On 2017?07?20? 06:09, Brijesh Singh wrote: > >> I have found that OVMF fails to detect the disk when iommu_platform > >> is set from > >> qemu cli. The failure occurs during the feature bit negotiation. > >> > >>

On Fri, Jul 21, 2017 at 06:17:15AM -0500, Brijesh Singh wrote: > > On 7/20/17 10:24 PM, Jason Wang wrote: > > > > > > On 2017?07?20? 06:09, Brijesh Singh wrote: > >> I have found that OVMF fails to detect the disk when iommu_platform > >> is set from > >> qemu cli. The failure occurs during the feature bit negotiation. > >> > >>

Hello all, hope all is well Was wondering if I'm doing something wrong/missing something. I have pxe+tftp+uefi working between 2 vms. However after the build is done and I reboot, I still come up to pxe b/c tianocore always starts, from what I've seen, with trying PXE first. Great for initial builds :) but I would like to it stop after. In the xml I am pointing to the disk to boot first.

Thanks VERY MUCH for all the info and help! Apologies for the extreme delay. I got distracted by other threads that forced out this work to later date. Also some frustration as well. ;) I completely missed this update. Apologies and thanks Will be diving back into this shortly! On Thu, Mar 24, 2016 at 3:57 PM, Laszlo Ersek <lersek@redhat.com> wrote: > On 03/21/16 19:53, jsl6uy js16uy

>>> Using VMware I built a test setup of a server with dhcp, tftp and a http-server and several pxe-clients with EFI mode turned on. This setup worked, albeit with the exponential-like decay of IO rate I described earlier. The work-around of using HTTP works beautifully though. <<< ""exponential-like decay of IO rate"" could you please post a link on

Hello dear list, Using VMware I built a test setup of a server with dhcp, tftp and a http-server and several pxe-clients with EFI mode turned on. This setup worked, albeit with the exponential-like decay of IO rate I described earlier. The work-around of using HTTP works beautifully though. So it was time for the next step. Migrate this setup to our automated testing environment that runs

On 04/07/15 19:22, BALATON Zoltan wrote: > Hello, > > I'm trying to find out how to pxe boot with syslinux.efi on QEMU with > OVMF. After getting through the initial hurdle caused by the iPXE based > option ROM included with QEMU having a problem as described in these > threads: > > http://www.syslinux.org/archives/2014-November/022804.html >

My apologies, I used Anthony's previous (now obsolete) email. Updated it now & keeping full context below. Sorry. On 10/22/13 19:49, Laszlo Ersek wrote: > Hi, > > "Appendix X: virtio-mmio" in the virtio spec says > > ? 0x040 | RW | QueuePFN > [...] When the Guest stops using the queue it must write zero > (0x0) to this register. >

Hello, I can't help with the problems on real hardware but have come across the qemu problems before and maybe I can give some hints on that. On Fri, 31 Jul 2015, Oscar Roozen via Syslinux wrote: > So it was time for the next step. Migrate this setup to our automated testing > environment that runs under qemu-kvm. For this I had to use OVMF so the nodes > would boot in EFI mode

Hello, I'm trying to find out how to pxe boot with syslinux.efi on QEMU with OVMF. After getting through the initial hurdle caused by the iPXE based option ROM included with QEMU having a problem as described in these threads: http://www.syslinux.org/archives/2014-November/022804.html http://sourceforge.net/p/edk2/mailman/message/33236100/ I'm now getting further to almost being able

Hi Would just like to know if any others are experiencing slow loading of HVM domains with OVMF bios. On my system it can take up to 5 min from the xl create command until the DomU shows the Tianocore screen. Is this normal behavior or is there something wrong with my build? Best regards Kristian _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org

On Tue, 7 Apr 2015, Laszlo Ersek wrote: > Whereas syslinux.efi apparently uses the embedded gpxe/ tree, and that > one uses TCP timestamps. See tcp_xmit() in gpxe/src/net/tcp.c: Actually syslinux.efi seems to be using the implementation calling into UEFI via these functions: http://git.kernel.org/cgit/boot/syslinux/syslinux.git/tree/efi/tcp.c I've tried to add debug messages to these

Stefan Hajnoczi <stefanha at gmail.com> writes: > On Sat, Jun 8, 2013 at 7:39 PM, Laszlo Ersek <lersek at redhat.com> wrote: >> Patches before the last are small cleanups. >> >> In the last patch I'm trying to extract / generalize an idea from Stefan >> Hajnoczi's review of my virtio-net driver for OVMF. How about a single patch which just replaces