Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 14 Jul 2022 13:05:47 -0700
From:   Ira Weiny <ira.weiny@intel.com>
To:     Dan Williams <dan.j.williams@intel.com>
CC:     Bjorn Helgaas <bhelgaas@google.com>,
        Jonathan Cameron <Jonathan.Cameron@huawei.com>,
        Ben Widawsky <bwidawsk@kernel.org>,
        "Alison Schofield" <alison.schofield@intel.com>,
        Lukas Wunner <lukas@wunner.de>,
        Vishal Verma <vishal.l.verma@intel.com>,
        Dave Jiang <dave.jiang@intel.com>,
        <linux-kernel@vger.kernel.org>, <linux-cxl@vger.kernel.org>,
        <linux-pci@vger.kernel.org>
Subject: Re: [PATCH V13 8/9] cxl/port: Retry reading CDAT on failure
Message-ID: <YtB3GySfcm5CfG01@iweiny-desk3>
References: <20220705154932.2141021-1-ira.weiny@intel.com>
 <20220705154932.2141021-9-ira.weiny@intel.com>
 <62d043d8bd04c_16fb9729422@dwillia2-xfh.jf.intel.com.notmuch>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <62d043d8bd04c_16fb9729422@dwillia2-xfh.jf.intel.com.notmuch>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?GUgGjLR72g5wgNMdpmy9PbVJNHdWCLNimU9i1ufUzVtwqTY3J4rom+6ss6HJ?=
 =?us-ascii?Q?EoA6jJnLMF1WyRtjfA7pUIJcfrH3zz46SczQIrYQ1Yf/GwtTe7uobKpeJ7sT?=
 =?us-ascii?Q?Hajk6dJvDIFUQBQRGpU8t1YrjdGR68uZbrmhNX4NYGK+AhyPynm9MTFFFGvw?=
 =?us-ascii?Q?St/+4vkUYJTuYjoEogz90p1q1tu1XTDr/QCvLJWWawlv053I+O2e5Jp0AihH?=
 =?us-ascii?Q?1qq2CpXTb1eNA25HjJ8o4Esa0VaEkKpare9700K+d57Qj0DUC+djC81xDO/u?=
 =?us-ascii?Q?fsC8v/B2ib7BpXXQm78eOeKc3NFvaOzNPv9dXnu7J4jtG6zKU6oEZPxv24hE?=
 =?us-ascii?Q?lKkKlAkM/SHI//zRKPI6GCtv+hgwkyy9COQ97fis2MmKyy1HXljSyOjmAKK+?=
 =?us-ascii?Q?I4weTDOFqIO7Xv3BxZAKf+EC3KJul7SfbP7vbwbczOICO816N+niaR5r8P4g?=
 =?us-ascii?Q?MO/i3pvngrTlLJWWUFdO8xEhDM8rXvEhJ5i45m9vX9W2tQprIz4FVyeaXDyN?=
 =?us-ascii?Q?6hPkk8H8dpyn76esv632g6MhokVswUtoFO/jCz8/fo+MDwv4vHNosbAL0saP?=
 =?us-ascii?Q?/VkYQUKpHlUXpOoVbmx/XF9H/De/mi0A/ZhS7JM7vMJCwXwqSstTfFhOV9Ft?=
 =?us-ascii?Q?2QO3D7a1n51OSuhwxkkmOMqP9MJeuUPlo6LHh+eQr6W2vPrGvu/vZi4x0rQy?=
 =?us-ascii?Q?e8rENYt8F461S2zSbSdwUiqXaUJQnYPb4aeIGKL+eJDSwM3fgmDDKQFuUb99?=
 =?us-ascii?Q?MkDgkqSxTt8xPFiE4lxcMskiT57u0smBnKxoX5Cq2sVhE1ses/iurtpEB44b?=
 =?us-ascii?Q?YAOs97gegJ/UbeEkE1WVjghcSq76l46WqChV67RCeXo2UnhU/DOaxJeGZSPn?=
 =?us-ascii?Q?9jYFzO7oh9LxKKcdzrvnUc/LtlV5IUF6JrV6iAILLCCxbk9KPOZO0eY6JCNm?=
 =?us-ascii?Q?HeVgN05PQA5Ya+ybshUYlq+5UmEOk01Tt/pS+vzh/jRJll+mkyxiqujAk6bB?=
 =?us-ascii?Q?dJgbPm9csRoYo9P9B9hrvXhbWCbMK95oiqIfZVHAnkdBLrbHJYsg2ePOCrVF?=
 =?us-ascii?Q?YmOz8yeTOglwVkf4OL5q0WLwON5Z0THGsbKMzZO/xR2y+ne+7Uwq3nxyGETX?=
 =?us-ascii?Q?cm/EZtTJn5qXPe2E/HeFZtpLq8RGE86DBSpg5ri5GeTtAEC/eB1s1P60Y2uk?=
 =?us-ascii?Q?Fz3FKwz19YTj3xOYgmwhKFSOOexWZINdvJBZ7O5vztl8CuZfatsFyt51aXue?=
 =?us-ascii?Q?5wXS/HVJ0VEWjVweUryKVGFb+wiZh9+rlWrwb55/zbLrJFCXu53sw5mIrASG?=
 =?us-ascii?Q?8vCyEmXSF3M1lqGuqYijApuQcfOKMo8csTugJqMEZogEF471A6fcp6ckFWFy?=
 =?us-ascii?Q?qIsb5scKivUnGParGSlRHiSWnRQeIaYAoWZHLn4pC8JHUJKfDy06VrDyJ5Lr?=
 =?us-ascii?Q?oGWcOdy3d0Y+bfJIw8mDvXBZChXLO0OUhGhA0amEX2LQySmoPRwbkEnT4rmi?=
 =?us-ascii?Q?2/ZhuIwqcI96Dz5mTwmoaarDsBXUEdQqt6sOR0CJFcmTLjbXo6+tuim7Fvwu?=
 =?us-ascii?Q?sy6OScOp2AzMi7eDL9nDNMHWxlDTheFbebzrD51TfDy/jBiRYjyLBlrRm9Ej?=
 =?us-ascii?Q?WTUV94fwfcBjys1YeJa6vRfo5nuso+Ybgw+fcT9/lqZw?=
