mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: "Limonciello, Mario" <Mario.Limonciello@amd.com>,
	Dave Hansen <dave.hansen@intel.com>,
	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: Wed, 06 Apr 2022 03:44:18 +0200	[thread overview]
Message-ID: <87a6cz0yvh.ffs@tglx> (raw)
In-Reply-To: <BL1PR12MB515702C06E483DF4EB78A7ADE2E49@BL1PR12MB5157.namprd12.prod.outlook.com>

Mario,

On Tue, Apr 05 2022 at 20:40, Mario Limonciello wrote:

> [Public]

Really useful information that your post is public while some of the
earlier posts in this _public_ thread were marked '[AMD confidential]'.

>> >> This seem _bit_ at odds with the commit message (and the AMD SSBD
>> >> whitepaper):
>> >>
>> >>>     Add the necessary synchronization logic for AMD family 17H.
>> >> So, is X86_FEATURE_ZEN for family==0x17, or family>=0x17?
>> > There are Zen family CPUs and APUs from family 0x19.  Perhaps at the
>> > time of the whitepaper there weren't yet though.
>> 
>> Is this a gap in the documentation, then?  Is there some documentation
>> of the availability of SSBD mitigations on family 0x19?
>
> It looks like a misinterpretation of the document.

Not at all. The document does not mention family 19h at all. So where is
the misinterpretation?

Dave was asking for documentation for family 0x19, right?

> Notice it mentions in Non-architectural MSRs explicitly:
>
> "some models of family 17h have logic that allow loads to bypass older stores 
> but lack the architectural SPEC_CTRL or VIRT_SPEC_CTR"

That's relevant to Dave's question in which way? 

> But that is not for all family 17h nor for family 19h.  You can see earlier in
> the document the method to detect presence for SSBD which applies to the
> rest of 17h and 19h.

We know how to read this document. But this document does not mention
anything else than family 17h. So what are you talking about?

> That code in amd_set_core_ssb_state is only used for one of the
> mitigation codepaths without MSR support, not for all Zen CPUs.

Again, how is that relevant to the legitimate question whether that
document applies to family 17h only or to 17h+ which includes 19h?

We need to make a decison about what X86_FEATURE_ZEN means. Is it that
hard to give an authoritive answer?

Thanks,

        tglx

  reply	other threads:[~2022-04-06 16:29 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-05 13:00 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 [this message]
2022-04-06 14:23             ` Limonciello, Mario
2022-04-07 21:16               ` Dave Hansen
2022-04-08  1:24                 ` Limonciello, Mario
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=87a6cz0yvh.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=Ananth.Narayan@amd.com \
    --cc=Lewis.Carroll@amd.com \
    --cc=Mario.Limonciello@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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®