Re: Cross vendor migration ideas

[Andi Kleen <andi@firstfloor.org>]

Alexander Graf wrote:
> 
> On 15.11.2008, at 14:03, Andi Kleen wrote:
> 
>> "Serebrin, Benjamin (Calendar)" <Benjamin.Serebrin@exchange.amd.com>
>> 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.

I was mainly thinking of tuning.

For example Linux selects the best suitable page copy
function based on vendor information. Using the wrong page copy
can have a large impact on your performance.

> 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? 

Yes. Undoubtedly also the same with others.

>> 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.

Depends on the CPU. Newer CPUs are faster.

Also you would select the default based on which CPU you're booting
on. So initially and as long as you stay on the same
vendor you'll have full performance.  Only if you switch
vendors later you'll also eat the emulation hit (and get it
back again when you switch back to a system with the original vendor)
But everything will still work correctly and that is the
important part.

Doesn't sound so bad to me.

-Andi