Hi Alex, * On Wednesday 12 Nov 2008 21:09:43 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. > > 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?
qemu has an option for that, -cpu qemu64 IIRC. As long as we expose practically correct cpuids and MSRs, this should be fine. I've not tested qemu64 with winxp x64 though. Also, last I knew, winxp x64 installation didn't succeed with --no-kvm. qemu by default exposes an AMD CPU type. There are pros and cons to expose a custom vendor ID: pros: - We don't need to have all the cpuid features exposed which are expected of a physically available CPU in the market, for example, badly-coded applications might crash if we don't have SSSE3 on a Core2Duo. But badly-coded or not, not exposing what's actually available on every C2D out there is bad. cons: - To expose the "correct" set of feature bits for a known processor, we also need to check the family/model/stepping to support the exact same feature bits that were present in the CPU. - We might not get some optimizations that OSes might have based on CPU type, even if the host CPU qualifies for such optimizations - Standard programs like benchmarking tools, etc., might fail if they depend on the vendor string for their functionality For 32-bit guests, I think exposing a pentium4 or Athlon CPU type should be fine. For 64-bit guests, the newer the better. > 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. I have a patch ready for emulating sysenter/sysexit on AMD systems (needs testing). Patching the guest was an option that was discouraged; I had a hack ready but it was quickly shelved (again, untested). Amit -- 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
