From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.7 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 32A61C432C0 for ; Fri, 22 Nov 2019 18:50:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 080EA2071F for ; Fri, 22 Nov 2019 18:50:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=intel-com.20150623.gappssmtp.com header.i=@intel-com.20150623.gappssmtp.com header.b="wNWvzpq8" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726739AbfKVSuV (ORCPT ); Fri, 22 Nov 2019 13:50:21 -0500 Received: from mail-oi1-f193.google.com ([209.85.167.193]:42624 "EHLO mail-oi1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726695AbfKVSuV (ORCPT ); Fri, 22 Nov 2019 13:50:21 -0500 Received: by mail-oi1-f193.google.com with SMTP id o12so7373202oic.9 for ; Fri, 22 Nov 2019 10:50:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NlbK6M2z9ltXCoUKRaVfCXvYkLVUjdiU4+HuMpNbpQg=; b=wNWvzpq8RdrJh/AB6vzVJgUewGsTxXi8gR2TG33WhKYr3TzWXA1NyVJH6OPeO6Sanm YR765U2kewKlhS4IV5T0ItUvs7SSnzYSTFqoDKch24edp5xBc6l5i1VgR8QA3epPUSZo 7o82Sc0xvI8kr7+cMe9KQ2E1vqQ7/xyPRc5W9StSudpIpywbIe3pC4uV9Vws7fzCPuym w6B8Qnv4OUGFNY6ILB2Socr0F3ePoII0gtlkmN+6cApdXU23F3tnZBBUREsFYKkIcoM8 88lw/MWTu0xz/q7o5Ho6X5RzWKg8nQPynqE0zYuhMbvtxjBeYpMlS87i1xERjNVU3Iqz L/Yw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NlbK6M2z9ltXCoUKRaVfCXvYkLVUjdiU4+HuMpNbpQg=; b=VZkr4Xtf/Uq/xxs6x3GeT/W04tdwxtpqjqw7wfNvq9RcKL5X9KNl57q2GnPSeYTmAf jBDWQAq171Ogdk5nnAdMg700VIO7zANu7Wh00g8ukgbTnSnrE3wKLPZoAU7OlAQznR38 aBkjL/4qba8eUzH/FH7mTjbZefgGHH4cjgaX6gmClXOSJHCJRSpAuad5T0HCrtYwg3Sk 5x9hhOxgd3K3smlx5GoBCukwEyXTQ5Nai7Sid7eBVTyU9Xyk5fYMI4PW9GcCOTcBOHDU nOZeMxRvINbHoaHPk54TQxP518CShHzd6dPHZu4arAlVh1R3lV3LnPlbp5CB47Fth3lS w5MQ== X-Gm-Message-State: APjAAAXSuw4b4C+Duvkscd7uCHTTF7g21CvVd7e170BPwrWixtY52/eh aH90+TpV3gguN18z6q3QadsCkPIdoKhb4gPbSaX8eg== X-Google-Smtp-Source: APXvYqySehOWsAqojTbu0/A8KW/Rq26HXplYi2MqxivoxYZMqIIThFjA0LBNYoNGJIjvGcmZlQ3Y3/O1RhtUBqAq7dk= X-Received: by 2002:aca:55c1:: with SMTP id j184mr14267686oib.105.1574448620728; Fri, 22 Nov 2019 10:50:20 -0800 (PST) MIME-Version: 1.0 References: <157428480574.36836.14057238306923901253.stgit@djiang5-desk3.ch.intel.com> <157428502934.36836.8119026517510193201.stgit@djiang5-desk3.ch.intel.com> <20191120215338.GN2634@zn.tnic> <247008b5-6d33-a51b-0caa-7f1991a94dbd@intel.com> <20191121105913.GB6540@zn.tnic> <20191122085953.GA6289@zn.tnic> <20191122184435.GK6289@zn.tnic> In-Reply-To: <20191122184435.GK6289@zn.tnic> From: Dan Williams Date: Fri, 22 Nov 2019 10:50:09 -0800 Message-ID: Subject: Re: [PATCH RFC 01/14] x86/asm: add iosubmit_cmds512() based on movdir64b CPU instruction To: Borislav Petkov Cc: Dave Jiang , "dmaengine@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "vkoul@kernel.org" , "Luck, Tony" , "Lin, Jing" , "Raj, Ashok" , "Kumar, Sanjay K" , "Dey, Megha" , "Pan, Jacob jun" , "Liu, Yi L" , "axboe@kernel.dk" , "akpm@linux-foundation.org" , "tglx@linutronix.de" , "mingo@redhat.com" , "Yu, Fenghua" , "hpa@zytor.com" Content-Type: text/plain; charset="UTF-8" Sender: dmaengine-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: dmaengine@vger.kernel.org On Fri, Nov 22, 2019 at 10:44 AM Borislav Petkov wrote: > > On Fri, Nov 22, 2019 at 09:20:39AM -0800, Dan Williams wrote: > > For those cases the thought would be to have memset512() for case1 and > > __iowrite512_copy() for case3. Where memset512() writes a > > non-incrementing source to an incrementing destination, and > > __iowrite512_copy() copies an incrementing source to an incrementing > > destination. Those 2 helpers *would* have fallbacks, but with the > > option to use something like cpu_has_write512() to check in advance > > whether those routines will fallback, or not. > > > > That can be a discussion for a future patchset when those users arrive. > > Oh, sure, of course. > > My only angle is very simple: if the MOVDIR* et al is only supported on > upcoming Intel platforms and looking at the use cases: > > 1. clear poison/MKTME > 3. copy iomem in big chunks > > I'm going to venture a guess that those two cases are going to be > happening only on Intel platforms which already support MODVIR*. So > wouldn't really need to do any generic helpers because those use cases > are very specific already. Which would make your feature detection a > one-time, driver-init time thing anyway... > > Unless I misunderstand those cases and there really is a use case > where the thing would fallback and the fallback would really be for an > "unenlightened" platform without that MOVDIR* hw support...? At least for something like __iowrite512_copy() it would indeed be something an unenlightened driver could call. Those drivers would simply be looking for opportunistic efficiency and could tolerate a fallback. Just like current __iowrite64_copy() users don't care if that routine falls back internally.