Comments inline. -----Original Message----- From: Andi Kleen <[EMAIL PROTECTED]> Sent: Saturday, November 15, 2008 07:03 To: Serebrin, Benjamin (Calendar) <[EMAIL PROTECTED]> Cc: Skywing <[EMAIL PROTECTED]>; Alexander Graf <[EMAIL PROTECTED]>; Anthony Liguori <[EMAIL PROTECTED]>; [email protected] <[email protected]>; Amit Shah <[EMAIL PROTECTED]>; Avi Kivity <[EMAIL PROTECTED]>; Wahlig, Elsie <[EMAIL PROTECTED]>; Nakajima, Jun <[EMAIL PROTECTED]> Subject: Re: Cross vendor migration ideas
> Also it might break user space, unless you key the fake vendor CPUID > intercept on ring 0 vs ring 3 (but even if that might not be enough > because some kernel modules can call CPUID on their own) > > I think just emulating SYSCALL/SYSENTER would be safer. It shouldn't > be that much slower than int 0x80 hopefully. > > -Andi If I understand that idea correctly, I think that trying to present a differing view of the CPU vendor and/or feature set is likely to be fraught with peril and highly fragile. There are many systems where the kernel gets processor feature data in CPL=0 and makes it available to user mode. This creates an inconsistency when user mode uses cpuid directly and comes up with differing results. As a real world example, in Windows, the kernel is responsible for examining the current processors installed on the box, mapping processor feature codes to a standard encoding, and making this available to all user mode processes via a shared memory region (read only to user mode) at a well known location (SharedUserData->ProcessorFeatures). However, user mode programs are free to make their own determinations via cpuid calls if they so wish. Many programs use the standard abstracted processor feature determination mechanism (figured by the kernel), while others, for varying reasons (some good and some foolish) just call cpuid directly at CPL=3. There can even be a mix within different code modules loaded into a process. In the specific case of Windows and system services, IIRC the old-style int 2e system service interface is always initialized on 32-bit x86 kernels, even if sysenter or syscall will be preferred. As far as I know, this is just for backcompat with programs issuing system services directly as opposed to using the correct C-level abstraction layer. For Windows, it is CPL=0 inspection of processor attributes via cpuid (assuming the "disable fast system service interface" registry value is not set) that determines which is used. This occurs once, at system boot, as one would expect. That being said, I still think that it will break things in difficult to debug ways should you introduce an inconsistent view of cpuid features into the system. - S-- 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
