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=-9.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS autolearn=ham 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 47FBEC43461 for ; Tue, 15 Sep 2020 02:02:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 18908207EA for ; Tue, 15 Sep 2020 02:02:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726086AbgIOCCS (ORCPT ); Mon, 14 Sep 2020 22:02:18 -0400 Received: from mga04.intel.com ([192.55.52.120]:57935 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726046AbgIOCCR (ORCPT ); Mon, 14 Sep 2020 22:02:17 -0400 IronPort-SDR: mtWpU4FbjHtKRRTOIFmLcYysRCsfg5yo7FFY59XklTmAxPHr8Fnd5mk05iZsu/YOyrA0eiRs86 DxLJyeN83HbA== X-IronPort-AV: E=McAfee;i="6000,8403,9744"; a="156580196" X-IronPort-AV: E=Sophos;i="5.76,427,1592895600"; d="scan'208";a="156580196" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Sep 2020 19:02:16 -0700 IronPort-SDR: N/Yz5aGcM6gsT2R3Poqs+0dJtTuuU+23RLSREefvakHjlB+NAFAaosxh7IeD8BOoc4ThbYgQNg 42zOt3Ujv1Dg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.76,427,1592895600"; d="scan'208";a="330979588" Received: from otcwcpicx6.sc.intel.com ([172.25.55.29]) by fmsmga004.fm.intel.com with ESMTP; 14 Sep 2020 19:02:14 -0700 Date: Tue, 15 Sep 2020 02:02:14 +0000 From: Fenghua Yu To: Randy Dunlap Cc: Fenghua Yu , Thomas Gleixner , Ingo Molnar , Borislav Petkov , H Peter Anvin , Andy Lutomirski , Jean-Philippe Brucker , Christoph Hellwig , Peter Zijlstra , David Woodhouse , Lu Baolu , Dave Hansen , Tony Luck , Ashok Raj , Jacob Jun Pan , Dave Jiang , Sohil Mehta , Ravi V Shankar , linux-kernel , x86 , iommu@lists.linux-foundation.org Subject: Re: [PATCH v7 3/9] docs: x86: Add documentation for SVA (Shared Virtual Addressing) Message-ID: <20200915020214.GA437862@otcwcpicx6.sc.intel.com> References: <1598540794-132666-1-git-send-email-fenghua.yu@intel.com> <1598540794-132666-4-git-send-email-fenghua.yu@intel.com> <626fe21c-1f82-f4f8-e37b-32d91e7d557a@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <626fe21c-1f82-f4f8-e37b-32d91e7d557a@infradead.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Randy, On Sat, Sep 05, 2020 at 10:54:59AM -0700, Randy Dunlap wrote: > Hi, > > I'll add a few edits other than those that Borislav made. > (nice review job, BP) > > > On 8/27/20 8:06 AM, Fenghua Yu wrote: > > From: Ashok Raj > > > > ENQCMD and Data Streaming Accelerator (DSA) and all of their associated > > features are a complicated stack with lots of interconnected pieces. > > This documentation provides a big picture overview for all of the > > features. > > > > Signed-off-by: Ashok Raj > > Co-developed-by: Fenghua Yu > > Signed-off-by: Fenghua Yu > > Reviewed-by: Tony Luck > > --- > > diff --git a/Documentation/x86/sva.rst b/Documentation/x86/sva.rst > > new file mode 100644 > > index 000000000000..6e7ac565e127 > > --- /dev/null > > +++ b/Documentation/x86/sva.rst > > @@ -0,0 +1,254 @@ > > +MMIO. This doesn't scale as the number of threads becomes quite large. The > > +hardware also manages the queue depth for Shared Work Queues (SWQ), and > > +consumers don't need to track queue depth. If there is no space to accept > > +a command, the device will return an error indicating retry. Also > > +submitting a command to an MMIO address that can't accept ENQCMD will > > +return retry in response. In the new DMWr PCIe terminology, devices need to > > so how does a submitter know whether a return of "retry" means no_space or > invalid_for_this_device? I will add "A user should check Deferrable Memory Write (DMWr) capability on the device and only submits ENQCMD when the device supports it." So the user doesn't need to distinguish "no space" and "invalid for this device" errors. All of your other comments will be addressed in the next version. Thank you very much for your comments! -Fenghua