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.
Operating systems detect usage of SYSCALL or SYSENTER pretty early on
(Linux does this on vdso). So when we boot up on an Intel machine,
Linux assumes that using SYSENTER in compat mode is fine. Migrating
that machine to an AMD machine breaks this assumption though, since
SYSENTER can't be used in compat mode.
On LInux, this detection is based on the CPU vendor string. If Linux
finds a "GenuineIntel", SYSENTER is used in compat mode, if it's
"AuthenticAMD", SYSCALL is used and if none of these two is found,
int80 is used.
I tried modifying the vendor string, removed the "overwrite the vendor
string with the native string" hack and things look like they work
just fine with Linux.
Unfortunately right now I don't have a 64-bit Windows installation
around to check if that approach works there too, but if it does and
no known OS breaks due to the invalid vendor string, we can just
create our own virtual CPU string, no?
I'd love to hear comments and suggestions on this and hope we'll end
up in a fruitful discussion on how to improve the current situation.
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
