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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 292E4D2C55B for ; Tue, 22 Oct 2024 14:12:01 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A17B76B0089; Tue, 22 Oct 2024 10:12:00 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9A04F6B008C; Tue, 22 Oct 2024 10:12:00 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 81AAE6B0092; Tue, 22 Oct 2024 10:12:00 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 61A5F6B0089 for ; Tue, 22 Oct 2024 10:12:00 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 7122F1C138A for ; Tue, 22 Oct 2024 14:11:41 +0000 (UTC) X-FDA: 82701426612.25.7B057C3 Received: from mail-qv1-f53.google.com (mail-qv1-f53.google.com [209.85.219.53]) by imf11.hostedemail.com (Postfix) with ESMTP id EFECA4001A for ; Tue, 22 Oct 2024 14:11:38 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=gourry.net header.s=google header.b=LcOmorfI; dmarc=none; spf=pass (imf11.hostedemail.com: domain of gourry@gourry.net designates 209.85.219.53 as permitted sender) smtp.mailfrom=gourry@gourry.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729606152; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=5Qhll7IfNOfUrslv0JS+DDYY0+c54jassaWQ2ezcVZM=; b=J89OrUj4ivQlrE/CS9eVfD5PQtndRb0DqqN5fM1ld5TMTBH/ExGlFXjK7gIuPyIi9D+u/v wdGl1+nUtXuYBJgbORjOfrhySvY4myAtyvEJvqm2kqJC5GSmN4Ws7mRcOmRlwg/DWZxoB4 Tuyjt9EbE6qmXRYs8wWLG25SIFutsMU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729606152; a=rsa-sha256; cv=none; b=hu48PyS9PGXjEfjBDXdbjMoESKYjffyCVO0Nb4eBt1LAYZPkb+70gujM3c/Zyaa06OFNzL pgE3lxpnByD+BEMCZVnbTi3+Q6d1TcxbjLWYM0mgz4MQe7VNNcTeywh9oxIfWXdUtZlv42 9+3H3GLg1xhO8PJTta28BgKuKslEAYs= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=gourry.net header.s=google header.b=LcOmorfI; dmarc=none; spf=pass (imf11.hostedemail.com: domain of gourry@gourry.net designates 209.85.219.53 as permitted sender) smtp.mailfrom=gourry@gourry.net Received: by mail-qv1-f53.google.com with SMTP id 6a1803df08f44-6cbc28f8e1bso41795496d6.0 for ; Tue, 22 Oct 2024 07:11:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gourry.net; s=google; t=1729606317; x=1730211117; darn=kvack.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=5Qhll7IfNOfUrslv0JS+DDYY0+c54jassaWQ2ezcVZM=; b=LcOmorfIe6sEr5CJxKPKqoDMRQYf/pK6XqCcSIa4fwMkmsC4L7evrSccYOvYDWD8hF AJcKsN5F3agEbQFAA9sWdg5LBcPTB92ISGcN7JCOZGHnt2RUzxiM8sL6xERTW6u6DquJ Ht7sk5Yidpwgcpx07xvpX3PXwrebMNu0AqOuUeeGRpi32vCaVquGFRCHgiq24noSE4E6 5mlV3HPoGSTz+tIsop8uMvhBUefVuusefUYhbiwGyOIl+ev52zMOja8Nr0TfNk4p+AZH kd1o46caPtxxrbPDuegVrP8yxkAAPGzj3Sth1KOg93MwKm+bAxINW2izKsOULULFI4zJ wVrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729606317; x=1730211117; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=5Qhll7IfNOfUrslv0JS+DDYY0+c54jassaWQ2ezcVZM=; b=W00PGx6lRB+2WGkhfRmnPeOj28jEPaZzTJNliqeyvd/t2m3H1nA3haAo52pvssf/3Z OSKn7DxUUt8IYjUvR3O6yGoiHPEp4BI+Oof0XRKw1dMSB78P8WYNft2TCO5Q2IFKLiKP LX5WArUlN8BwcOejjOGZYlhXfKoLD371UmTtYtgtVJCgWkL/uPCcu0RDzgMAEY+m1iIO KL3sHoFFLmbRZFJWE5QEL1jCHajbEOBBOt7b/VyD/9cLF7gbc96lhVNRty1Yx4gNRVj/ Q+xc8Bku8PpSCNasrfiorOXMYge3xLDYMZLN58g6mjK3avqkgYF14D07Tqx1u9SZrjdh A1+Q== X-Forwarded-Encrypted: i=1; AJvYcCWEDVqw50WoOlII37mzLdDVfZ+Jw0eRnoOvW2xJXKpKxZ0dDJT9PUNZTVWSvVy58UUApuyxXGu9/A==@kvack.org X-Gm-Message-State: AOJu0YwZHSpLOQLdBzC23QoVMuHlabMm7j83viiJNqAGAEbT48wkipdD mh3Ps5m7WihOB2/JQ98Q+Qm3boRX8lGXLlRSTSUNinBjYGwJsPP7qGNpOSRK4nU= X-Google-Smtp-Source: AGHT+IHbw1D8MQDNK0PT64hixmIdaE3j5oH9Y2hxuMJ4+N0WrOEaNeUQS0eLymZXwzrOWOPN26VX2Q== X-Received: by 2002:a05:6214:440b:b0:6cc:2cc0:ccda with SMTP id 6a1803df08f44-6cde11459a2mr205071776d6.0.1729606317290; Tue, 22 Oct 2024 07:11:57 -0700 (PDT) Received: from PC2K9PVX.TheFacebook.com (pool-173-79-56-208.washdc.fios.verizon.net. [173.79.56.208]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-6ce009e4470sm29298036d6.125.2024.10.22.07.11.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Oct 2024 07:11:56 -0700 (PDT) Date: Tue, 22 Oct 2024 10:11:58 -0400 From: Gregory Price To: Jonathan Cameron Cc: John Groves , David Hildenbrand , linux-mm , linux-cxl , Davidlohr Bueso , Ira Weiny , virtualization , Oscar Salvador , qemu-devel , Dave Jiang , Dan Williams , Linuxarm , "Wangkefeng (OS Kernel Lab)" , John Groves , Fan Ni , Navneet Singh , =?utf-8?B?4oCcTWljaGFlbCBTLiBUc2lya2lu4oCd?= , Igor Mammedov , Philippe =?iso-8859-1?Q?Mathieu-Daud=E9?= Subject: Re: [RFC] Virtualizing tagged disaggregated memory capacity (app specific, multi host shared) Message-ID: References: <20240815172223.00001ca7@Huawei.com> <20240819164024.00005a0a@Huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: EFECA4001A X-Stat-Signature: dne9eitodsnd44aubcwxb8aosghxb89a X-Rspam-User: X-HE-Tag: 1729606298-272386 X-HE-Meta: U2FsdGVkX19zWwh4nCwMi1KLRIIc9NPlFX0magb8UKDlAWh7uoXL5Wgo+J3K8Bh0pSirim5nXifffHqyIRwGIzw30ccKFZLHpyzsRJqRJrIIRfJ2ryFNBoosg0yJKDssN+zlLIlbqeZKKOhWR3bLXn1jTR+7MiWBp5sK84YtZLW+s3k0FQimIJN2BeYQuFSinH7MqAZPQ8VH/yfUKibVKhwkFSSFs+uyNvKtsUzC9KGNZzfwzo2zVIcxdVjiT+rZXdLl93HIs0teK3jtZ1phgoj4botr0p++JuBR0okHMu1Htm8fNdA5C7U4aKE6bq0voAXngfnyOEBg2EGPsaA9tCIfYS1pHBg0vCEKtTcwJSacu3Pc/ih8tqQ689TQnDt2tPrkvhEuDItQg+PgOonRGZ2lpzmHRhaF0nrmyu8AAG3+rHU4dxoB8B46oait9kw5wkPwWMj4LSRIpX6QHmMK2CsY5b/s54BWm0VQUYjkSuOo0trA3rp+pq9idRSe5AiRLlgo3EgfS6rifFwqBXqQFC5GaOUGNnEF/TFI7eqnf5PC65Wj7/Tx/1Z69OQjBXveQnhmGVZPPxIHrJjrJheO55ViwyZa1uULwYZ8mGNS2DaNK3WzlXSS6O0W+7BRdvdDRS55InY6zR78yT5fg42PgMo2tgObtfQdo2GvxhGb4QhcsAD1tUoE8GJClvooiGDoSd58jshHM181WlV14DnLqS+1HN42IcgFqavZ4RZ2tOhGtPACN0NmgO2IzkUJSulDbjxlMXKFEco4Z19CJ9W/LVJtxpSW2e3iu0JOzcxM84J3iSFOsf6PNbqUB0H9cxLKAt94UUFSpYv+6y1NiKOQscNTNKX694TW1dwX7ctRJxU7qgE9A5x51BRBqeJt01fUu1yyinr6okJ/0AZN5/9IzLk+KUn02tZgkRnVGy8qWMlxj5XJlD6wAi26OFMk+4mB9xVZcunj9rD162bfECK 3a39Wmfr 8CQYrB5+TFXoq49MTPZ0JCWfpvuuZJdwjr1ECD6bdLCqb7XgaJxwdD7VWZMMiRCAM6X58qxffGlI0Xm9yArqzzrSiYEDjm1ZojSu+mNa0leMsNO2QZ6W8XMyhhCPKgMDbE0pMAmrZlGsrzFXkCDX6eQytxTkCOZdHrETkwl5KVL/Ksw6GoVlUNLs3v2FG2UVHWnbKosOoMIZYWyIodN8tjomO2uLZhrMsVaw1Iep4WpGRs9kF7zDNY/7jDWDPsIrJHFyXhNg55D0U3cyaR0gzokdFnOxCsuYFt4Crk9oeiKSCgv6MredzvHnRPw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Sep 17, 2024 at 07:37:21PM +0000, Jonathan Cameron wrote: > > * Said mechanism should not be explicitly CXL-specific. > > Somewhat agreed, but I don't want to invent a new spec just to avoid explicit > ties to CXL. I'm not against using CXL to present HBM / ACPI Specific Purpose > memory for example to a VM. It will trivially work if that is what a user > wants to do and also illustrates that this stuff doesn't necessarily just > apply to capacity on a memory pool - it might just be 'weird' memory on the host. > I suspect if you took all the DCD components of the current CXL device and repackaged it into a device called "DefinitelyNotACXLDCDDevice", that the CXL device inherited, this whole discussion goes away. Patches welcome? :] > > * Finding a tagged capacity devdax device in a VM should work the same as it > > does running on bare metal. > > Absolutely - that's a requirement. > > > * The file-backed (and devdax-backed) devdax abstraction is needed in qemu. > > Maybe. I'm not convinced the abstraction is needed at that particular level. > > > * Beyond that, I'm not yet sure what the lookup mechanism should be. Extra > > points for being easy to implement in both physical and virtual systems. > > For physical systems we aren't going to get agreement :( For the systems > I have visibility of there will be some diversity in hardware, but the > presentation to userspace and up consistency should be doable. > > Jonathan > > > > > Thanks for teeing this up! > > John > > > > > > [1] https://github.com/cxl-micron-reskit/famfs/blob/master/README.md > > > >