mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Chuck Ebbert <76306.1226@compuserve.com>
To: Andi Kleen <ak@suse.de>
Cc: virtualization <virtualization@lists.osdl.org>,
	Zachary Amsden <zach@vmware.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	Xen-devel <xen-devel@lists.xensource.com>,
	Dan Hecht <dhecht@vmware.com>, Chris Wright <chrisw@sous-sol.org>
Subject: Re: [RFC, PATCH 5/24] i386 Vmi code patching
Date: Mon, 27 Mar 2006 19:52:58 -0500	[thread overview]
Message-ID: <200603271955_MC3-1-BBB1-E3F1@compuserve.com> (raw)

In-Reply-To: <200603222115.46926.ak@suse.de>

On Wed, 22 Mar 2006 21:15:44 +0100, Andi Kleen wrote:

> On Monday 13 March 2006 19:02, Zachary Amsden wrote:
> > The VMI ROM detection and code patching mechanism is illustrated in
> > setup.c.  There ROM is a binary block published by the hypervisor, and
> > and there are certainly implications of this.  ROMs certainly have a
> > history of being proprietary, very differently licensed pieces of
> > software, and mostly under non-free licenses.  Before jumping to the
> > conclusion that this is a bad thing, let us consider more carefully
> > why hiding the interface layer to the hypervisor is actually a good
> > thing.
> 
> How about you fix all these issues you describe here first 
> and then submit it again?
> 
> The disassembly stuff indeed doesn't look like something
> that belongs in the kernel.

I think they put the disassembler in there as a joke. ;)

It's not necessary for fixing up the call site, anyway. Something like
this should work, assuming there is always a call in every vmi
translation.


 /* Now, measure and emit the vmi translation sequence */
 #define vmi_translation_start			\
 	.pushsection .vmi.translation,"ax";	\
 	781:;
 #define vmi_translation_finish			\
-	782:;					\
+	783:;					\
 	.popsection;
 #define vmi_translation_begin	781b
-#define vmi_translation_end	782b
+#define vmi_call_location	782b
+#define vmi_translation_end	783b
 #define vmi_translation_len	(vmi_translation_end - vmi_translation_begin)
+#define vmi_call_offset	(vmi_call_location - vmi_translation_begin)

 #define vmi_call(name)						\
-	call .+5+name
+	782: call .+5+name

 #define vmi_annotate(name)				\
 	.pushsection .vmi.annotation,"a";		\
 	.align 4;					\
 	.long name;					\
 	.long vmi_padded_begin;				\
 	.long vmi_translation_begin;			\
 	.byte vmi_padded_len;				\
 	.byte vmi_translation_len;			\
 	.byte vmi_pad_total;				\
-	.byte 0;					\
+	.byte vmi_call_offset;				\
 	.popsection;

 struct vmi_annotation {
 	unsigned long	vmi_call;
 	unsigned char 	*nativeEIP;
 	unsigned char	*translationEIP;
 	unsigned char	native_size;
 	unsigned char	translation_size;
 	char		nop_size;
-	unsigned char	pad;
+	unsigned char	call_offset;
 };

 static void fixup_translation(struct vmi_annotation *a)
 {
 	unsigned char *c, *start, *end;
 	int left;
 
 	memcpy(a->nativeEIP, a->translationEIP, a->translation_size);
+	patch_call_site(a, a->nativeEIP + a->call_offset);
-	start = a->nativeEIP;
-	end = a->nativeEIP + a->translation_size;
-
-	for (c = start; c < end;) {
-		switch(*c) {
-			case MNEM_CALL_NEAR:
-				patch_call_site(a, c);
-				c+=5;
-				break;
-
-			case MNEM_PUSH_I:
-				c+=5;
-				break;
-
-			case MNEM_PUSH_IB:
-				c+=2;
-				break;
-
-			case MNEM_PUSH_EAX:
-			case MNEM_PUSH_ECX:
-			case MNEM_PUSH_EDX:
-			case MNEM_PUSH_EBX:
-			case MNEM_PUSH_EBP:
-			case MNEM_PUSH_ESI:
-			case MNEM_PUSH_EDI: 
-				c+=1;
-				break;
-
-			case MNEM_LEA:
-				BUG_ON(*(c+1) != 0x64);  /* [--][--]+disp8, %esp */
-				BUG_ON(*(c+2) != 0x24);  /* none + %esp */
-				c+=4;
-				break;
-
-			default:
-				/*
-				 * Don't printk - it may acquire spinlocks with
-				 * partially completed VMI translations, causing
-				 * nuclear meltdown of the core.
- 				 */
-				BUG();
-				return;
-		}
-	}

-- 
Chuck
"Penguins don't come from next door, they come from the Antarctic!"

             reply	other threads:[~2006-03-28  0:55 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-28  0:52 Chuck Ebbert [this message]
2006-03-28  1:48 ` Zachary Amsden
  -- strict thread matches above, loose matches on Subject: below --
2006-03-22 23:41 Volkmar Uhlig
2006-03-13 18:02 Zachary Amsden
2006-03-15 10:02 ` Chris Wright
2006-03-15 16:01   ` Zachary Amsden
2006-03-15 22:05 ` Anthony Liguori
2006-03-15 23:00 ` Pavel Machek
2006-03-17  0:51   ` Zachary Amsden
2006-03-17 10:08   ` Joshua LeVasseur
2006-03-17 21:11     ` Chris Wright
2006-03-18  0:49       ` Joshua LeVasseur
2006-03-16 19:10 ` Jan Engelhardt
2006-03-16 19:45   ` Rik van Riel
2006-03-16 21:54     ` Zachary Amsden
2006-03-22 20:15 ` Andi Kleen
2006-03-22 21:40   ` Chris Wright
2006-03-22 22:16     ` Zachary Amsden
2006-03-22 22:33       ` Daniel Arai
2006-03-22 23:02         ` Chris Wright
2006-03-22 22:51       ` Chris Wright
2006-03-22 23:36         ` Zachary Amsden
2006-03-23  0:41           ` Chris Wright
2006-03-23  0:54             ` Zachary Amsden
2006-03-23  1:06               ` Chris Wright
2006-03-23  4:04                 ` Zachary Amsden
2006-03-23 11:42                 ` Joshua LeVasseur
2006-03-23  0:31     ` Anthony Liguori
2006-03-23  0:40       ` Chris Wright
2006-03-23  9:25         ` Keir Fraser

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=200603271955_MC3-1-BBB1-E3F1@compuserve.com \
    --to=76306.1226@compuserve.com \
    --cc=ak@suse.de \
    --cc=chrisw@sous-sol.org \
    --cc=dhecht@vmware.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=virtualization@lists.osdl.org \
    --cc=xen-devel@lists.xensource.com \
    --cc=zach@vmware.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

all inboxes | Powered by JetHome®