Re: [PATCH 18/25] [PATCH] turn priviled operations into macros in entry.S

On Wed, Aug 08, 2007 at 09:47:05AM -0400, Steven Rostedt wrote:

/me working very hard to get lguest64 ready for public display

Here's a snippet from my version of core.c.  I've been thinking of ways to
optimize it, but for now it works fine. This was done for both ring 3 and
ring 1 lguest versions (this is the host running):


	/*
	 * Update the LSTAR to point to the HV syscall handler.
	 * Also update the fsbase if the guest uses one.
	 */
	wrmsrl(MSR_LSTAR, (unsigned long)HV_OFFSET(&lguest_syscall_trampoline));

[...]
	asm volatile ("pushq %2; pushq %%rsp; pushfq; pushq %3; call *%6;"
		      /* The stack we pushed is off by 8, due to the
previous pushq */
		      "addq $8, %%rsp"

Weird stack inbalance, i'm surprised that works. %6 must be doing strange
things.

	/* Need to read manual, does rdmsr clear
	 * the top 32 bits of rax? */
	xor	%rax, %rax

	movl  	$MSR_GS_BASE,%ecx
	rdmsr

This seems incredibly slow. Since GS changes are controlled in 
the kernel why don't you just cache them in the per cpu area? 
The only case where user can reload it is using segment
selector changes, which can be also handled.

Also why do you need the guest gs value anyways? 

You could just use your own stack and let the guest
switch to its own.

-Andi