From: Alejandro Lucero Palau <alucerop@amd.com>
To: Ben Cheatham <benjamin.cheatham@amd.com>, alejandro.lucero-palau@amd.com
Cc: linux-cxl@vger.kernel.org, netdev@vger.kernel.org,
dan.j.williams@intel.com, martin.habets@xilinx.com,
edward.cree@amd.com, davem@davemloft.net, kuba@kernel.org,
pabeni@redhat.com, edumazet@google.com
Subject: Re: [PATCH v4 24/26] cxl: preclude device memory to be used for dax
Date: Fri, 18 Oct 2024 09:10:59 +0100 [thread overview]
Message-ID: <9f1d0a16-9c81-9165-8341-bc2982607f65@amd.com> (raw)
In-Reply-To: <ae59e9a4-a4f1-4839-977b-b667d927c647@amd.com>
On 10/17/24 22:50, Ben Cheatham wrote:
> On 10/17/24 11:52 AM, alejandro.lucero-palau@amd.com wrote:
>> From: Alejandro Lucero <alucerop@amd.com>
>>
>> By definition a type2 cxl device will use the host managed memory for
>> specific functionality, therefore it should not be available to other
>> uses.
>>
> I disagree that this is a valid assumption. I don't think that the device memory
> should be added as system ram, but I do think there is value in having the
> option to have the memory be available as a device-dax region. My reasoning here is:
>
> 1) I can think of a possible use case where the memory benefits from being user space
> accessible (CXL memory GPU buffers).
> 2) I think it's really early to say this is the only way we expect these devices to
> be used. The flip side of this is that it is early, so we can always change it later
> when we start seeing real devices, but I would vote to keep a more flexible structure
> early and if no one uses it oh well.
>
> My idea here is that whoever writes the driver indicates whether they want to make
> the device memory device-dax mappable, or do it all manually like you are now. I've
> been working on a RFC based on v3 of this series that has this (as well as the
> "better" solution mentioned in patch 22/26) that I was planning
> on sending out in the next week or two, but if the consensus here is that this is
> not the direction we want to go I'll probably drop that portion.
I understand your point and I agree dax creation could be required or
interesting for some accelerators.
My experience when testing without this patch is the system is using
that DAX even without any specific user space app, so the system was
crashing because the CXL memory backend was not doing the expected
thing. That is exactly the same case for our device, where memory should
not be used except with the right format when writing. So the trivial
patch was to preclude this dax creation for an accel/Type2.
I'm not against adding that flexibility now with a flag set by the
driver at region creation time, so I'll add it for v5 if none is against it.
Thanks!
> Thanks,
> Ben
>
>> Signed-off-by: Alejandro Lucero <alucerop@amd.com>
>> ---
>> drivers/cxl/core/region.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/drivers/cxl/core/region.c b/drivers/cxl/core/region.c
>> index 04c270a29e96..7c84d8f89af6 100644
>> --- a/drivers/cxl/core/region.c
>> +++ b/drivers/cxl/core/region.c
>> @@ -3703,6 +3703,9 @@ static int cxl_region_probe(struct device *dev)
>> case CXL_DECODER_PMEM:
>> return devm_cxl_add_pmem_region(cxlr);
>> case CXL_DECODER_RAM:
>> + if (cxlr->type != CXL_DECODER_HOSTONLYMEM)
>> + return 0;
>> +
>> /*
>> * The region can not be manged by CXL if any portion of
>> * it is already online as 'System RAM'
next prev parent reply other threads:[~2024-10-18 8:11 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-17 16:51 [PATCH v4 00/26] cxl: add Type2 device support alejandro.lucero-palau
2024-10-17 16:52 ` [PATCH v4 01/26] cxl: add type2 device basic support alejandro.lucero-palau
2024-10-25 13:50 ` Jonathan Cameron
2024-10-28 9:37 ` Alejandro Lucero Palau
2024-10-28 18:05 ` Dave Jiang
2024-10-30 16:26 ` Alejandro Lucero Palau
2024-10-17 16:52 ` [PATCH v4 02/26] sfc: add cxl support using new CXL API alejandro.lucero-palau
2024-10-17 21:48 ` Ben Cheatham
2024-10-18 13:38 ` Alejandro Lucero Palau
2024-10-25 14:03 ` Jonathan Cameron
2024-10-28 11:59 ` Alejandro Lucero Palau
2024-10-29 15:14 ` Jonathan Cameron
2024-10-30 16:31 ` Alejandro Lucero Palau
2024-10-17 16:52 ` [PATCH v4 03/26] cxl: add capabilities field to cxl_dev_state and cxl_port alejandro.lucero-palau
2024-10-25 14:14 ` Jonathan Cameron
2024-10-28 12:00 ` Alejandro Lucero Palau
2024-10-28 18:19 ` Dave Jiang
2024-10-30 16:28 ` Alejandro Lucero Palau
2024-10-17 16:52 ` [PATCH v4 04/26] cxl/pci: add check for validating capabilities alejandro.lucero-palau
2024-10-25 10:16 ` Alejandro Lucero Palau
2024-10-25 14:16 ` Jonathan Cameron
2024-10-17 16:52 ` [PATCH v4 05/26] cxl: move pci generic code alejandro.lucero-palau
2024-10-17 21:49 ` Ben Cheatham
2024-10-18 9:35 ` Alejandro Lucero Palau
2024-10-17 16:52 ` [PATCH v4 06/26] cxl: add function for type2 cxl regs setup alejandro.lucero-palau
2024-10-17 21:49 ` Ben Cheatham
2024-10-17 16:52 ` [PATCH v4 07/26] sfc: use cxl api for regs setup and checking alejandro.lucero-palau
2024-10-17 21:49 ` Ben Cheatham
2024-10-18 15:07 ` Alejandro Lucero Palau
2024-10-17 16:52 ` [PATCH v4 08/26] cxl: add functions for resource request/release by a driver alejandro.lucero-palau
2024-10-17 21:49 ` Ben Cheatham
2024-10-18 14:58 ` Alejandro Lucero Palau
2024-10-18 16:40 ` Ben Cheatham
2024-10-17 16:52 ` [PATCH v4 09/26] sfc: request cxl ram resource alejandro.lucero-palau
2024-10-17 16:52 ` [PATCH v4 10/26] cxl: harden resource_contains checks to handle zero size resources alejandro.lucero-palau
2024-10-17 16:52 ` [PATCH v4 11/26] cxl: add function for setting media ready by a driver alejandro.lucero-palau
2024-10-17 16:52 ` [PATCH v4 12/26] sfc: set cxl media ready alejandro.lucero-palau
2024-10-17 16:52 ` [PATCH v4 13/26] cxl: prepare memdev creation for type2 alejandro.lucero-palau
2024-10-17 21:49 ` Ben Cheatham
2024-10-18 10:49 ` Alejandro Lucero Palau
2024-10-18 16:40 ` Ben Cheatham
2024-10-17 16:52 ` [PATCH v4 14/26] sfc: create type2 cxl memdev alejandro.lucero-palau
2024-10-17 16:52 ` [PATCH v4 15/26] cxl: define a driver interface for HPA free space enumeration alejandro.lucero-palau
2024-10-17 16:52 ` [PATCH v4 16/26] sfc: obtain root decoder with enough HPA free space alejandro.lucero-palau
2024-10-17 16:52 ` [PATCH v4 17/26] cxl: define a driver interface for DPA allocation alejandro.lucero-palau
2024-10-17 16:52 ` [PATCH v4 18/26] sfc: get endpoint decoder alejandro.lucero-palau
2024-10-17 16:52 ` [PATCH v4 19/26] cxl: make region type based on endpoint type alejandro.lucero-palau
2024-10-17 16:52 ` [PATCH v4 20/26] cxl/region: factor out interleave ways setup alejandro.lucero-palau
2024-10-17 16:52 ` [PATCH v4 21/26] cxl/region: factor out interleave granularity setup alejandro.lucero-palau
2024-10-17 16:52 ` [PATCH v4 22/26] cxl: allow region creation by type2 drivers alejandro.lucero-palau
2024-10-17 21:49 ` Ben Cheatham
2024-10-18 8:51 ` Alejandro Lucero Palau
2024-10-18 16:40 ` Ben Cheatham
2024-10-21 9:54 ` Alejandro Lucero Palau
2024-10-17 16:52 ` [PATCH v4 23/26] sfc: create cxl region alejandro.lucero-palau
2024-10-17 16:52 ` [PATCH v4 24/26] cxl: preclude device memory to be used for dax alejandro.lucero-palau
2024-10-17 21:50 ` Ben Cheatham
2024-10-18 8:10 ` Alejandro Lucero Palau [this message]
2024-10-17 16:52 ` [PATCH v4 25/26] cxl: add function for obtaining params from a region alejandro.lucero-palau
2024-10-17 16:52 ` [PATCH v4 26/26] sfc: support pio mapping based on cxl alejandro.lucero-palau
2024-10-23 8:46 ` [PATCH v4 00/26] cxl: add Type2 device support Paolo Abeni
2024-10-23 9:38 ` Alejandro Lucero Palau
2024-11-20 16:50 ` Should the CXL Type2 support patchset be split up? Alejandro Lucero Palau
2024-11-20 17:13 ` Dave Jiang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9f1d0a16-9c81-9165-8341-bc2982607f65@amd.com \
--to=alucerop@amd.com \
--cc=alejandro.lucero-palau@amd.com \
--cc=benjamin.cheatham@amd.com \
--cc=dan.j.williams@intel.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=edward.cree@amd.com \
--cc=kuba@kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=martin.habets@xilinx.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox