Cc: Ingo Molnar <mingo@...>, H. Peter Anvin <hpa@...>, Thomas Gleixner <tglx@...>, LKML <linux-kernel@...>, the arch/x86 maintainers <x86@...>, <avi@...>, Rusty Russell <rusty@...>, Zachary Amsden <zach@...>, Dan Hecht <dhecht@...>, <Jun.Nakajima@...>, Tim Deegan <Tim.Deegan@...>
I'm sympathetic to the idea, but it seems a bit under-defined.
Are you leaving a gap between 0x40000000 and -10 for what? Future
extension? Avoiding existing hypervisor-specific leaves?
I think there's a move towards doing a scan for a signature, such as
checking every 16 leaves after 0x40000000 for "a while" looking for
interesting signatures, so that a hypervisor can support multiple ABIs
at once. Given this, it would be better to define a "Generic Hypervisor
ABI" signature, and put all the related leaves together.
And then, rather than having a simple "maximum leaf", it would be better
to have cap bits for each specific feature. For example, how would the
"RESERVED" registers in "Timing information" ever get used? How would
you know that they were no longer reserved, but now meaningful?
That said, I'm a bit worried about the whole idea of having these kinds
of timing parameters. It does assume that they're constant for the
whole life of the VM. What if they change due to power management or
migration?
