Chris Wright wrote:
* Zachary Amsden ([email protected]) 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 [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]
