Andi Kleen wrote:
On Wed, Aug 22, 2007 at 09:48:25AM -0700, Zachary Amsden wrote:
Andi Kleen wrote:
On Tue, Aug 21, 2007 at 10:23:14PM -0700, Zachary Amsden wrote:
In general, I/O in a virtual guest is subject to performance problems.
The I/O can not be completed physically, but must be virtualized. This
means trapping and decoding port I/O instructions from the guest OS.
Not only is the trap for a #GP heavyweight, both in the processor and
the hypervisor (which usually has a complex #GP path), but this forces
the hypervisor to decode the individual instruction which has faulted.
Is that really that expensive? Hard to imagine.
You have an expensive (16x cost of hypercall on some processors)
Where is the difference comming from? Are you using SYSENTER
for the hypercall? I can't really see you using SYSENTER,
because how would you do system calls then? I bet system calls
are more frequent than in/out, so if you have decide between the
two using them for syscalls is likely faster.
We use sysenter for hypercalls and also for system calls. :)
Also I fail to see the fundamental speed difference between
mov index,register
int 0x...
...
switch (register)
case xxxx: do emulation
Int (on p4 == ~680 cycles).
versus
out ...
#gp
-> switch (*eip) {
case 0xee: /* etc. */
do emulation
GP = ~2000 cycles.
to verify protection in the page tables mapping the page allows
execution (P, !NX, and U/S check). This is a lot more expensive than a
When the page is not executable or not present you get #PF not #GP.
So the hardware already checks that.
The only case where you would need to check yourself is if you emulate
NX on non NX capable hardware, but I can't see you doing that.
No, it doesn't. Between the #GP and decode, you have an SMP race where
another processor can rewrite the instruction.
Zach
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization
