On Sep 19, 2014, at 10:58 AM, Borislav Petkov <bp@xxxxxxxxx> wrote: > On Thu, Sep 18, 2014 at 03:36:43PM +0200, Paolo Bonzini wrote: >> We're talking about the case where the field is not reserved anymore and >> we _know_ that the vendor has just decided to grow the bitfield that >> precedes it. > > We're talking about the case where you assumed that a reserved bit is 0 > which is an unsafe assumption, the least. > >> As soon as we know that the field is not reserved anymore, we >> obviously rely on reserved bits being zero in older processors, and in >> future processors from other vendors. > > Again, this is an unsafe assumption. > >> The trivial example is feature bits like XSAVE. We query them all the >> time without checking the family when they were first introduced, >> don't we? > > The feature bits would obviously be 0 if features are not supported. > > However, even there > > "16 - Reserved - Do not count on the value." > > I'm quoting Intel's CPUID doc 241618-037 from 2011 (there might be a > newer one though), the CPUID(1).ECX description. New fields which which replace reserved bits would be handled the same way with bitfields and bit masks. As for the concern that CPUID fields would be extended into non-zero reserved bits - can someone point me to a single case that occurred in the last 20 years during which CPUID existed? The closest thing I found was “extended family id”, but this field is separate than “family id” and treated this way. Nadav
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail
