All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paolo Bonzini <pbonzini@redhat.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Nadav Amit <namit@cs.technion.ac.il>,
	Ingo Molnar <mingo@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
	Ingo Molnar <mingo@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	the arch/x86 maintainers <x86@kernel.org>,
	kvm <kvm@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [RESEND PATCH 1/3] x86: Adding structs to reflect cpuid fields
Date: Fri, 19 Sep 2014 15:40:29 +0200	[thread overview]
Message-ID: <541C324D.2080608@redhat.com> (raw)
In-Reply-To: <20140919075814.GA30491@nazgul.tnic>

Il 19/09/2014 09:58, Borislav Petkov ha scritto:
>> > 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.

And similarly, Intel would not extend a bit from 16 to 17 bits if it
weren't zero on all older processors.

> 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.

Once that bit gets a meaning in newer processors, the same meaning will
work retroactively for existing processors.  That's just how CPUID is
used.  Nobody checks families before testing bits, Intel/AMD do not even
suggest that.

> Do you have a guarantee that this won't happen in the future and break
> all your fancy bitfields assumptions?

No guarantee, but were that to happen, I'd expect tar and feathers
spectacles around Intel's engineering headquarters.

Paolo

  parent reply	other threads:[~2014-09-19 13:41 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-16 12:22 [PATCH 0/3] x86: structs for cpuid info in x86 Nadav Amit
2014-09-16 12:22 ` [PATCH 1/3] x86: Adding structs to reflect cpuid fields Nadav Amit
2014-09-16 12:22 ` [PATCH 2/3] x86: Use new cpuid structs in cpuid functions Nadav Amit
2014-09-16 12:22 ` [PATCH 3/3] KVM: x86: Using cpuid structs in KVM Nadav Amit
2014-09-16 13:22 ` [PATCH 0/3] x86: structs for cpuid info in x86 Ingo Molnar
2014-09-16 20:19   ` Nadav Amit
2014-09-17 12:37     ` Ingo Molnar
2014-09-17 12:45       ` Borislav Petkov
2014-09-17 12:54         ` [RESEND PATCH " Nadav Amit
2014-09-17 12:54           ` [RESEND PATCH 1/3] x86: Adding structs to reflect cpuid fields Nadav Amit
2014-09-17 13:21             ` Borislav Petkov
2014-09-17 13:53               ` Nadav Amit
2014-09-17 14:06                 ` Borislav Petkov
2014-09-17 15:04                   ` Radim Krčmář
2014-09-17 15:22                     ` Borislav Petkov
2014-09-18  0:29                       ` Radim Krčmář
2014-09-18  7:19                         ` Borislav Petkov
2014-09-18 10:00                           ` Radim Krčmář
2014-09-18 13:06                   ` Paolo Bonzini
2014-09-18 13:26                     ` Borislav Petkov
2014-09-18 13:36                       ` Paolo Bonzini
2014-09-19  7:58                         ` Borislav Petkov
2014-09-19  8:59                           ` Nadav Amit
2014-09-19 10:32                             ` Borislav Petkov
2014-09-19 13:40                           ` Paolo Bonzini [this message]
2014-09-19 14:44                             ` Borislav Petkov
2014-09-17 14:10             ` Peter Zijlstra
2014-09-17 12:54           ` [RESEND PATCH 2/3] x86: Use new cpuid structs in cpuid functions Nadav Amit
2014-09-17 12:54           ` [RESEND PATCH 3/3] KVM: x86: Using cpuid structs in KVM Nadav Amit
2014-09-17 14:12       ` [PATCH 0/3] x86: structs for cpuid info in x86 Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=541C324D.2080608@redhat.com \
    --to=pbonzini@redhat.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=namit@cs.technion.ac.il \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.