On Thu, Sep 18, 2014 at 03:06:59PM +0200, Paolo Bonzini wrote:
> The extra bit used to be reserved and thus will be zero on older
> families. So, nothing?
"thus will be zero" is unfortunately simply not true.
>From the SDM:
"1.3.2 Reserved Bits and Software Compatibility
In many register and memory layout descriptions, certain bits are marked
as reserved. When bits are marked as reserved, it is essential for
compatibility with future processors that software treat these bits as
having a future, though unknown, effect. The behavior of reserved bits
should be regarded as not only undefined, but unpredict- able. Software
should follow these guidelines in dealing with reserved bits:
* Do not depend on the states of any reserved bits when testing the values of registers that contain such bits.
Mask out the reserved bits before testing.
* Do not depend on the states of any reserved bits when storing to memory or to a register.
* Do not depend on the ability to retain information written into any reserved bits.
* When loading a register, always load the reserved bits with the values indicated in the documentation, if any,
or reload them with values previously read from the same register."
And so on and so on.
Aaanyway, I see kvm folks are strongly determined to do this so I'll
propose you do it for kvm only and not touch the rest of arch/x86/.
I really really disagree with casting CPUID words in stone and with
touching code which is perfectly fine.
But this is just me and the final word lies with x86 people so it'll
happen whatever they say.
--
Regards/Gruss,
Boris.
--
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
