After seeing that the older version fixed the problem for John and checking my archive of OVMF builds. I conclude that there is a upstream regression that manifest first in versions between edk2.git-ovmf-x64-0-20160323.b1631.ga7b1590.noarch.rpm and edk2.git-ovmf-x64-0-20160419.b1737.gc4cc609.noarch.rpm, then gets worse at newer versions. (Unless it is two issues, the first only responsible for approx. 5 sec boot delay)
Timing form pressing Power-On in Virt-manager to the circle under win 10 logo shows: edk2.git-ovmf-x64-0-20160323.b1631.ga7b1590.noarch.rpm: 18 sec edk2.git-ovmf-x64-0-20160324.b1635.gf0bbcdf.noarch.rpm: 20 sec edk2.git-ovmf-x64-0-20160419.b1737.gc4cc609.noarch.rpm: 25 sec edk2.git-ovmf-x64-0-20160829.b2090.g5f53a7a.noarch.rpm: 87 sec Also edk2.git-ovmf-x64-0-20160510.b1805.g05b2f9c.noarch.rpm hangs with no-cpu-usage, and edk2.git-ovmf-x64-0-20160829.b2090.g5f53a7a.noarch.rpm is the first version with cpu at 100% until windows starts booting. 2017-07-26 0:49 GMT+01:00, Blair Bethwaite <blair.bethwa...@gmail.com>: > Is there an upstream OVMF bug for the root cause or is it still unknown? > > On 26 Jul. 2017 08:41, "John Koelndorfer" <jkoelndor...@gmail.com> wrote: > >> Good news, folks! >> >> Hagbard was kind enough to send an older build of OVMF he had lying >> around >> and suggested I try it. I did, and I am happy to report my VM boots very >> fast again! For safekeeping, I have committed it to my GitHub repository: >> https://github.com/jkoelndorfer/local-tools/blob/ >> master/workstation/vfio/edk2.git-ovmf-x64-0-20150804.b1143. >> g8ca1489.noarch.rpm. I believe that when I did my initial VFIO setup, I >> used a package from the AUR which may have been just old enough to avoid >> the problem. >> >> I may experiment some and see if any of the qemu parameters provided by >> Hristo make a difference with a current version of OVMF. For now, I'm >> happy >> my VM is booting quickly. >> >> Thanks very much for your help. >> >> On Mon, Jul 24, 2017 at 7:22 PM, John Koelndorfer >> <jkoelndor...@gmail.com> >> wrote: >> >>> An update: >>> >>> The slow boot does not occur if I remove host devices from the virtual >>> machine (without any other configuration changes). It doesn't matter >>> whether GPU, USB, or both are passed in. Any device being passed in at >>> all >>> triggers the problem, so it's something related to the physical device >>> passthrough I think. >>> >>> An older version of OVMF did not help, nor did booting a non-Windows OS. >>> I tried two alternate versions of OVMF from here: >>> https://www.rpmfind.net/linux/rpm2html/search.php?query=edk2-ovmf. One >>> from 2016 November, one from 2016 April. I initially did my last VFIO >>> setup >>> in 2016 July. >>> >>> I also tried the pc-i440fx machine, per Hristo's suggestion (though I >>> tried 2.6, which was what my last configuration used). >>> >>> Hristo, it seems your setup is very similar to mine, so I have a few >>> questions for you: >>> >>> * Are you using libvirt? >>> * Could you send the qemu arguments for your VM? >>> * What are your kernel boot parameters? >>> >>> My suspicion now is that libvirt is doing some extra configuration that >>> I'm not. I looked at my old libvirt XML file and nothing is jumping out >>> at >>> me, so maybe it's a hardcoded default behavior. >>> >>> Thanks for all the suggestions so far, folks. >>> >>> On Mon, Jul 24, 2017 at 4:03 PM, Hagbard Celine <hagbardce...@gmail.com> >>> wrote: >>> >>>> Hi, just registered to the list to share my experience on this; >>>> >>>> I've been getting my OVMF builds from kraxel.org since >>>> edk2.git-ovmf-x64-0-20150804.b1143.g8ca1489.noarch.rpm and was >>>> regularly updating when new builds came. >>>> Somwhere around edk2.git-ovmf-x64-0-20151221.b1390.g5ba9f06.noarch.rpm >>>> boot with large amounts of memory got slower. >>>> And around edk2.git-ovmf-x64-0-20160324.b1634.g3decba3.noarch.rpm the >>>> EFI part of boot could last about 15min with 16GB assigned to VM out >>>> of a total of 32GB. Lovering the assigned memory for VM to below 8GB >>>> resulted in normal boot times. >>>> >>>> PS. The version numbers are approximations, my recollection is not >>>> exact. >>>> >>>> _______________________________________________ >>>> vfio-users mailing list >>>> vfio-users@redhat.com >>>> https://www.redhat.com/mailman/listinfo/vfio-users >>>> >>> >>> >> >> _______________________________________________ >> vfio-users mailing list >> vfio-users@redhat.com >> https://www.redhat.com/mailman/listinfo/vfio-users >> >> > _______________________________________________ vfio-users mailing list vfio-users@redhat.com https://www.redhat.com/mailman/listinfo/vfio-users
