Alexander Graf wrote:
On 12.11.2008, at 16:45, Anthony Liguori wrote:
Alexander Graf wrote:
Hi,
I was thinking a bit about cross vendor migration recently and since
we're doing open source development, I figured it might be a good
idea to talk to everyone about this.
So why are we having a problem?
In normal operation we don't. If we're running a 32-bit kernel, we
can use SYSENTER to jump from kernel<->userspace. If we're on a
64-bit kernel with 64-bit userspace, every CPU supports SYSCALL. At
least Linux is being smart on this and does use exactly these two
capabilities in these two cases.
But if we're running in compat mode (64-bit kernel with 32-bit
userspace), things differ. Intel supports only SYSENTER here, while
AMD only supports SYSCALL. Both can still use int80.
Obviously we can trap-and-emulate but that would be slow in a
relatively fast past.
If we can do it without emulation, I'd greatly prefer it, as
syscall/sysenter emulation in the hypervisor most probably isn't
exactly fast ;-). And you don't really want to degrade performance
just because you're migrating (think flashplayer here). I guess
Windows 64-bit contains even more 32-bit parts.
I wonder if patching is an option?
Windows does have background daemons that check code in runtime and
compares that to checksums. So binary patching might break Windows
pretty easily. I'm really wondering why the CR8 patching still works -
maybe even that'll break with Windows 7.
The Hyper-V spec claims that the accesses to the TPR will always be in 5
byte instructions. Presumably this is to allow binary patching to be
reliable. I'm pretty sure newer versions of Windows don't access the
TPR so frequently or at least access it through CR8.
With VT on modern processors, TPR patching is unnecessary so as long as
they use CR8 on AMD processors, all should be okay.
Although here is obviously another spot where cross vendor migration
could be problematic :-)
Regards,
Anthony Liguori
Alex
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
