H. Peter Anvin wrote:
> What you'd want, at least, is a standard CPUID identification and
> range leaf at the top. 256 leaves is a *lot*, though; I'm not saying
> one couldn't run out, but it'd be hard. Keep in mind that for large
> objects there are "counting" CPUID levels, as much as I personally
> dislike them, and one could easily argue that if you're doing
> something that would require anywhere near 256 leaves you probably are
> storing bulk data that belongs elsewhere.
I agree, but it just makes the proposal a bit more brittle.
> Of course, if we had some kind of central authority assigning 8-bit
> IDs that would be even better, especially since there are tools in the
> field which already scan on 64K boundaries. I don't know, though, how
> likely it is that we'll have to deal with 256 hypervisors.
I'm assuming that the likelihood of getting all possible vendors -
current and future - to agree to a scheme like this is pretty small. We
need to come up with something that will work well when there are
non-cooperative parties to deal with.
> I agree completely, of course (except that "what hypervisor is this"
> still has limited usage, especially when it comes to dealing with bug
> workarounds. Similar to the way we use CPU vendor IDs and stepping
> numbers for physical CPUs.)
I guess. Its certainly useful to be able to identify the hypervisor for
bug reporting and just general status information. But making
functional changes on that basis should be a last resort.
J
_______________________________________________
Virtualization mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/virtualization
