public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Avi Kivity <avi@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>, kvm <kvm@vger.kernel.org>,
	"H. Peter Anvin" <hpa@linux.intel.com>
Subject: Re: [PATCH 1/2] qemu-kvm: extboot: Keep variables in RAM
Date: Thu, 18 Feb 2010 14:27:48 -0600	[thread overview]
Message-ID: <4B7DA2C4.9040207@codemonkey.ws> (raw)
In-Reply-To: <4B7D6725.1090202@siemens.com>

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?

Regards,

Anthony Liguori

> ---
>
> Don't forget to update extboot.bin after merging both patches.
>
>   pc-bios/optionrom/extboot.S |   41 ++++++++++++++++++++++++++++++-----------
>   1 files changed, 30 insertions(+), 11 deletions(-)
>
> diff --git a/pc-bios/optionrom/extboot.S b/pc-bios/optionrom/extboot.S
> index 1e60f68..1eeb172 100644
> --- a/pc-bios/optionrom/extboot.S
> +++ b/pc-bios/optionrom/extboot.S
> @@ -19,6 +19,9 @@
>    *   Authors: Anthony Liguori<aliguori@us.ibm.com>
>    */
>
> +#define OLD_INT19	(0x80 * 4)	/* re-use INT 0x80 BASIC vector */
> +#define OLD_INT13	(0x81 * 4)	/* re-use INT 0x81 BASIC vector */
> +
>   .code16
>   .text
>   	.global _start
> @@ -37,7 +40,7 @@ _start:
>
>   	/* save old int 19 */
>   	mov (0x19*4), %eax
> -	mov %eax, %cs:old_int19
> +	mov %eax, (OLD_INT19)
>
>   	/* install out int 19 handler */
>   	movw $int19_handler, (0x19*4)
> @@ -48,6 +51,7 @@ _start:
>   	lret
>
>   int19_handler:
> +	push %eax /* reserve space for lret */
>   	push %eax
>   	push %bx
>   	push %cx
> @@ -69,7 +73,7 @@ int19_handler:
>   1: /* hook int13: intb(0x404) == 1 */
>   	/* save old int 13 to int 2c */
>   	mov (0x13*4), %eax
> -	mov %eax, %cs:old_int13
> +	mov %eax, (OLD_INT13)
>
>   	/* install our int 13 handler */
>   	movw $int13_handler, (0x13*4)
> @@ -90,15 +94,21 @@ int19_handler:
>
>   3: /* fall through: inb(0x404) == 0 */
>   	/* restore previous int $0x19 handler */
> -	mov %cs:old_int19,%eax
> +	mov (OLD_INT19),%eax
>   	mov %eax,(0x19*4)
> -	
> +
> +	/* write old handler as return address onto stack */
> +	push %bp
> +	mov %sp, %bp
> +	mov %eax, 14(%bp)
> +	pop %bp
> +
>   	pop %ds
>   	pop %dx
>   	pop %cx
>   	pop %bx
>   	pop %eax
> -	ljmpw *%cs:old_int19
> +	lret
>
>   #define FLAGS_CF	0x01
>
> @@ -626,7 +636,21 @@ terminate_disk_emulation:
>   int13_handler:
>   	cmp $0x80, %dl
>   	je 1f
> -	ljmpw *%cs:old_int13
> +
> +	/* write old handler as return address onto stack */
> +	push %eax
> +	push %eax
> +	push %ds
> +	push %bp
> +	mov %sp, %bp
> +	xor %ax, %ax
> +	mov %ax, %ds
> +	mov (OLD_INT13), %eax
> +	mov %eax, 8(%bp)
> +	pop %bp
> +	pop %ds
> +	pop %eax
> +	lret
>   1:
>   	cmp $0x0, %ah
>   	jne 1f
> @@ -686,10 +710,5 @@ int13_handler:
>   	int $0x18  /* boot failed */
>   	iret
>
> -/* Variables */
> -.align 4, 0
> -old_int13:	.long 0
> -old_int19:	.long 0
> -	
>   .align 512, 0
>   _end:
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>    


  reply	other threads:[~2010-02-18 20:35 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-18 16:13 [PATCH 1/2] qemu-kvm: extboot: Keep variables in RAM Jan Kiszka
2010-02-18 20:27 ` Anthony Liguori [this message]
2010-02-18 22:56   ` H. Peter Anvin
2010-02-19 10:06     ` Jan Kiszka
2010-02-19 16:50       ` H. Peter Anvin
2010-02-19 17:03         ` Jan Kiszka
2010-02-19 17:24           ` H. Peter Anvin
2010-02-19 17:44             ` Jan Kiszka
2010-02-19 18:10           ` Anthony Liguori
2010-02-19 18:17             ` Jan Kiszka
2010-02-19 19:37               ` H. Peter Anvin
2010-02-20  3:21                 ` Kevin O'Connor
2010-02-22 10:03               ` Stefan Hajnoczi
     [not found]                 ` <4B82DE3F.5090306@linux.intel.com>
2010-02-23  9:30                   ` Stefan Hajnoczi
2010-02-22  9:40 ` Avi Kivity
2010-02-22  9:59   ` Jan Kiszka
2010-02-22 10:03     ` Jan Kiszka
2010-02-22 11:02     ` Avi Kivity
2010-04-06  8:50   ` Jan Kiszka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B7DA2C4.9040207@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=avi@redhat.com \
    --cc=hpa@linux.intel.com \
    --cc=jan.kiszka@siemens.com \
    --cc=kvm@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox