From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Subject: Re: [PATCH 1/2] qemu-kvm: extboot: Keep variables in RAM Date: Thu, 18 Feb 2010 14:56:37 -0800 Message-ID: <4B7DC5A5.5020500@linux.intel.com> References: <4B7D6725.1090202@siemens.com> <4B7DA2C4.9040207@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Jan Kiszka , Avi Kivity , Marcelo Tosatti , kvm To: Anthony Liguori Return-path: Received: from mga06.intel.com ([134.134.136.21]:48290 "EHLO orsmga101.jf.intel.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751185Ab0BRW5i (ORCPT ); Thu, 18 Feb 2010 17:57:38 -0500 In-Reply-To: <4B7DA2C4.9040207@codemonkey.ws> Sender: kvm-owner@vger.kernel.org List-ID: 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 >> > > commit a4492b03932ea3c9762372f3e15e8c6526ee56c6 > Author: H. Peter Anvin > 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 > Signed-off-by: Avi Kivity > > 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