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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
