All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Limonciello, Mario" <Mario.Limonciello@amd.com>
To: Dave Hansen <dave.hansen@intel.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	"Karny, Wyes" <Wyes.Karny@amd.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"Carroll, Lewis" <Lewis.Carroll@amd.com>,
	"Shenoy, Gautham Ranjal" <gautham.shenoy@amd.com>,
	"Narayan, Ananth" <Ananth.Narayan@amd.com>,
	"Rao, Bharata Bhasker" <bharata@amd.com>,
	"len.brown@intel.com" <len.brown@intel.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"bp@alien8.de" <bp@alien8.de>,
	"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"chang.seok.bae@intel.com" <chang.seok.bae@intel.com>,
	"keescook@chromium.org" <keescook@chromium.org>,
	"metze@samba.org" <metze@samba.org>,
	"zhengqi.arch@bytedance.com" <zhengqi.arch@bytedance.com>,
	"mark.rutland@arm.com" <mark.rutland@arm.com>
Subject: RE: [PATCH] x86: Prefer MWAIT over HALT on AMD processors
Date: Fri, 8 Apr 2022 01:24:15 +0000	[thread overview]
Message-ID: <BL1PR12MB5157E978932A02865541D319E2E99@BL1PR12MB5157.namprd12.prod.outlook.com> (raw)
In-Reply-To: <7a95b837-e347-0ad3-3a2c-f347f12d6625@intel.com>

[Public]

> 
> I don't want to give you too hard of a time on this.  But, that's not
> architecture, that's just telling folks what the implementation is on
> *one* CPU model.  Don't get me wrong: these model-specific docs are
> great, and I wish Intel published something like that.
> 
> But, the code as written depends on behavior for *all* of family 0x19:
> 
> >         case 0x17: fallthrough;
> >         case 0x19: init_amd_zn(c); break;
> 
> So, while the docs for "family 19h model 01h" are *consistent* with this
> code, there's also nothing preventing the docs for "family 19h model
> 02h" from breaking this new MWAIT code.
> 
> Now, AMD is full of smart folks that aren't going out of their way to
> try and break existing software.  But, actual documentation of the
> *architecture* is really preferable to what we have now.  It helps
> establish a shared hardware/software contract that keeps both sides honest.

Point taken.  As you're probably aware releasing documentation is never a quick
process, but Lewis and Wyes can take this to the powers that be internally to see
what can be done for the future.

> 
> What's missing is something that says:
> 
> 	All AMD family 0x17 and 0x19 that enumerate support for MWAIT
> 	also support this "early MWAIT" implementation
> 
> That represents a promise from AMD that this can't break in the future.
>  It both gives us something unambiguous to write code with *and*
> something to help nudge our hardware and microcode colleagues if they
> start to do something funny in the future.
> 
> Just having that in the changelog would be fine, and a genuine
> improvement over what we have now.  Having it one of the
> model-independent architecture manuals would be even better.

OK... I think the commit message and/or a comment is doable in the short
term for v2.

  reply	other threads:[~2022-04-08  1:24 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-05 13:00 [PATCH] x86: Prefer MWAIT over HALT on AMD processors Wyes Karny
2022-04-05 14:05 ` Borislav Petkov
2022-04-05 20:26   ` Carroll, Lewis
2022-04-05 20:38     ` Borislav Petkov
2022-04-05 21:49       ` Carroll, Lewis
2022-04-06  9:30         ` Borislav Petkov
2022-04-06  6:14   ` Wyes Karny
2022-04-06  9:25     ` Borislav Petkov
2022-04-05 14:07 ` Peter Zijlstra
2022-04-05 15:10   ` Dave Hansen
2022-04-05 15:34     ` Limonciello, Mario
2022-04-05 15:47       ` Dave Hansen
2022-04-05 20:40         ` Limonciello, Mario
2022-04-06  1:44           ` Thomas Gleixner
2022-04-06 14:23             ` Limonciello, Mario
2022-04-07 21:16               ` Dave Hansen
2022-04-08  1:24                 ` Limonciello, Mario [this message]
2022-04-14 21:06                   ` Limonciello, Mario
2022-04-07  2:19   ` Wen Pu

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=BL1PR12MB5157E978932A02865541D319E2E99@BL1PR12MB5157.namprd12.prod.outlook.com \
    --to=mario.limonciello@amd.com \
    --cc=Ananth.Narayan@amd.com \
    --cc=Lewis.Carroll@amd.com \
    --cc=Wyes.Karny@amd.com \
    --cc=bharata@amd.com \
    --cc=bp@alien8.de \
    --cc=chang.seok.bae@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=gautham.shenoy@amd.com \
    --cc=hpa@zytor.com \
    --cc=keescook@chromium.org \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=metze@samba.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=zhengqi.arch@bytedance.com \
    /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.