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 Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
