From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f177.google.com (mail-qt1-f177.google.com [209.85.160.177]) (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 C34643D6495 for ; Wed, 21 Jan 2026 23:13:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.177 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769037196; cv=none; b=R1qzW5NZ8vXECcYUjHDPKAObgt6y8ahoOJEc9PebRUwEIfAXJJk2gTGZ+CuWxyFnMWuhI97N9VvvUd9dinKfnNmOiGrQRRLY+y5BM7oPz4sajANuRoIOhu2dirqBxfWqpCo1iNXLI7NJ8cKJ/AmcGrt6knDkMyzre1v13lE5m3I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769037196; c=relaxed/simple; bh=JKWGv2QBEpr9NraO7c0DMd4m2jNrvXSOqOxT/ZV85mg=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=GQ/zXscDMLa1ypK+md806z8LPqOE/3r2et9BbEdtj1llOXdt5vsBLhEc9qknap+bQfiYmafje5eZRu2fh4EMXvdYZjNQ6tLQFVR42W0Muk10DslNRgOFjBYPfBx03evwwwcD+CEHlYdoik+EPmW/f81IpmOtgNj2r3pZWExX9Cc= 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=aJuqbDkA; arc=none smtp.client-ip=209.85.160.177 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="aJuqbDkA" Received: by mail-qt1-f177.google.com with SMTP id d75a77b69052e-5013c912f9fso3275941cf.2 for ; Wed, 21 Jan 2026 15:13:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1769037193; x=1769641993; darn=vger.kernel.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=IquXnFFosZlOyNmK6bSXL9iR+BIWvsTphuu77XAlhOg=; b=aJuqbDkAMeJVzj6D8vY+dtweIDQj3r4yFU42WLysjClCO4/aSSHMGWcrrnj/OXqTUS XhGE0M+YNeu7QWGL3TJZICBd5/oQBM/w7ohcC2c2BX3CF1DUk59GjJBW3enktFfT4Ykh jH8G4YKyh65WwTW8wPIHqtnoflLn9eaevHYvTYYE8ZJwAdi8/WlsH13bpX7eOLjQRzG1 kE/awANmNkMhZvcNyZ5Rl3NooNZVbk8bXsNAmeRujB+oirb03b/mG+sxLJKQ3L6+ztOM AFIY6oqQCYzBPGQYWcg4ow7sq08XUIrDUF6YjVeRAx7kN99Dd39frGx7izpbN2QZyGLe PpHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769037193; x=1769641993; h=in-reply-to: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=IquXnFFosZlOyNmK6bSXL9iR+BIWvsTphuu77XAlhOg=; b=iabWWJpFPEnu4si1+vb5L4gKYspIRWQyyXcg/VE82ayXtsa5uQGfraPZL0aAPn9z+9 Dy6ujVxXxiOK+6ZcaxKwNNNQX0sX6tE64/Y6YMGhxqLI63hu3naSc0YQNXTAScOpgkxd 7C0fLI4dAW809b4rvN36SvsyqXzJnpisXL6R6FjRfKUf9NciHYOBmHndF/qtww1dDFsB p9EOfj4+2FEsxTXelVSqhnI2nOx7q0RkUGfTmw4tIEYR1GtBnta1TQiMR54oc3gRlbEY aRSUjC83mMNRP8fFo4nJmhyB+hwO3eofH6lGbA/N14kRQQkvYOqRfd3J+YRMswjm4LhZ y+Iw== X-Forwarded-Encrypted: i=1; AJvYcCWeLFKKf/pqgPGSCyQac6WmU362U2JjwsutIoWx30SdsgO6tr7qP68L5p4UmpWTBLJ3BXxuIIY80eXCAHw=@vger.kernel.org X-Gm-Message-State: AOJu0YwbzKdSJSDe8+nae1dh7kNlhzkFyBv+llSnRagx5tEK6vqzhuoH 3Us+z1b+swvjdkJx8u19fwYdFuIN1/AtgP51wypZa3y0fWsALiXN+v4H0NFH3Ut5LE4= X-Gm-Gg: AZuq6aI+w1WZ2SwA/5AyzzqNsx2squebyDUTxFVNw/2pNXVKb/2F9uh6fQGLLg63rm1 mXm9hbyzthnbKkIf8q0cWHiXTHUVgo3wZ5PF8Lnp++5x1OKEPi1x927DsKOwFNBS7d1PHtaHH0K sfWhmsnGNpMgPsBB1cs7VoNioGMe/LZlcf421BEiZkN/92v8Lrp0pbDJFHmCNB3jK3vFDAPetm/ dE1Ps8ywLQop9KBW7LJLxTOHaKKITZU7WQe2Hv9LuvY/4605dE89z6UYNGBL2SGphKqvP6P9RWQ wgHiDChzkB7xSQEdy0BvLgWEDd3AUKZhQeHNhQ461Vvv5L5OMW3iGgZWeqnt27dabdva1//H6q9 N+e9MahZRs3TJ/cJz+accHYKXUDS3f27wxKTtickcDSl4V/+0HTy735SwegIQ1ycQ4TOU4ANuih iBapB9x6iFKWVvgfFfu15pCu8KiF+zb7NcOUGdht2yqk0hUaH1ChkMMupMEci5EM4J6143pQ== X-Received: by 2002:a05:622a:38b:b0:4ef:c4de:2ac9 with SMTP id d75a77b69052e-502a1dbcb2bmr223833141cf.17.1769037192645; Wed, 21 Jan 2026 15:13:12 -0800 (PST) Received: from gourry-fedora-PF4VCD3F (pool-96-255-20-138.washdc.ftas.verizon.net. [96.255.20.138]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-502a1f1b872sm117818431cf.31.2026.01.21.15.13.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Jan 2026 15:13:12 -0800 (PST) Date: Wed, 21 Jan 2026 18:12:39 -0500 From: Gregory Price To: dan.j.williams@intel.com Cc: Yazen Ghannam , Robert Richter , Peter Zijlstra , Dave Jiang , Ard Biesheuvel , Jonathan Cameron , Alison Schofield , Vishal Verma , Ira Weiny , Davidlohr Bueso , linux-cxl@vger.kernel.org, linux-kernel@vger.kernel.org, "Fabio M. De Francesco" , Terry Bowman , Joshua Hahn , Borislav Petkov , "Rafael J. Wysocki" , John Allen Subject: Re: [PATCH v9 10/13] cxl: Enable AMD Zen5 address translation using ACPI PRMT Message-ID: References: <20260114180859.00004623@huawei.com> <20260115080444.GD830755@noisy.programming.kicks-ass.net> <20260116143838.GC1890602@noisy.programming.kicks-ass.net> <20260119160342.GA659351@yaz-khff2.amd.com> <69701f6de978_1d6f1001e@dwillia2-mobl4.notmuch> <20260121145817.GB1784626@yaz-khff2.amd.com> <69714e9728d2d_1d6f10075@dwillia2-mobl4.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=us-ascii Content-Disposition: inline In-Reply-To: <69714e9728d2d_1d6f10075@dwillia2-mobl4.notmuch> On Wed, Jan 21, 2026 at 02:09:27PM -0800, dan.j.williams@intel.com wrote: > > > > I see. So the concern is including model-specific methods that would > > modify the CXL standard flow, correct? > ... > > As I told Robert, I want a generic "Normalized Address" facility of > which Zen5 is the first user. > Isn't that what this patch functionally is w/ a specific PRM function? rc = acpi_call_prm_handler(prm_cxl_dpa_spa_guid, &data); Or is the request now: replace this with static table data? point of ignorance: what facility would you use to expose such tables? ----- When i initialially hacked up driver support for this mode before getting PRM support, the "hacked up translation code" I was this: /* Find 0-based offset into whole interleave region */ dev = (pdev->bus->number == 0xe1) ? 0 : 1; offset = (0x100 * (((norm_addr >> 8) * 2) + dev)) + (norm_addr & 0xff); /* Find the SPA base for the address */ for (idx = 0; idx < cfmws_nr; idx++) { size = cxl_get_cfmws_size(idx); /* We may have a gap in the CFMWS */ if (offset < size) { *sys_addr = cxl_get_cfmws_base(idx) + offset; return 0; } offset -= size; } ------ This makes hard-assumptions about two things: device interleave index - pcidev(0xe1) => 0 cfmws base - all CFMWS are used for this one region cxl_get_cfmws_base() was a call into ACPI code, and the acpi code just kept a global cache of the raw CEDT CFMWS structures (base + size); So, assuming you had such tables, it would need to be like: Normalized Decoders Table -------------------------------------------------------- | CXL PCIDev | Decoder | CFMW SPAN | Interleave IDX | -------------------------------------------------------- | d1 | 0 | 1,2 | 0 | | e1 | 0 | 1,2 | 1 | -------------------------------------------------------- --------------------------------^ | CFMW Index Table | ----------------------------------------- | | CFMW ID | BASE | SIZE | | ----------------------------------------- | | 0 | 0xb00000.... | ... | |->| 1 | 0xc05000.... | | |->| 2 | 0x100500.... | | | 3 | 0x200000.... | ... | ----------------------------------------- ------- The code above turns into int cxl_normal_translate(pdev, norm_addr, u64* sys_addr) { int i_idx = cxl_nrm_decoder_interleave_index(pdev); int span, i; u64 offset; if (i_idx < 0) return -EINVAL; span = cxl_nrm_decoder_window_span(pdev); /* Normalized offset into whole region */ offset = (0x100 * (((norm_addr >> 8) * 2) + i_idx)) + (norm_addr & 0xff); /* Find actual CFMW Base (might cross multiple w/ gaps) */ for (i = 0; i < span; i++) { u64 base, size; int id; id = cxl_nrm_decoder_cfmws_id(i); if (id < 0) return -EINVAL; if (!cxl_nrm_decoder_cfmws_data(id, &base, &size)) return -EINVAL; if (offset < size) { *sys_addr = cxl_get_cfmws_base(id) + offset; return 0; } offset -= size; } return -EINVAL; } Where the cxl_nrm_*() functions just query the exposed tables - however that actually happens. -------- I don't know whether the above math is actually true, it's basically just the simply interleave maths. If something else is going on, then this whole table thing might not actually work. The rest of the patch set would more or less stay the same. ~Gregory