On Sat, Nov 15, 2008 at 2:39 PM, Alexander Graf <[EMAIL PROTECTED]> wrote: > > On 15.11.2008, at 14:03, Andi Kleen wrote: > >> "Serebrin, Benjamin (Calendar)" <[EMAIL PROTECTED]> >> writes: >>> >>> 64-bit OSes will use SYSCALL for 64-bit code. CPUID name string should >>> be "FakeCPUFakeCPU" >> >> One problem is that you'll disable a lot of vendor specific setup >> code if you do that. Might have all kinds of unexpected side effects. > > Yes, but since we're emulating a CPU anyways we don't want vendor specific > setup, since we might live migrate. And quirks should already be handled by > the host. We'd only nop them out usually. > >> 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) > > Is there userspace code that relies on GenuineIntel? What would a new vendor > do? Can't we just behave the same and have our self-invented vendor string > added to applications that direly need to know which vendor they're running > on? > >> I think just emulating SYSCALL/SYSENTER would be safer. It shouldn't >> be that much slower than int 0x80 hopefully. > > Well emulating them means you're leaving the VM on every user<->kernel > transition. That's a _huge_ performance hit. I don't have the numbers, but > IIRC a roundtrip is ~3000 cycles. > > So yes, it definitely is safer. But it'll hurt performance a lot - which is > exactly what you'd want to avoid when migrating between vendors.
We can possibly do it a little bit better by emulating in the guest directly. So the deal would be emulation both in the host and the guest. If the guest have it, fine. Otherwise, we use host emulation, that is slower, but works. > Alex > -- > 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 > -- Glauber Costa. "Free as in Freedom" http://glommer.net "The less confident you are, the more serious you have to act." -- 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
