Alok Kataria wrote:
>> No, that's always a terrible idea. Sure, its necessary to deal with
>> some backward-compatibility issues, but we should even consider a new
>> interface which assumes this kind of thing. We want properly enumerable
>> interfaces.
>
> The reason we still have to do this is because, Microsoft has already
> defined a CPUID format which is way different than what you or I are
> proposing ( with the current case of 256 leafs being available). And I
> doubt they would change the way they deal with it on their OS.
> Any proposal that we go with, we will have to export different CPUID
> interface from the hypervisor for the 2 OS in question.
>
> So i think this is something that we anyways will have to do and not
> worth binging about in the discussion.
No, that's a good hint that what "you and I" are proposing is utterly
broken and exactly underscores what I have been stressing about
noncompliant hypervisors.
All I have seen out of Microsoft only covers CPUID levels 0x40000000 as
an vendor identification leaf and 0x40000001 as a "hypervisor
identification leaf", but you might have access to other information.
This further underscores my belief that using 0x400000xx for anything
"standards-based" at all is utterly futile, and that this space should
be treated as vendor identification and the rest as vendor-specific.
Any hope of creating a standard that's actually usable needs to be
outside this space, e.g. in the 0x40SSSSxx space I proposed earlier.
-hpa
_______________________________________________
Virtualization mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/virtualization
