[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Chris Wright wrote:
* Zachary Amsden (zach@xxxxxxxxxx) 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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.