From mboxrd@z Thu Jan 1 00:00:00 1970 From: Borislav Petkov Subject: Re: [RESEND PATCH 1/3] x86: Adding structs to reflect cpuid fields Date: Fri, 19 Sep 2014 09:58:15 +0200 Message-ID: <20140919075814.GA30491@nazgul.tnic> References: <20140917124501.GC5358@nazgul.tnic> <1410958454-7501-1-git-send-email-namit@cs.technion.ac.il> <1410958454-7501-2-git-send-email-namit@cs.technion.ac.il> <20140917132141.GD5358@nazgul.tnic> <20140917140601.GE5358@nazgul.tnic> <541AD8F3.5010700@redhat.com> <20140918132635.GB27008@nazgul.tnic> <541ADFEB.6030801@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Cc: Nadav Amit , Ingo Molnar , "H. Peter Anvin" , Ingo Molnar , Thomas Gleixner , the arch/x86 maintainers , kvm , Linux Kernel Mailing List , Linus Torvalds , Andrew Morton , Peter Zijlstra To: Paolo Bonzini Return-path: Content-Disposition: inline In-Reply-To: <541ADFEB.6030801@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: kvm.vger.kernel.org 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. -- Regards/Gruss, Boris. --