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

H. Peter Anvin
2010-02-18T22:57:38Z

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