X-MS-Exchange-CrossTenant-Network-Message-Id: e906963e-90f3-43f2-bc1b-08da65d44196
X-MS-Exchange-CrossTenant-AuthSource: DM4PR11MB6311.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jul 2022 20:05:53.5309
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: gG0sQe8J9v9Su7ku9/S0Wsx+LV15A4sPn6IqCRsrssV7WY9Vd5d6Tt7ermGFrhE06wI5kTrwKAVv/fPH8QUd1Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3854
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-5.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Thu, Jul 14, 2022 at 09:27:04AM -0700, Dan Williams wrote:
> ira.weiny@ wrote:
> > From: Ira Weiny <ira.weiny@intel.com>
> > 
> > The CDAT read may fail for a number of reasons but mainly it is possible
> > to get different parts of a valid state.  The checksum in the CDAT table
> > protects against this.
> 
> I don't know what "different parts of a valid state" means.

This text is stale but given what I know about how other entities may be
issuing queries without the kernel knowledge I'm not 100% sure that the data
read back will always be valid.

Regardless, this has already caught a bug in QEMU.

So I'm inclined to leave this check in because the checksum is there and should
can be validated if only to detect broken hardware.

I can update the commit message to clarify this.

Ira

>
> The CDAT
> should not be changing as it is being read unless someone is issuing a
> set-partition while the DOE operation is happening. Rather than
> arbitrary retries, block out set-partition while CDAT is being read.
> 
> You can use {set,clear}_exclusive_cxl_commands() to temporarily lock out
> set-partition while the CDAT read is happening.
> 
> ...and since this series is only for enabling