Re: State of current pv_ops backend for KVM?

Zachary Amsden
2007-05-30T18:02:33Z

Anthony Liguori wrote:
> Rusty Russell wrote:
>> On Mon, 2007-05-28 at 20:54 -0500, Anthony Liguori wrote:
>>
>>> Howdy,
>>>
>>> Does anyone know what the state of a pv_ops backend for KVM is? I
>>> know Ingo has an implementation that implements CR3 caching but I
>>> don't see any branches in Avi's git tree.
>>>
>>> Perhaps we should try for a simple pv_ops backend for 2.6.23 seeing
>>> as how the host infrastructure is there? I'd be willing to do some
>>> leg work here...
>>>
>>
>> "Me too". It's at least worth toying with the mmu batching stuff to see
>> if that can shave some cycles there: it seems that cr3 caching is the
>> main win for context switch so batching there won't help.
>>
>
> I'm working on a simple patch that just adds the infrastructure.
>
>> IIRC Ingo used a magic MSR to detect kvm, and there was a question mark
>> over that.
>
> I am not too worried about using an MSR. There's really no fool proof
> method here. The only thing to do IMHO is move the kvm pv_ops backend
> into a separate file and add appropriate Kconfig stuff.
>
>> VMI uses a different technique, which is probably worth
>> considering...
>>
>
> VMI can determine that it's under VMware since VMware has to publish
> an option ROM. It's quite neat, but overkill for what we're doing
> (since we're not going to be using a ROM anyway).

The near to being blessed way to do this is to use a CPUID leaf (I
believe it is 0x40000000) to identify the hypervisor. I don't have the
exact details, but making CPUID 0x40000000 return 'KVMKVMKVMKVM' sounds
like a pretty safe detection technique.

We're probably dropping the ROM probing in favor of this for 64-bit.

Zach