Re: [RFC, PATCH 8/24] i386 Vmi syscall assembly

[Zachary Amsden <zach@vmware.com>]

Chris Wright wrote:
> * Zachary Amsden (zach@vmware.com) wrote:
>   
> > These changes are sufficient to glue the Linux low level entry points to
> > hypervisor event injection by emulating the native processor exception
> > frame interface.
> >     
>
> There's a bit more going on in the Xen changes to entry.S.  The STI/CLI
> abstraction definitely gets partway there.  Then there's some bits that
> use (in your terms) __STI, __CLI.  It's in code that's a pure addition
> so it's tempting to simply make a mechanism for the additions, but it's a bit
> too intertwined to just separate that code, as there's calls from core
> entry.S into the Xen additions.
>   

Yes, entry.S in Xen is a lot more complicated because of the event 
channel stuff.  I don't think we're adverse to supporting the event 
channel interface, I just think that you can actually get a cleaner and 
simpler implementation without it.

> > N.B. Sti; Sysexit is a required abstraction, as the STI instruction implies
> > holdoff of interrupts, which is destroyed by any NOP padding.
> >     
>
> Or just disable systenter ;-)  Random question...do you support systenter?
> Sounds slower than int80, since it should require 3->0->1->0->3 transitions.
> Just idly curious if you've done benchmarks to see the difference.
>   

Still required for VMI kernels on native - so the padding of sti doesn't 
affect the holdoff in that case.  We actually do use sysenter.  We've 
done the benchmarks, and found the tradeoffs and benefits are similar 
for both approaches.

Zach
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/