----- "Nitin A Kamble" <[EMAIL PROTECTED]> 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. -- 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
