On 09/18/2014 03:00 PM, Andy Lutomirski wrote:
> On Thu, Sep 18, 2014 at 2:46 PM, David Hepkin <david...@microsoft.com> wrote:
>> I'm not sure what you mean by "this mechanism?" Are you suggesting that
>> each hypervisor put "CrossHVPara\0" somewhere in the 0x40000000 - 0x400fffff
>> CPUID range, and an OS has to do a full scan of this CPUID range on boot to
>> find it? That seems pretty inefficient. An OS will take 1000's of
>> hypervisor intercepts on every boot just to search this CPUID range.
>
> Linux already does this, which is arguably unfortunate. But it's not
> quite that bad; the KVM and Xen code is only scanning at increments of
> 0x100.
>
> I think that Linux as a guest would have no problem with checking the
> Hyper-V range or some new range. I don't think that Linux would want
> to have to set a guest OS identity, and it's not entirely clear to me
> whether this would be necessary to use the Hyper-V mechanism.
>
We really don't want to have to do this in early code, though.
>>
>> I suggest we come to consensus on a specific CPUID leaf where an OS needs to
>> look to determine if a hypervisor supports this capability. We could define
>> a new CPUID leaf range at a well-defined location, or we could just use one
>> of the existing CPUID leaf ranges implemented by an existing hypervisor.
>> I'm not familiar with the KVM CPUID leaf range, but in the case of Hyper-V,
>> the Hyper-V CPUID leaf range was architected to allow for other hypervisors
>> to implement it and just show through specific capabilities supported by the
>> hypervisor. So, we could define a bit in the Hyper-V CPUID leaf range
>> (since Xen and KVM also implement this range), but that would require Linux
>> to look in that range on boot to discover this capability.
>
> I also don't know whether QEMU and KVM would be okay with implementing
> the host side of the Hyper-V mechanism by default. They would have to
> implement at least leaves 0x40000001 and 0x4000002, plus correctly
> reporting zeros through whatever leaf is used for this new feature.
> Gleb? Paolo?
>
The problem is what happens with a noncooperating hypervisor. I guess
we could put a magic number in one of the leaf registers, but still...
-hpa
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
