From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ua1-f45.google.com (mail-ua1-f45.google.com [209.85.222.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3384030674B for ; Tue, 23 Jun 2026 17:01:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.222.45 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782234083; cv=none; b=Z+JibK4wfls2FW7+GDTWNDQfouUVZGMhwIXyIgLu2dyfwg9w6AkQkqMUC400PP5oww5jSlaT4KaIOIK8pLLpLnQcI0Bzr+ePOE0RzroNiwqHWeVG0mpxPjEoCpeVRmoMHBJwT5aJt6OKGc7p34A5PO2IOvQLqDJjVxpkHlSpLPM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1782234083; c=relaxed/simple; bh=drTPL+/4sCDq7xFfebBhZN9MFM/p9D5us+A1LEs9MHg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=nAmKxdOI92IDzrhVbY6X2XougqxkyZaUqP/SfUfxnifX9WR8SbxGkKzNrxE+PWOsOzIMR7GSS1OHKeUZTKPxzXCwJNOvsiqXI7dgX2M71+WSIYt/ESMlp7HK+v3zM95GPwIgzghj2ANmG1mbN4yN0ttpb1XoeRn7toPBMpgKciw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net; spf=pass smtp.mailfrom=gourry.net; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b=FEqdijxc; arc=none smtp.client-ip=209.85.222.45 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=gourry.net Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gourry.net Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gourry.net header.i=@gourry.net header.b="FEqdijxc" Received: by mail-ua1-f45.google.com with SMTP id a1e0cc1a2514c-966df39a092so16262241.1 for ; Tue, 23 Jun 2026 10:01:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1782234081; x=1782838881; darn=vger.kernel.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=xvgEVwQ8jfCIcJ0ba/B6osmLE2ZzPQbQhunldQ5OJKk=; b=FEqdijxcJOXaYeegZW2MMFnBE3mkI8rzXD59lYgpIOwGvh61Rxt5ZrGQkDxfwNrQMU HCA/HAzLxUOmTEFCUMaNlwAdjQxTZF/MX522fK+P9nZeJ9w1xfFm3FLXLTsatuaSjRV/ RE16PEHWdBvXn/LdxQGn1xMgVKVW4A/6nAP4Nl7ZpyqOy1ii/YeVIzc15XbI7Ck+BpMC o6aakjzyiDANXbMf+h7k52ij+lguBMw4AAvDw1qPvn8u1VyOYEx5lljp6XwM4MTWK1XY T0o+uz2L6/HLDCu9b0DIxT6ssCMJm4u99VP0B0GQ6BJz1kmYTj7vCpZM+xAvpMb5SQSG 8rFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1782234081; x=1782838881; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=xvgEVwQ8jfCIcJ0ba/B6osmLE2ZzPQbQhunldQ5OJKk=; b=Us+Imrxi68xXIcJjripaObAriHq5kAG9NMi+YVanbMcqObOUYirLHu7aUZ6ZTW0rcS poIexLFs0AOQt4nrt2gAGccrSLy7QmvfKZ4R0RF+ceW3CiRCmHgMOzSfaewjPD05lCLK vTYXh92EkagMA0u4Ci+v5QtLKuaaxrMQzRMSP8yjzb65LJFTjXtCTIDHU2AcMNXth8Q2 yOyNLOTueVWyDtWjPnut0on/wy+7gt1M2eny7cw8KZzBIV2Lk27pDOgkaLJvxHzzlYjW EKExuegPAGjVGyQ8eYc0/wzOOT3/9vOIjMo6txQY0TSJ2O13Hs/x8eoAg14EFYx5vZMf 5S0w== X-Forwarded-Encrypted: i=1; AFNElJ9nIQXvg6sIqxhKnHm7+x8x0lLo/QG4a6wUWwz+jTyL70NLDLk/t+IJjjY/tX/GqXzzcuK7TAcjvraUlzI=@vger.kernel.org X-Gm-Message-State: AOJu0Yz6khQnu0UdVDIw+m8ffAW547uUTFiWjNWBgldnTQO6XhLQMOmq QHoGmGjQmFr8xBCG+n9oo6Tk1J0r75VEuNvlwqJoMxsVeluBsKHQ2lCmq/qPju5lsC8= X-Gm-Gg: AfdE7clO8jzh22Jc6Xm2ZSSzsCaHaBZ8Es26Cmf2/luTq9i51W9bdpv0SA9bEnY9Upt YSviDdexZR9WIQTmycpVAaeBO6DSKr3knzYdIFNin0rsBM3iiJvi2YwiiF8yFIqrCbw5MBEX6j8 mdUrpZWJ/gd3CX0KE8E9t4EmCQmm+MmT1pBDiuKvL+caWDLYxGrwVI6RCt3FEwWYIf3pMoqTd+Y I5bJ/uq/j7OVsU4Ig80a+Zh+s/aY+jmYkL3Y3MeUNLQtP31TSRCEM2AMxoNMs+LNx2PjTPEx2BO s9sMV5L3HydW1VS+ajRiotr9aMdQa0jfHQixafTMtPAqFV8N7NqyG4Qg4NkocbgeREZix+zM8fm WrTG0uDEsTJ/eg7EkXpZRpHyiuYUBdfJ1mIl5CJQjAMZtnD/YwUXdZp5nX2HU4NQKbJhq0Z8CiC h+5EO3luAJC1rsRQbNTk4neqK00nbd6Y+9+19IanXPhGg+Yza4D8QIb+qHB8F/bzjoEl8Y X-Received: by 2002:a05:6102:8089:b0:631:e729:4575 with SMTP id ada2fe7eead31-72ff3f7fea1mr2054044137.5.1782234074396; Tue, 23 Jun 2026 10:01:14 -0700 (PDT) Received: from gourry-fedora-PF4VCD3F (pool-173-79-60-52.washdc.fios.verizon.net. [173.79.60.52]) by smtp.gmail.com with ESMTPSA id af79cd13be357-9260079070bsm327795185a.40.2026.06.23.10.01.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Jun 2026 10:01:13 -0700 (PDT) Date: Tue, 23 Jun 2026 13:01:09 -0400 From: Gregory Price To: "Dan Williams (nvidia)" Cc: Richard Cheng , dave@stgolabs.net, jonathan.cameron@huawei.com, dave.jiang@intel.com, alison.schofield@intel.com, vishal.l.verma@intel.com, ira.weiny@intel.com, dan.j.williams@intel.com, linux-cxl@vger.kernel.org, linux-kernel@vger.kernel.org, newtonl@nvidia.com, kristinc@nvidia.com, kaihengf@nvidia.com, kobak@nvidia.com, vaslot@nvidia.com, smadhavan@nvidia.com Subject: Re: [PATCH v4 0/2] Support zero-sized HDM decoders Message-ID: References: <20260607081345.61954-1-icheng@nvidia.com> <6a289e3665fc5_4fa78100b1@djbw-dev.notmuch> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6a289e3665fc5_4fa78100b1@djbw-dev.notmuch> On Tue, Jun 09, 2026 at 04:13:58PM -0700, Dan Williams (nvidia) wrote: > Richard Cheng wrote: > > Hello, > > > > This v4 continues Vishal Aslot's "Support zero-sized decoders" series [1] > > and addresses the v3 review of patch 1's port->hdm_end handling [2]. > > > > CXL r3.2 §8.2.4.20.12 and §14.13.10 permit committing an HDM decoder with > > size 0. BIOS commits and LOCKs such decoders to burn the trailing, unused > > slots so the OS cannot program regions through them, e.g. a Type 3 device > > in a Trusted Computing Base (TCB) established via the Trusted Security > > Protocol (TSP). init_hdm_decoder() rejected these with -ENXIO during port > > enumeration and aborted the whole port, so affected systems showed nothing > > under 'cxl list'. > > > > Patch 1 enumerates the decoder into the topology with its HW-reported LOCK > > state and skips the DPA reservation it does not need. > > > > On port->hdm_end (the v3 review): v3 advanced the watermark for the > > zero-size decoder. sashiko correctly noted the write was outside > > cxl_rwsem.dpa, and that advancing it without a balanced release strands > > hdm_end -- cxl_dpa_free() returns early on !dpa_res, so it can never be > > decremented past the zero-size id, breaking LIFO teardown of lower > > decoders. v4 therefore does not touch hdm_end at all. The in-order check > > in __cxl_dpa_reserve() is its only consumer and is never legitimately > > reached past such a decoder: the burned slots are trailing, so enumeration > > reserves no committed decoder after one, and the OS must not program a > > region through a locked slot. hdm_end stays at the last sized reservation, > > which is accurate. IMHO, if a non-trailing zero-size layout ever needs > > support, the check should key off commit_end rather than hdm_end, > > out of scope here. > > I am not comfortable with this outcome. It assumes that zero-sized > decoders are always committed. I would much rather keep the meaning of > hdm_end as the marker of the last decoder set aside for a reservation. > (pre: before a program[mable] decoder, post: after ...) Pre-locked zero-sized decoders *must* be committed if the non-zero decoders are programmable. Post-locked zero-sized committed decoders *are not legal* if the non-zero decoders are programmable. They can only be legal IFF the entire device came up with decoders programmed and locked. Violating either condition implies an out of order commit has occurred, and trying to deal with zero-sized decoders as a special class is just a giant footgun. Covered this here: https://lore.kernel.org/linux-cxl/aPeSqjqU6BH9gvcw@gourry-fedora-PF4VCD3F/ https://lore.kernel.org/linux-cxl/aYynWqJ7u-v-6WsZ@gourry-fedora-PF4VCD3F/ So,I agree that zero-sized decoders can't be assumed to be committed. Consider this case: Pre-lock Post-lock decoder 0 1 2 ... N ------------------------------------------------------------------ [zero-lock] [programmed] [zero-lock] [zero-lock] ^ must be committed ^ must not be committed unless D1 is locked Anyway, agree, zero-sized decoders cannot be assumed to always be commited, and the spec (or at least my last reading) leaves it ambiguous what state a zero-sized decoder must be in. ~Gregory