From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on
	aws-us-west-2-korg-lkml-1.web.codeaurora.org
Received: from vger.kernel.org (vger.kernel.org [23.128.96.18])
	by smtp.lore.kernel.org (Postfix) with ESMTP id ACC8BEB64D7
	for <linux-kernel@archiver.kernel.org>; Wed, 21 Jun 2023 13:19:41 +0000 (UTC)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S231834AbjFUNTk (ORCPT <rfc822;linux-kernel@archiver.kernel.org>);
        Wed, 21 Jun 2023 09:19:40 -0400
Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50438 "EHLO
        lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S231134AbjFUNTh (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 21 Jun 2023 09:19:37 -0400
Received: from xry111.site (xry111.site [89.208.246.23])
        by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2E5E3E72
        for <linux-kernel@vger.kernel.org>; Wed, 21 Jun 2023 06:19:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xry111.site;
        s=default; t=1687353576;
        bh=h6D1oWxliIEGx0hamqvBgdIL8Yifhe5fhqBA/YQTfnQ=;
        h=Subject:From:To:Cc:Date:In-Reply-To:References:From;
        b=Q/EOGTLF0eEnQ6UK8N15G7+DEJu8umFvvRckgLxBsVu3L+sFQtrhyrIypRBTuWWBF
         xDyCbWFk9yW+4jjCvWD+SfTGRyGvPIKSCZm0pf/y909N9BS0i8+YfBq9/cOkfQ8wW+
         x2wWYHEKEDXmf0viJdQZ4vmQcEFOrPgm8dVNSySA=
Received: from localhost.localdomain (xry111.site [IPv6:2001:470:683e::1])
        (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
         key-exchange ECDHE (P-256) server-signature ECDSA (P-384) server-digest SHA384)
        (Client did not present a certificate)
        (Authenticated sender: xry111@xry111.site)
        by xry111.site (Postfix) with ESMTPSA id ED09065EBF;
        Wed, 21 Jun 2023 09:19:35 -0400 (EDT)
Message-ID: <29beee7faf370ea892cb4e5a85ddd1f7ee132164.camel@xry111.site>
Subject: Re: A question about prefetchw detection in "x86/asm: Cleanup
 prefetch primitives"
From:   Xi Ruoyao <xry111@xry111.site>
To:     Borislav Petkov <bp@alien8.de>
Cc:     x86@kernel.org, linux-kernel@vger.kernel.org,
        Thomas Gleixner <tglx@linutronix.de>
Date:   Wed, 21 Jun 2023 21:19:34 +0800
In-Reply-To: <20230621130955.GHZJL2o771lIEPURUl@fat_crate.local>
References: <0b663d8f6802e8dbf443397718234bcb6d0811c8.camel@xry111.site>
         <20230621111346.GFZJLbavDw1JiLi34n@fat_crate.local>
         <a155ebb791d3aefce5db32658e3c519a1cfac1f6.camel@xry111.site>
         <e76180a1b82d1c29715587e94e2d6923b64bb893.camel@xry111.site>
         <20230621125749.GGZJLzzUw0rA3goV1X@fat_crate.local>
         <b50735128c5a985634468d63fef092f093f0aebc.camel@xry111.site>
         <20230621130955.GHZJL2o771lIEPURUl@fat_crate.local>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.48.3 
MIME-Version: 1.0
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, 2023-06-21 at 15:09 +0200, Borislav Petkov wrote:
> On Wed, Jun 21, 2023 at 09:06:51PM +0800, Xi Ruoyao wrote:
> > I think it's not an issue in the kernel itself, but announcing
> > 3dnowprefetch in /proc/cpuinfo for an old Intel CPU w/o real prefetchw
> > implementation seems problematic (to me).
>=20
> And this is a problem because?

If a code generator parses /proc/cpuinfo for CPU capabilities, it may
generates a no-op prefetchw instead of prefetcht0 as a fallback.

>=20
> Think practically.
>=20

--=20
Xi Ruoyao <xry111@xry111.site>
School of Aerospace Science and Technology, Xidian University