Re: Cross vendor migration ideas

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

----- "Nitin A Kamble" <nitin.a.kamble@intel.com> wrote:

> Amit, Alex,
>   Please see my comments bellow.
> 
> Avi, 
>   Please have a look at the patches, and let me know the parts you
> think
> can be done better.
> 
> On Fri, 2008-11-14 at 06:07 -0700, Amit Shah wrote:
> > * On Thursday 13 Nov 2008 19:08:14 Alexander Graf wrote:
> > > On 13.11.2008, at 05:35, Amit Shah wrote:
> > > > * On Wednesday 12 Nov 2008 22:49:16 Alexander Graf wrote:
> > > >> On 12.11.2008, at 17:52, Amit Shah wrote:
> > > >>> 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.
> > > >>
> > > >> I wasn't talking about CPUID features, but the vendor string.
> Qemu64
> > > >> provides the AuthenticAMD string, so we don't run into any
> issues I'm
> > > >> presuming.
> > > >
> > > > Right -- the thing is, with the default AuthenticAMD string,
> winp x64
> > > > installation fails. That has to be because of some missing
> cpuids.
> > > > That's one
> > > > of the drawbacks of exposing a well-known CPU type. I was
> suggesting
> > > > we
> > > > should try out the -cpu qemu64 CPU type since it exposes a non-
> > > > standard CPU
> > > > to see if guests and most userspace programs work fine without
> any
> > > > further
> > > > tweaking -- see the 'cons' below for why this might be a
> problem.
> > >
> > > I still don't really understand what you're trying to say - qemu64
> is
> > > the default in KVM right now. You mean winxp64 installation
> doesn't
> 
> 
> > No, the default for KVM is the host CPU type.
> 
> Amit, Aliex is correct. the default cpu for kvm is qemu64 not the
> host.

There are two things -- the Vendor ID and the cpuid bits. I'm talking about the vendor ID here.

> I have sent the patches to add an options -cpu host. Some of the
> patches
> are gone in, But All the patches are not in yet. Also my patches does
> not make the host option as default. I have attached the remaining
> two
> patches.

Amit.