Re: Bug#584846: Detects only 64MB and fails to boot on Intel Green City board if e820 hooked by GRUB2

["H. Peter Anvin" <hpa@zytor.com>]

On 06/24/2010 12:27 AM, Josh Triplett wrote:
> 
> The following patch fixes GRUB; with this patch, I can reserve memory
> (such as with drivemap), boot 2.6.35-rc3 successfully, and it detects
> all of my RAM.
> 

Congratulations!  You have just committed the single most common BIOS
implementation bug.  (Sorry for the sarcasm, but this seems to be a bug
that almost everyone who tries to implement BIOS makes at one point or
another... even the original IBM BIOS had it in at least one place.)

You *must not* use "lret $2" to return to the caller, because the INT
instruction will have cleared IF after pushing the registers to the
stack.  You have to restore the original IF, which "lret $2" will not do.

The best way to do this is to clobber the low byte of the flags register
on the stack.  Since CF is bit 0, and the low byte only contains
arithmetic flags anyway, you can simply overwrite the low byte with 0
for CF=0 and 1 for CF=1.  This will zero SF, ZF, AF and PF as side
effect, which is OK for almost all uses (including e820/e801/88.)

If you don't already have a pointer to the stack, you have to make one,
since it is not possible in 16-bit mode to access the stack directly.
One option is to replace each iret with a jump to the following common code:

carry_cf_iret:
	pushw	%bp
	movw	%sp, %bp
	setc	6(%bp)		/* Set CF on stack based on EFLAGS */
	popw	%bp
	iret

> 
> I don't see any trivial way Linux could work around this bug.  If the
> e820 call left CF=0 on entry, then the error case would get incorrectly
> treated as a valid e820 entry (albeit a final one, since bx=0).
> 

More importantly, it makes the error direction the wrong one.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.