Re: [PATCH 1/2] qemu-kvm: extboot: Keep variables in RAM

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

On 02/18/2010 12:27 PM, Anthony Liguori wrote:
> On 02/18/2010 10:13 AM, Jan Kiszka wrote:
>> Instead of saving the old INT 0x13 and 0x19 handlers in ROM which fails
>> under QEMU as it enforces protection, keep them in spare vectors of the
>> interrupt table, namely INT 0x80 and 0x81.
>>
>> Signed-off-by: Jan Kiszka<jan.kiszka@siemens.com>
>>    
> 
> commit a4492b03932ea3c9762372f3e15e8c6526ee56c6
> Author: H. Peter Anvin <hpa@zytor.com>
> Date:   Fri Jul 18 11:22:59 2008 -0700
> 
>      kvm: extboot: don't use interrupt vectors $0x2b and $0x2c
> 
>      extboot's use of interrupt vectors $0x2b and $0x2c is unsafe, as these
>      interrupt vectors fall in the OS-use range (0x20-0x3f).  Furthermore,
>      it's unnecessary: we can keep a local pointer instead of hooking
>      another interrupt as long as we can write to our own segment.
> 
>      Make the extboot segment writable, and use local variables to hold the
>      old link pointers.
> 
>      If this turns out to cause problems, we should probably switch to
>      using vectors in the 0xc0-0xef range, and/or other BIOS-reserved
>      memory.
> 
>      Signed-off-by: H. Peter Anvin <hpa@zytor.com>
>      Signed-off-by: Avi Kivity <avi@qumranet.com>
> 
> Sounds like 0x80/0x81 is probably not the best choice.  hpa: any 
> suggestions?

There aren't really any free memory that you can just use -- there are
no free interrupt vectors which are safe to use.  Furthermore, this
implies that there is a bug in the Qemu BIOS in this respect: the PCI
spec requires that the "ROM region" (upper memory area) that contains
shadow ROM contents be writable until INT 19h is executed -- at *that*
point it gets write protected.

However, as I did point out in the original comment, there are some
BIOSes in the field which uses vectors 0xc0-0xdf as a scratch memory
pool -- usually to have somewhere to stash a small stack -- so if you
absolutely have to go down this route that range those probably be the
safest.  An alternative would be to use memory in the BDA in the range
0x4ac-0x4ff (absolute), which appears to be available for BIOS-specific
uses.

>> NEITHER OF THESE OPTIONS ARE SAFE ON REAL HARDWARE <<
These are both BIOS-specific use areas.

	-hpa