Re: Cross vendor migration ideas

[Amit Shah <amit.shah@redhat.com>]

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