[Qemu-devel] Re: Regression due to "Fall back to network boot..."

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 1635 bytes --]

Anthony Liguori wrote:
> Jan Kiszka wrote:
>> Anthony Liguori wrote:
>>  
>>> Jan Kiszka wrote:
>>>    
>>>> OK, thanks. Still one complaint: gPXE comes with an annoying boot delay
>>>> even if you can boot from disk or have _explicitly_ specified this. I'm
>>>> not familiar with it, but I bet there is some magic config switch to
>>>> disable this...
>>>>         
>>> Nothing seemed obvious to me.  If anyone has ideas/patches I'm all
>>> for it.
>>>     
>>
>> Found it: BANNER_TIMEOUT=0.
>>   
> 
> But it's not a tunable and I was hoping to not have to pull gpxe into
> the tree and start adding patches.

It's tunable: Customize -> Console Options -> BANNER_TIMEOUT

> 
> Maybe we could wait until 0.13 and then introduce the FW cfg interface
> to gpxe?  I've already talked to some of the gpxe devs about it and they
> seem pretty receptive.  That would let us define how long the timeout was.
> 
> The advantage of leaving in the timeout is that it lets a user access
> the gPXE menu even if it's not set to be bootable.  You see this on bare
> metal all of the time with gPXE.

Yeah, you see this or even much longer netboot related timeouts these
days everywhere. Specifically when every damn NIC adds its own delay to
the boot, you quickly wait half a minute or more on this stage. Granted,
it's by far not that bad with qemu and gpxe, but this delay is a
regression from the nice speed we just gained a few months ago.

OK, compromise until we have a proper FW interface: BANNER_TIMEOUT=3.
That leaves us with a fair chance to break in but keeps the delay
regression low.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]