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!"
next 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®