* Re: [PATCH v3 08/12] amd-pstate-ut: Add ability to run a single testcase
From: Mario Limonciello (AMD) (kernel.org) @ 2026-03-23 20:21 UTC (permalink / raw)
To: Gautham R. Shenoy, Rafael J . Wysocki, Viresh Kumar,
K Prateek Nayak
Cc: linux-kernel, linux-pm
In-Reply-To: <20260320144321.18543-9-gautham.shenoy@amd.com>
On 3/20/2026 9:43 AM, Gautham R. Shenoy wrote:
> Currently when amd-pstate-ut test module is loaded, it runs all the
> tests from amd_pstate_ut_cases[] array.
>
> Add a module parameter named "run_only" that allows users to run a
> single test from the array by specifying the test name string.
>
> Signed-off-by: Gautham R. Shenoy <gautham.shenoy@amd.com>
> ---
> drivers/cpufreq/amd-pstate-ut.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/amd-pstate-ut.c b/drivers/cpufreq/amd-pstate-ut.c
> index 447b9aa5ce40..35e453a49c0f 100644
> --- a/drivers/cpufreq/amd-pstate-ut.c
> +++ b/drivers/cpufreq/amd-pstate-ut.c
> @@ -35,6 +35,10 @@
>
> #include "amd-pstate.h"
>
> +static char *run_only;
> +module_param(run_only, charp, 0444);
> +MODULE_PARM_DESC(run_only,
> + "Run only the named test case (default: run all)");
This default shows the end effect; but it doesn't make sense for this
parameter IMO.
How about instead if you had a semicolon delimitted list and then
defaulted an empty list to mean all tests? Something like this:
static char *test_list;
module_param(test_list, charp, 0444)
MODULE_PARM_DESC(test_list,
"Semicolon delimitted list of tests to run (empty means run all tests)");
>
> struct amd_pstate_ut_struct {
> const char *name;
> @@ -275,7 +279,12 @@ static int __init amd_pstate_ut_init(void)
> u32 i = 0, arr_size = ARRAY_SIZE(amd_pstate_ut_cases);
>
> for (i = 0; i < arr_size; i++) {
> - int ret = amd_pstate_ut_cases[i].func(i);
> + int ret;
> +
> + if (run_only && strcmp(run_only, amd_pstate_ut_cases[i].name))
> + continue;
> +
> + ret = amd_pstate_ut_cases[i].func(i);
If you take my suggestion then you would split this on semicolon or end
of string and then allow matching multiple.
>
> if (ret)
> pr_err("%-4d %-20s\t fail: %d!\n", i+1, amd_pstate_ut_cases[i].name, ret);
^ permalink raw reply
* Re: [PATCH v5 00/21] Virtual Swap Space
From: Nhat Pham @ 2026-03-23 20:05 UTC (permalink / raw)
To: Kairui Song
Cc: Liam.Howlett, akpm, apopple, axelrasmussen, baohua, baolin.wang,
bhe, byungchul, cgroups, chengming.zhou, chrisl, corbet, david,
dev.jain, gourry, hannes, hughd, jannh, joshua.hahnjy, lance.yang,
lenb, linux-doc, linux-kernel, linux-mm, linux-pm,
lorenzo.stoakes, matthew.brost, mhocko, muchun.song, npache,
pavel, peterx, peterz, pfalcato, rafael, rakie.kim,
roman.gushchin, rppt, ryan.roberts, shakeel.butt, shikemeng,
surenb, tglx, vbabka, weixugc, ying.huang, yosry.ahmed, yuanchu,
zhengqi.arch, ziy, kernel-team, riel
In-Reply-To: <CAMgjq7AzySv801qDxfc8mEkEsFDv4P=_qw0rNOTe0n+qy7Fz6A@mail.gmail.com>
On Mon, Mar 23, 2026 at 12:41 PM Kairui Song <ryncsn@gmail.com> wrote:
>
> On Mon, Mar 23, 2026 at 11:33 PM Nhat Pham <nphamcs@gmail.com> wrote:
> >
> > On Mon, Mar 23, 2026 at 6:09 AM Kairui Song <ryncsn@gmail.com> wrote:
> > >
> > > On Sat, Mar 21, 2026 at 3:29 AM Nhat Pham <nphamcs@gmail.com> wrote:
> > > > This patch series is based on 6.19. There are a couple more
> > > > swap-related changes in mainline that I would need to coordinate
> > > > with, but I still want to send this out as an update for the
> > > > regressions reported by Kairui Song in [15]. It's probably easier
> > > > to just build this thing rather than dig through that series of
> > > > emails to get the fix patch :)
> > > >
> > > > Changelog:
> > > > * v4 -> v5:
> > > > * Fix a deadlock in memcg1_swapout (reported by syzbot [16]).
> > > > * Replace VM_WARN_ON(!spin_is_locked()) with lockdep_assert_held(),
> > > > and use guard(rcu) in vswap_cpu_dead
> > > > (reported by Peter Zijlstra [17]).
> > > > * v3 -> v4:
> > > > * Fix poor swap free batching behavior to alleviate a regression
> > > > (reported by Kairui Song).
> > >
> >
> > Hi Kairui! Thanks a lot for the testing big boss :) I will focus on
> > the regression in this patch series - we can talk more about
> > directions in another thread :)
>
> Hi Nhat,
>
> > Interesting. Normally "lots of zero-filled page" is a very beneficial
> > case for vswap. You don't need a swapfile, or any zram/zswap metadata
> > overhead - it's a native swap backend. If production workload has this
> > many zero-filled pages, I think the numbers of vswap would be much
> > less alarming - perhaps even matching memory overhead because you
> > don't need to maintain a zram entry metadata (it's at least 2 words
> > per zram entry right?), while there's no reverse map overhead induced
> > (so it's 24 bytes on both side), and no need to do zram-side locking
> > :)
> >
> > So I was surprised to see that it's not working out very well here. I
> > checked the implementation of memhog - let me know if this is wrong
> > place to look:
> >
> > https://man7.org/linux/man-pages/man8/memhog.8.html
> > https://github.com/numactl/numactl/blob/master/memhog.c#L52
> >
> > I think this is what happened here: memhog was populating the memory
> > 0xff, which triggers the full overhead of a swapfile-backed swap entry
> > because even though it's "same-filled" it's not zero-filled! I was
> > following Usama's observation - "less than 1% of the same-filled pages
> > were non-zero" - and so I only handled the zero-filled case here:
> >
> > https://lore.kernel.org/all/20240530102126.357438-1-usamaarif642@gmail.com/
> >
> > This sounds a bit artificial IMHO - as Usama pointed out above, I
> > think most samefilled pages are zero pages, in real production
> > workloads. However, if you think there are real use cases with a lot
>
> I vaguely remember some workloads like Java or some JS engine
> initialize their heap with fixed value, same fill might not be that
> common but not a rare thing, it strongly depends on the workload.
To a non-zero value? ISTR it was initialized to zero, but if I was
wrong then yeah it should just be a small simple patch.
>
> > of non-zero samefilled pages, please let me know I can fix this real
> > quick. We can support this in vswap with zero extra metadata overhead
> > - change the VSWAP_ZERO swap entry type to VSWAP_SAME_FILLED, then use
> > the backend field to store that value. I can send you a patch if
> > you're interested.
>
> Actually I don't think that's the main problem. For example, I just
> wrote a few lines C bench program to zerofill ~50G of memory
> and swapout sequentially:
>
> Before:
> Swapout: 4415467us
> Swapin: 49573297us
>
> After:
> Swapout: 4955874us
> Swapin: 56223658us
>
> And vmstat:
> cat /proc/vmstat | grep zero
> thp_zero_page_alloc 0
> thp_zero_page_alloc_failed 0
> swpin_zero 12239329
> swpout_zero 21516634
>
> There are all zero filled pages, but still slower. And what's more, a
> more critical issue, I just found the cgroup and global swap usage
> accounting are both somehow broken for zero page swap,
> maybe because you skipped some allocation? Users can
> no longer see how many pages are swapped out. I don't think you can
> break that, that's one major reason why we use a zero entry instead of
> mapping to a zero readonly page. If that is acceptable, we can have
> a very nice optimization right away with current swap.
No, that was intentional :) I probably should have documented this
better - but we're only charging towards swap usage (cgroup and system
wide) on memory. There was a whole patch that did that in the series
:)
I can add new counters to differentiate these cases, but it makes no
sense to me to charge towards swap usage for non-swapfile backend
(namely, zswap and zero swap pages). You are not actually occupying
the limited swapfile slots, but instead occupy a dynamic, vast virtual
swap space only (and memory in the case of zswap - this is actually an
argument against zram which does not do any cgroup accounting, but
that's another story for another day). I don't see a point in swap
charging here. It's the whole point of decoupling the backends - these
are not the same resource domains.
And if you follow Usama's work above, we actually were trying to
figure out a way to map it to a zero readonly page. That was Usama's
v2 of the patch series IIRC - but there was a bug. I think it was a
potential race between the reclaimer's rmap walk to unmap the page
from PTEs pointing to the page, and concurrent modifiers to the page?
We couldn't fix the race in a way that does not induce more overhead
than it's worth. But had that work we would also not do any swap
charging :)
BTW, if you can figure that part out, please let us know. We actually
quite like that idea - we just never managed to make it work (and we
have a bunch more urgent tasks).
>
> That's still just an example. bypassing the accounting and still
> slower is not a good sign. We should focus on the generic
> performance and design.
I will dig into the remaining regression :) Thanks for the report.
>
> Yet this is just another new found issue, there are many other parts
> like the folio swap allocation may still occur even if a lower device
> can no longer accept more whole folios, which I'm currently
> unsure how it will affect swap.
>
> > 1. Regarding pmem backend - I'm not sure if I can get my hands on one
> > of these, but if you think SSD has the same characteristics maybe I
> > can give that a try? The problem with SSD is for some reason variance
> > tends to be pretty high, between iterations yes, but especially across
> > reboots. Or maybe zram?
>
> Yeah, ZRAM has a very similar number for some cases, but storage is
> getting faster and faster and swap occurs through high speed networks
> too. We definitely shouldn't ignore that.
I can also simulate it using tmpfs as a swap backend (although it
might not work for certain benchmarks, like your usemem benchmark in
which we allocate more memory than the host physical memory).
>
> > 2. What about the other numbers below? Are they also on pmem? FTR I
> > was running most of my benchmarks on zswap, except for one kernel
> > build benchmark on SSD.
> >
> > 3. Any other backends and setup you're interested in?
> >
> > BTW, sounds like you have a great benchmark suite - is it open source
> > somewhere? If not, can you share it with us :) Vswap aside, I think
> > this would be a good suite to run all swap related changes for every
> > swap contributor.
>
> I can try to post that somewhere, really nothing fancy just some
> wrapper to make use of systemd for reboot and auto test. But all test
> steps I mentioned before are already posted and publically available.
Okay, thanks, Kairui!
^ permalink raw reply
* Re: [PATCH v7 0/2] mm/swap, PM: hibernate: fix swapoff race and optimize swap
From: Andrew Morton @ 2026-03-23 19:56 UTC (permalink / raw)
To: YoungJun Park
Cc: rafael, chrisl, kasong, pavel, shikemeng, nphamcs, bhe, baohua,
usama.arif, linux-pm, linux-mm
In-Reply-To: <ab/E5SaSAlAKLCwD@yjaykim-PowerEdge-T330>
On Sun, 22 Mar 2026 19:31:01 +0900 YoungJun Park <youngjun.park@lge.com> wrote:
> I based this series on v7.0-rc4 per Rafael's request since it
> depends on PM-side changes. I'm not very familiar with how
> cross-subsystem dependencies are typically coordinated -- if
> rebasing onto mm-new is an option, the race goes away and the
> PM-side changes could be picked up separately. Would that be
> a reasonable approach? I'd appreciate any guidance on this.
hm, yes, 2/2 doesn't apply to linux-next.
The easiest approach would be to park this until the next cycle. How
serious is the bug?
Or Rafael can merge the whole thing, if we can tease some review out of
the swap maintainers (please).
^ permalink raw reply
* Re: [PATCH v8 3/9] dax/hmem: Request cxl_acpi and cxl_pci before walking Soft Reserved ranges
From: Dan Williams @ 2026-03-23 19:54 UTC (permalink / raw)
To: Smita Koralahalli, linux-cxl, linux-kernel, nvdimm, linux-fsdevel,
linux-pm
Cc: Ard Biesheuvel, Alison Schofield, Vishal Verma, Ira Weiny,
Dan Williams, Jonathan Cameron, Yazen Ghannam, Dave Jiang,
Davidlohr Bueso, Matthew Wilcox, Jan Kara, Rafael J . Wysocki,
Len Brown, Pavel Machek, Li Ming, Jeff Johnson, Ying Huang,
Yao Xingtao, Peter Zijlstra, Greg Kroah-Hartman, Nathan Fontenot,
Terry Bowman, Robert Richter, Benjamin Cheatham, Zhijian Li,
Borislav Petkov, Smita Koralahalli, Tomasz Wolski
In-Reply-To: <20260322195343.206900-4-Smita.KoralahalliChannabasappa@amd.com>
Smita Koralahalli wrote:
> From: Dan Williams <dan.j.williams@intel.com>
>
> Ensure cxl_acpi has published CXL Window resources before HMEM walks Soft
> Reserved ranges.
>
> Replace MODULE_SOFTDEP("pre: cxl_acpi") with an explicit, synchronous
> request_module("cxl_acpi"). MODULE_SOFTDEP() only guarantees eventual
> loading, it does not enforce that the dependency has finished init
> before the current module runs. This can cause HMEM to start before
> cxl_acpi has populated the resource tree, breaking detection of overlaps
> between Soft Reserved and CXL Windows.
>
> Also, request cxl_pci before HMEM walks Soft Reserved ranges. Unlike
> cxl_acpi, cxl_pci attach is asynchronous and creates dependent devices
> that trigger further module loads. Asynchronous probe flushing
> (wait_for_device_probe()) is added later in the series in a deferred
> context before HMEM makes ownership decisions for Soft Reserved ranges.
>
> Add an additional explicit Kconfig ordering so that CXL_ACPI and CXL_PCI
> must be initialized before DEV_DAX_HMEM. This prevents HMEM from consuming
> Soft Reserved ranges before CXL drivers have had a chance to claim them.
>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
> Reviewed-by: Dave Jiang <dave.jiang@intel.com>
> Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Reviewed-by: Alison Schofield <alison.schofield@intel.com>
> ---
> drivers/dax/Kconfig | 2 ++
> drivers/dax/hmem/hmem.c | 17 ++++++++++-------
> 2 files changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/dax/Kconfig b/drivers/dax/Kconfig
> index d656e4c0eb84..3683bb3f2311 100644
> --- a/drivers/dax/Kconfig
> +++ b/drivers/dax/Kconfig
> @@ -48,6 +48,8 @@ config DEV_DAX_CXL
> tristate "CXL DAX: direct access to CXL RAM regions"
> depends on CXL_BUS && CXL_REGION && DEV_DAX
> default CXL_REGION && DEV_DAX
> + depends on CXL_ACPI >= DEV_DAX_HMEM
> + depends on CXL_PCI >= DEV_DAX_HMEM
As I learned from Keith's recent CXL_PMEM dependency fix for CXL_ACPI
[1], this wants to be:
depends on DEV_DAX_HMEM || !DEV_DAX_HMEM
depends on CXL_ACPI || !CXL_ACPI
depends on CXL_PCI || !CXL_PCI
...to make sure that DEV_DAX_CXL can never be built-in unless all of its
dependencies are built-in.
[1]: http://lore.kernel.org/69aa341fcf526_6423c1002c@dwillia2-mobl4.notmuch
At this point I am wondering if all of the feedback I have for this
series should just be incremental fixes. I also want to have a canned
unit test that verifies the base expectations. That can also be
something I reply incrementally.
^ permalink raw reply
* Re: [PATCH v8 1/9] dax/bus: Use dax_region_put() in alloc_dax_region() error path
From: Dan Williams @ 2026-03-23 19:37 UTC (permalink / raw)
To: Smita Koralahalli, linux-cxl, linux-kernel, nvdimm, linux-fsdevel,
linux-pm
Cc: Ard Biesheuvel, Alison Schofield, Vishal Verma, Ira Weiny,
Dan Williams, Jonathan Cameron, Yazen Ghannam, Dave Jiang,
Davidlohr Bueso, Matthew Wilcox, Jan Kara, Rafael J . Wysocki,
Len Brown, Pavel Machek, Li Ming, Jeff Johnson, Ying Huang,
Yao Xingtao, Peter Zijlstra, Greg Kroah-Hartman, Nathan Fontenot,
Terry Bowman, Robert Richter, Benjamin Cheatham, Zhijian Li,
Borislav Petkov, Smita Koralahalli, Tomasz Wolski
In-Reply-To: <20260322195343.206900-2-Smita.KoralahalliChannabasappa@amd.com>
Smita Koralahalli wrote:
> alloc_dax_region() calls kref_init() on the dax_region early in the
> function, but the error path for sysfs_create_groups() failure uses
> kfree() directly to free the dax_region. This bypasses the kref lifecycle.
>
> Use dax_region_put() instead to handle kref lifecycle correctly.
There is no correctness issue here, the object was never published.
I am ok with the change, but be clear that this is for pure symmetry
reasons, not correctness.
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
^ permalink raw reply
* Re: [PATCH v1] powercap: intel_rapl: Consolidate PL4 and PMU support flags into rapl_defaults
From: Rafael J. Wysocki @ 2026-03-23 19:22 UTC (permalink / raw)
To: srinivas pandruvada, Kuppuswamy Sathyanarayanan; +Cc: linux-pm, linux-kernel
In-Reply-To: <ed821010a38d535bd123e3d1999d3fd722ccd1ba.camel@linux.intel.com>
On Mon, Mar 23, 2026 at 7:20 PM srinivas pandruvada
<srinivas.pandruvada@linux.intel.com> wrote:
>
> On Fri, 2026-03-13 at 12:00 -0700, Kuppuswamy Sathyanarayanan wrote:
> > Currently, PL4 and MSR-based RAPL PMU support are detected using
> > separate CPU ID tables (pl4_support_ids and pmu_support_ids) in the
> > MSR driver probe path. This creates a maintenance burden since adding
> > a new CPU requires updates in two places: the rapl_ids table and one
> > or both of these capability tables.
> >
> > Consolidate PL4 and PMU capability information directly into
> > struct rapl_defaults by adding msr_pl4_support and msr_pmu_support
> > flags. This allows per-CPU capability to be expressed in a single
> > place alongside other per-CPU defaults, eliminating the duplicate
> > CPU ID tables entirely.
> >
> > No functional changes are intended.
> >
> > Co-developed-by: Zhang Rui <rui.zhang@intel.com>
> > Signed-off-by: Zhang Rui <rui.zhang@intel.com>
> > Signed-off-by: Kuppuswamy Sathyanarayanan
> > <sathyanarayanan.kuppuswamy@linux.intel.com>
>
>
> Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Applied as 7.1 material, thanks!
> > ---
> > drivers/powercap/intel_rapl_msr.c | 83 ++++++++++++++---------------
> > --
> > include/linux/intel_rapl.h | 2 +
> > 2 files changed, 38 insertions(+), 47 deletions(-)
> >
> > diff --git a/drivers/powercap/intel_rapl_msr.c
> > b/drivers/powercap/intel_rapl_msr.c
> > index cfb35973f0b5..a34543e66446 100644
> > --- a/drivers/powercap/intel_rapl_msr.c
> > +++ b/drivers/powercap/intel_rapl_msr.c
> > @@ -216,33 +216,6 @@ static int rapl_msr_write_raw(int cpu, struct
> > reg_action *ra)
> > return ra->err;
> > }
> >
> > -/* List of verified CPUs. */
> > -static const struct x86_cpu_id pl4_support_ids[] = {
> > - X86_MATCH_VFM(INTEL_ICELAKE_L, NULL),
> > - X86_MATCH_VFM(INTEL_TIGERLAKE_L, NULL),
> > - X86_MATCH_VFM(INTEL_ALDERLAKE, NULL),
> > - X86_MATCH_VFM(INTEL_ALDERLAKE_L, NULL),
> > - X86_MATCH_VFM(INTEL_ATOM_GRACEMONT, NULL),
> > - X86_MATCH_VFM(INTEL_RAPTORLAKE, NULL),
> > - X86_MATCH_VFM(INTEL_RAPTORLAKE_P, NULL),
> > - X86_MATCH_VFM(INTEL_METEORLAKE, NULL),
> > - X86_MATCH_VFM(INTEL_METEORLAKE_L, NULL),
> > - X86_MATCH_VFM(INTEL_ARROWLAKE_U, NULL),
> > - X86_MATCH_VFM(INTEL_ARROWLAKE_H, NULL),
> > - X86_MATCH_VFM(INTEL_PANTHERLAKE_L, NULL),
> > - X86_MATCH_VFM(INTEL_WILDCATLAKE_L, NULL),
> > - X86_MATCH_VFM(INTEL_NOVALAKE, NULL),
> > - X86_MATCH_VFM(INTEL_NOVALAKE_L, NULL),
> > - {}
> > -};
> > -
> > -/* List of MSR-based RAPL PMU support CPUs */
> > -static const struct x86_cpu_id pmu_support_ids[] = {
> > - X86_MATCH_VFM(INTEL_PANTHERLAKE_L, NULL),
> > - X86_MATCH_VFM(INTEL_WILDCATLAKE_L, NULL),
> > - {}
> > -};
> > -
> > static int rapl_check_unit_atom(struct rapl_domain *rd)
> > {
> > struct reg_action ra;
> > @@ -420,6 +393,23 @@ static const struct rapl_defaults
> > rapl_defaults_amd = {
> > .check_unit = rapl_default_check_unit,
> > };
> >
> > +static const struct rapl_defaults rapl_defaults_core_pl4 = {
> > + .floor_freq_reg_addr = 0,
> > + .check_unit = rapl_default_check_unit,
> > + .set_floor_freq = rapl_default_set_floor_freq,
> > + .compute_time_window = rapl_default_compute_time_window,
> > + .msr_pl4_support = 1,
> > +};
> > +
> > +static const struct rapl_defaults rapl_defaults_core_pl4_pmu = {
> > + .floor_freq_reg_addr = 0,
> > + .check_unit = rapl_default_check_unit,
> > + .set_floor_freq = rapl_default_set_floor_freq,
> > + .compute_time_window = rapl_default_compute_time_window,
> > + .msr_pl4_support = 1,
> > + .msr_pmu_support = 1,
> > +};
> > +
> > static const struct x86_cpu_id rapl_ids[] = {
> > X86_MATCH_VFM(INTEL_SANDYBRIDGE, &rapl_defaul
> > ts_core),
> > X86_MATCH_VFM(INTEL_SANDYBRIDGE_X, &rapl_defaul
> > ts_core),
> > @@ -443,35 +433,35 @@ static const struct x86_cpu_id rapl_ids[] = {
> > X86_MATCH_VFM(INTEL_KABYLAKE_L, &rap
> > l_defaults_core),
> > X86_MATCH_VFM(INTEL_KABYLAKE, &rapl_defaul
> > ts_core),
> > X86_MATCH_VFM(INTEL_CANNONLAKE_L, &rapl_defaul
> > ts_core),
> > -
> > X86_MATCH_VFM(INTEL_ICELAKE_L, &rapl_defaults_core),
> > + X86_MATCH_VFM(INTEL_ICELAKE_L, &rapl_defaul
> > ts_core_pl4),
> > X86_MATCH_VFM(INTEL_ICELAKE, &rapl_defaul
> > ts_core),
> > X86_MATCH_VFM(INTEL_ICELAKE_NNPI, &rapl_defaul
> > ts_core),
> > X86_MATCH_VFM(INTEL_ICELAKE_X, &rapl_defaul
> > ts_hsw_server),
> > X86_MATCH_VFM(INTEL_ICELAKE_D, &rapl_defaul
> > ts_hsw_server),
> > X86_MATCH_VFM(INTEL_COMETLAKE_L, &rapl_defaul
> > ts_core),
> > X86_MATCH_VFM(INTEL_COMETLAKE, &rapl_defaul
> > ts_core),
> > -
> > X86_MATCH_VFM(INTEL_TIGERLAKE_L, &rapl_defaults_core),
> > + X86_MATCH_VFM(INTEL_TIGERLAKE_L, &rapl_defaul
> > ts_core_pl4),
> > X86_MATCH_VFM(INTEL_TIGERLAKE, &rapl_defaul
> > ts_core),
> > X86_MATCH_VFM(INTEL_ROCKETLAKE, &rap
> > l_defaults_core),
> > -
> > X86_MATCH_VFM(INTEL_ALDERLAKE, &rapl_defaults_core),
> > -
> > X86_MATCH_VFM(INTEL_ALDERLAKE_L, &rapl_defaults_core),
> > -
> > X86_MATCH_VFM(INTEL_ATOM_GRACEMONT, &rapl_defaults_core),
> > -
> > X86_MATCH_VFM(INTEL_RAPTORLAKE, &rapl_defaults_core),
> > -
> > X86_MATCH_VFM(INTEL_RAPTORLAKE_P, &rapl_defaults_core),
> > + X86_MATCH_VFM(INTEL_ALDERLAKE, &rapl_defaul
> > ts_core_pl4),
> > + X86_MATCH_VFM(INTEL_ALDERLAKE_L, &rapl_defaul
> > ts_core_pl4),
> > + X86_MATCH_VFM(INTEL_ATOM_GRACEMONT, &rapl_defaul
> > ts_core_pl4),
> > + X86_MATCH_VFM(INTEL_RAPTORLAKE, &rap
> > l_defaults_core_pl4),
> > + X86_MATCH_VFM(INTEL_RAPTORLAKE_P, &rapl_defaul
> > ts_core_pl4),
> > X86_MATCH_VFM(INTEL_RAPTORLAKE_S, &rapl_defaul
> > ts_core),
> > X86_MATCH_VFM(INTEL_BARTLETTLAKE, &rapl_defaul
> > ts_core),
> > -
> > X86_MATCH_VFM(INTEL_METEORLAKE, &rapl_defaults_core),
> > -
> > X86_MATCH_VFM(INTEL_METEORLAKE_L, &rapl_defaults_core),
> > + X86_MATCH_VFM(INTEL_METEORLAKE, &rap
> > l_defaults_core_pl4),
> > + X86_MATCH_VFM(INTEL_METEORLAKE_L, &rapl_defaul
> > ts_core_pl4),
> > X86_MATCH_VFM(INTEL_SAPPHIRERAPIDS_X, &rapl_defaul
> > ts_spr_server),
> > X86_MATCH_VFM(INTEL_EMERALDRAPIDS_X, &rapl_defaul
> > ts_spr_server),
> > X86_MATCH_VFM(INTEL_LUNARLAKE_M, &rapl_defaul
> > ts_core),
> > -
> > X86_MATCH_VFM(INTEL_PANTHERLAKE_L, &rapl_defaults_core),
> > -
> > X86_MATCH_VFM(INTEL_WILDCATLAKE_L, &rapl_defaults_core),
> > -
> > X86_MATCH_VFM(INTEL_NOVALAKE, &rapl_defaults_core),
> > -
> > X86_MATCH_VFM(INTEL_NOVALAKE_L, &rapl_defaults_core),
> > -
> > X86_MATCH_VFM(INTEL_ARROWLAKE_H, &rapl_defaults_core),
> > + X86_MATCH_VFM(INTEL_PANTHERLAKE_L, &rapl_defaul
> > ts_core_pl4_pmu),
> > + X86_MATCH_VFM(INTEL_WILDCATLAKE_L, &rapl_defaul
> > ts_core_pl4_pmu),
> > + X86_MATCH_VFM(INTEL_NOVALAKE, &rapl_defaul
> > ts_core_pl4),
> > + X86_MATCH_VFM(INTEL_NOVALAKE_L, &rap
> > l_defaults_core_pl4),
> > + X86_MATCH_VFM(INTEL_ARROWLAKE_H, &rapl_defaul
> > ts_core_pl4),
> > X86_MATCH_VFM(INTEL_ARROWLAKE, &rapl_defaul
> > ts_core),
> > -
> > X86_MATCH_VFM(INTEL_ARROWLAKE_U, &rapl_defaults_core),
> > + X86_MATCH_VFM(INTEL_ARROWLAKE_U, &rapl_defaul
> > ts_core_pl4),
> > X86_MATCH_VFM(INTEL_LAKEFIELD, &rapl_defaul
> > ts_core),
> >
> > X86_MATCH_VFM(INTEL_ATOM_SILVERMONT, &rapl_defaul
> > ts_byt),
> > @@ -498,7 +488,6 @@ MODULE_DEVICE_TABLE(x86cpu, rapl_ids);
> >
> > static int rapl_msr_probe(struct platform_device *pdev)
> > {
> > - const struct x86_cpu_id *id =
> > x86_match_cpu(pl4_support_ids);
> > int ret;
> >
> > switch (boot_cpu_data.x86_vendor) {
> > @@ -518,16 +507,16 @@ static int rapl_msr_probe(struct
> > platform_device *pdev)
> > rapl_msr_priv->defaults = (const struct rapl_defaults
> > *)pdev->dev.platform_data;
> > rapl_msr_priv->rpi = rpi_msr;
> >
> > - if (id) {
> > + if (rapl_msr_priv->defaults->msr_pl4_support) {
> > rapl_msr_priv->limits[RAPL_DOMAIN_PACKAGE] |=
> > BIT(POWER_LIMIT4);
> > rapl_msr_priv-
> > >regs[RAPL_DOMAIN_PACKAGE][RAPL_DOMAIN_REG_PL4].msr =
> > MSR_VR_CURRENT_CONFIG;
> > - pr_info("PL4 support detected.\n");
> > + pr_info("PL4 support detected (updated).\n");
> > }
> >
> > - if (x86_match_cpu(pmu_support_ids)) {
> > + if (rapl_msr_priv->defaults->msr_pmu_support) {
> > rapl_msr_pmu = true;
> > - pr_info("MSR-based RAPL PMU support enabled\n");
> > + pr_info("MSR-based RAPL PMU support enabled
> > (updated)\n");
> > }
> >
> > rapl_msr_priv->control_type =
> > powercap_register_control_type(NULL, "intel-rapl", NULL);
> > diff --git a/include/linux/intel_rapl.h b/include/linux/intel_rapl.h
> > index 01f290de3586..328004f605c3 100644
> > --- a/include/linux/intel_rapl.h
> > +++ b/include/linux/intel_rapl.h
> > @@ -135,6 +135,8 @@ struct rapl_defaults {
> > unsigned int dram_domain_energy_unit;
> > unsigned int psys_domain_energy_unit;
> > bool spr_psys_bits;
> > + bool msr_pl4_support;
> > + bool msr_pmu_support;
> > };
> >
> > #define PRIMITIVE_INFO_INIT(p, m, s, i, u, f) { \
^ permalink raw reply
* Re: [PATCH v11 03/16] mm/secretmem: make use of folio_{zap,restore}_direct_map
From: Ackerley Tng @ 2026-03-23 18:46 UTC (permalink / raw)
To: Kalyazin, Nikita, kvm@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
bpf@vger.kernel.org, linux-kselftest@vger.kernel.org,
kernel@xen0n.name, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, loongarch@lists.linux.dev,
linux-pm@vger.kernel.org
Cc: pbonzini@redhat.com, corbet@lwn.net, maz@kernel.org,
oupton@kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com,
yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org,
seanjc@google.com, tglx@kernel.org, mingo@redhat.com,
bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
hpa@zytor.com, luto@kernel.org, peterz@infradead.org,
willy@infradead.org, akpm@linux-foundation.org, david@kernel.org,
lorenzo.stoakes@oracle.com, vbabka@kernel.org, rppt@kernel.org,
surenb@google.com, mhocko@suse.com, ast@kernel.org,
daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev,
eddyz87@gmail.com, song@kernel.org, yonghong.song@linux.dev,
john.fastabend@gmail.com, kpsingh@kernel.org, sdf@fomichev.me,
haoluo@google.com, jolsa@kernel.org, jgg@ziepe.ca,
jhubbard@nvidia.com, peterx@redhat.com, jannh@google.com,
pfalcato@suse.de, skhan@linuxfoundation.org, riel@surriel.com,
ryan.roberts@arm.com, jgross@suse.com, yu-cheng.yu@intel.com,
kas@kernel.org, coxu@redhat.com, kevin.brodsky@arm.com,
yosry@kernel.org, ajones@ventanamicro.com, maobibo@loongson.cn,
tabba@google.com, prsampat@amd.com, wu.fei9@sanechips.com.cn,
mlevitsk@redhat.com, jmattson@google.com, jthoughton@google.com,
agordeev@linux.ibm.com, alex@ghiti.fr, aou@eecs.berkeley.edu,
borntraeger@linux.ibm.com, chenhuacai@kernel.org,
dev.jain@arm.com, gor@linux.ibm.com, hca@linux.ibm.com,
palmer@dabbelt.com, pjw@kernel.org, shijie@os.amperecomputing.com,
svens@linux.ibm.com, thuth@redhat.com, wyihan@google.com,
yang@os.amperecomputing.com, Jonathan.Cameron@huawei.com,
Liam.Howlett@oracle.com, urezki@gmail.com,
zhengqi.arch@bytedance.com, gerald.schaefer@linux.ibm.com,
jiayuan.chen@shopee.com, lenb@kernel.org, osalvador@suse.de,
pavel@kernel.org, rafael@kernel.org, vannapurve@google.com,
jackmanb@google.com, aneesh.kumar@kernel.org,
patrick.roy@linux.dev, Thomson, Jack, Itazuri, Takahiro,
Manwaring, Derek
In-Reply-To: <20260317141031.514-4-kalyazin@amazon.com>
"Kalyazin, Nikita" <kalyazin@amazon.co.uk> writes:
> From: Nikita Kalyazin <kalyazin@amazon.com>
>
> Signed-off-by: Nikita Kalyazin <kalyazin@amazon.com>
> ---
> mm/secretmem.c | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/mm/secretmem.c b/mm/secretmem.c
> index fd29b33c6764..27b176af8fc4 100644
> --- a/mm/secretmem.c
> +++ b/mm/secretmem.c
> @@ -53,7 +53,6 @@ static vm_fault_t secretmem_fault(struct vm_fault *vmf)
> struct inode *inode = file_inode(vmf->vma->vm_file);
> pgoff_t offset = vmf->pgoff;
> gfp_t gfp = vmf->gfp_mask;
> - unsigned long addr;
> struct folio *folio;
> vm_fault_t ret;
> int err;
> @@ -72,7 +71,7 @@ static vm_fault_t secretmem_fault(struct vm_fault *vmf)
> goto out;
> }
>
> - err = set_direct_map_invalid_noflush(folio_address(folio));
> + err = folio_zap_direct_map(folio);
> if (err) {
> folio_put(folio);
> ret = vmf_error(err);
> @@ -87,7 +86,7 @@ static vm_fault_t secretmem_fault(struct vm_fault *vmf)
> * already happened when we marked the page invalid
> * which guarantees that this call won't fail
> */
> - set_direct_map_default_noflush(folio_address(folio));
> + folio_restore_direct_map(folio);
> folio_put(folio);
> if (err == -EEXIST)
> goto retry;
> @@ -95,9 +94,6 @@ static vm_fault_t secretmem_fault(struct vm_fault *vmf)
> ret = vmf_error(err);
> goto out;
> }
> -
> - addr = (unsigned long)folio_address(folio);
> - flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
> }
>
> vmf->page = folio_file_page(folio, vmf->pgoff);
> --
> 2.50.1
Reviewed-by: Ackerley Tng <ackerleytng@google.com>
^ permalink raw reply
* Re: [PATCH v11 02/16] set_memory: add folio_{zap,restore}_direct_map helpers
From: Ackerley Tng @ 2026-03-23 18:43 UTC (permalink / raw)
To: Kalyazin, Nikita, kvm@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
bpf@vger.kernel.org, linux-kselftest@vger.kernel.org,
kernel@xen0n.name, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, loongarch@lists.linux.dev,
linux-pm@vger.kernel.org
Cc: pbonzini@redhat.com, corbet@lwn.net, maz@kernel.org,
oupton@kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com,
yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org,
seanjc@google.com, tglx@kernel.org, mingo@redhat.com,
bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
hpa@zytor.com, luto@kernel.org, peterz@infradead.org,
willy@infradead.org, akpm@linux-foundation.org, david@kernel.org,
lorenzo.stoakes@oracle.com, vbabka@kernel.org, rppt@kernel.org,
surenb@google.com, mhocko@suse.com, ast@kernel.org,
daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev,
eddyz87@gmail.com, song@kernel.org, yonghong.song@linux.dev,
john.fastabend@gmail.com, kpsingh@kernel.org, sdf@fomichev.me,
haoluo@google.com, jolsa@kernel.org, jgg@ziepe.ca,
jhubbard@nvidia.com, peterx@redhat.com, jannh@google.com,
pfalcato@suse.de, skhan@linuxfoundation.org, riel@surriel.com,
ryan.roberts@arm.com, jgross@suse.com, yu-cheng.yu@intel.com,
kas@kernel.org, coxu@redhat.com, kevin.brodsky@arm.com,
yosry@kernel.org, ajones@ventanamicro.com, maobibo@loongson.cn,
tabba@google.com, prsampat@amd.com, wu.fei9@sanechips.com.cn,
mlevitsk@redhat.com, jmattson@google.com, jthoughton@google.com,
agordeev@linux.ibm.com, alex@ghiti.fr, aou@eecs.berkeley.edu,
borntraeger@linux.ibm.com, chenhuacai@kernel.org,
dev.jain@arm.com, gor@linux.ibm.com, hca@linux.ibm.com,
palmer@dabbelt.com, pjw@kernel.org, shijie@os.amperecomputing.com,
svens@linux.ibm.com, thuth@redhat.com, wyihan@google.com,
yang@os.amperecomputing.com, Jonathan.Cameron@huawei.com,
Liam.Howlett@oracle.com, urezki@gmail.com,
zhengqi.arch@bytedance.com, gerald.schaefer@linux.ibm.com,
jiayuan.chen@shopee.com, lenb@kernel.org, osalvador@suse.de,
pavel@kernel.org, rafael@kernel.org, vannapurve@google.com,
jackmanb@google.com, aneesh.kumar@kernel.org,
patrick.roy@linux.dev, Thomson, Jack, Itazuri, Takahiro,
Manwaring, Derek
In-Reply-To: <20260317141031.514-3-kalyazin@amazon.com>
"Kalyazin, Nikita" <kalyazin@amazon.co.uk> writes:
> From: Nikita Kalyazin <kalyazin@amazon.com>
>
> Let's provide folio_{zap,restore}_direct_map helpers as preparation for
> supporting removal of the direct map for guest_memfd folios.
> In folio_zap_direct_map(), flush TLB to make sure the data is not
> accessible.
>
> The new helpers need to be accessible to KVM on architectures that
> support guest_memfd (x86 and arm64).
>
> Direct map removal gives guest_memfd the same protection that
> memfd_secret does, such as hardening against Spectre-like attacks
> through in-kernel gadgets.
>
> Signed-off-by: Nikita Kalyazin <kalyazin@amazon.com>
> ---
> include/linux/set_memory.h | 13 ++++++++++++
> mm/memory.c | 42 ++++++++++++++++++++++++++++++++++++++
> 2 files changed, 55 insertions(+)
>
> diff --git a/include/linux/set_memory.h b/include/linux/set_memory.h
> index 1a2563f525fc..24caea2931f9 100644
> --- a/include/linux/set_memory.h
> +++ b/include/linux/set_memory.h
> @@ -41,6 +41,15 @@ static inline int set_direct_map_valid_noflush(const void *addr,
> return 0;
> }
>
> +static inline int folio_zap_direct_map(struct folio *folio)
> +{
> + return 0;
> +}
> +
> +static inline void folio_restore_direct_map(struct folio *folio)
> +{
> +}
> +
> static inline bool kernel_page_present(struct page *page)
> {
> return true;
> @@ -57,6 +66,10 @@ static inline bool can_set_direct_map(void)
> }
> #define can_set_direct_map can_set_direct_map
> #endif
> +
> +int folio_zap_direct_map(struct folio *folio);
> +void folio_restore_direct_map(struct folio *folio);
> +
> #endif /* CONFIG_ARCH_HAS_SET_DIRECT_MAP */
>
> #ifdef CONFIG_X86_64
> diff --git a/mm/memory.c b/mm/memory.c
> index 07778814b4a8..cab6bb237fc0 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -78,6 +78,7 @@
> #include <linux/sched/sysctl.h>
> #include <linux/pgalloc.h>
> #include <linux/uaccess.h>
> +#include <linux/set_memory.h>
>
> #include <trace/events/kmem.h>
>
> @@ -7478,3 +7479,44 @@ void vma_pgtable_walk_end(struct vm_area_struct *vma)
> if (is_vm_hugetlb_page(vma))
> hugetlb_vma_unlock_read(vma);
> }
> +
> +#ifdef CONFIG_ARCH_HAS_SET_DIRECT_MAP
> +/**
> + * folio_zap_direct_map - remove a folio from the kernel direct map
> + * @folio: folio to remove from the direct map
> + *
> + * Removes the folio from the kernel direct map and flushes the TLB. This may
> + * require splitting huge pages in the direct map, which can fail due to memory
> + * allocation.
> + *
> + * Return: 0 on success, or a negative error code on failure.
> + */
> +int folio_zap_direct_map(struct folio *folio)
> +{
> + const void *addr = folio_address(folio);
> + int ret;
> +
> + ret = set_direct_map_valid_noflush(addr, folio_nr_pages(folio), false);
> + flush_tlb_kernel_range((unsigned long)addr,
> + (unsigned long)addr + folio_size(folio));
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_FOR_MODULES(folio_zap_direct_map, "kvm");
> +
> +/**
> + * folio_restore_direct_map - restore the kernel direct map entry for a folio
> + * @folio: folio whose direct map entry is to be restored
> + *
> + * This may only be called after a prior successful folio_zap_direct_map() on
> + * the same folio. Because the zap will have already split any huge pages in
> + * the direct map, restoration here only updates protection bits and cannot
> + * fail.
> + */
> +void folio_restore_direct_map(struct folio *folio)
> +{
> + WARN_ON_ONCE(set_direct_map_valid_noflush(folio_address(folio),
> + folio_nr_pages(folio), true));
> +}
> +EXPORT_SYMBOL_FOR_MODULES(folio_restore_direct_map, "kvm");
> +#endif /* CONFIG_ARCH_HAS_SET_DIRECT_MAP */
> --
> 2.50.1
Reviewed-by: Ackerley Tng <ackerleytng@google.com>
I also took a look at Sashiko's [1] comments and I think that the
highmem folio issues should be the responsibility of the caller to
check.
[1] https://sashiko.dev/#/patchset/20260317141031.514-1-kalyazin%40amazon.com
^ permalink raw reply
* Re: [PATCH v3 3/4] cpupower-frequency-info.1: document --boost and --epp options
From: Shuah Khan @ 2026-03-23 18:34 UTC (permalink / raw)
To: Roberto Ricci, Thomas Renninger, Shuah Khan, John B. Wyatt IV,
John Kacur, linux-pm, linux-kernel, Shuah Khan
In-Reply-To: <20260312102029.14980-3-io@r-ricci.it>
On 3/12/26 04:20, Roberto Ricci wrote:
> `cpupower frequency-info` supports the '--boost' option since the
> program was first added with commit
> 7fe2f6399a84 ("cpupowerutils - cpufrequtils extended with quite some features")
> but the man page lacks it.
>
> '--epp' has been added with commit
> 5f567afc283f ("cpupower: Add support for showing energy performance preference")
> but it has never been added to the man page.
>
> cpufreq-info.c:
> {"boost", no_argument, NULL, 'b'},
> ...
> {"epp", no_argument, NULL, 'z'},
>
> Fixes 7fe2f6399a84760a9af8896ac152728250f82adb ("cpupowerutils - cpufrequtils extended with quite some features")
> Fixes 5f567afc283fc9e7c6a34d013c4fc6c5e8d6afae ("cpupower: Add support for showing energy performance preference")
>
Remove Fixes tag from all these 4 patches and run checkpatch
before sending patches to me adding version information.
+ add a cover letter is helpful and makes it easier to comment
on things common across all patches such as these.
thanks,
-- Shuah
^ permalink raw reply
* Re: [PATCH v3 4/4] cpupower-info.1: describe the --perf-bias option
From: Shuah Khan @ 2026-03-23 18:34 UTC (permalink / raw)
To: Roberto Ricci, Thomas Renninger, Shuah Khan, John B. Wyatt IV,
John Kacur, linux-pm, linux-kernel, Shuah Khan
In-Reply-To: <20260312102029.14980-4-io@r-ricci.it>
On 3/12/26 04:20, Roberto Ricci wrote:
> The cpupower-info(1) man page only mentions the short form of the
> '--perf-bias' option in the synopsys, but the long form is not
> documented and its effect is not explained.
>
> Fixes 7fe2f6399a84760a9af8896ac152728250f82adb ("cpupowerutils - cpufrequtils extended with quite some features")
>
> Signed-off-by: Roberto Ricci <io@r-ricci.it>
Remove Fixes tag from all these 4 patches and run checkpatch
before sending patches to me adding version information.
+ add a cover letter is helpful and makes it easier to comment
on things common across all patches such as these.
thanks,
-- Shuah
^ permalink raw reply
* Re: [PATCH v3 2/4] cpupower-frequency-info.1: use the proper name of the --perf option
From: Shuah Khan @ 2026-03-23 18:32 UTC (permalink / raw)
To: Roberto Ricci, Thomas Renninger, Shuah Khan, John B. Wyatt IV,
John Kacur, linux-pm, linux-kernel, Shuah Khan
In-Reply-To: <20260312102029.14980-2-io@r-ricci.it>
On 3/12/26 04:20, Roberto Ricci wrote:
> The cpupower-frequency-info(1) man page describes a '--perf' option.
> Even though this form is accepted by the program, its proper name is
> '--performance'.
>
> cpufreq-info.c:
> {"performance", no_argument, NULL, 'c'},
>
> Fixes 8382dce5e4835c045f33b8958a5f559d212cdd11 ("cpupower: Add "perf" option to print AMD P-State information")
Remove Fixes tag from all these 4 patches and run checkpatch
before sending patches to me adding version information.
thanks,
-- Shuah
^ permalink raw reply
* Re: [PATCH v11 04/16] mm/gup: drop secretmem optimization from gup_fast_folio_allowed
From: David Hildenbrand (Arm) @ 2026-03-23 18:31 UTC (permalink / raw)
To: Kalyazin, Nikita, kvm@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
bpf@vger.kernel.org, linux-kselftest@vger.kernel.org,
kernel@xen0n.name, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, loongarch@lists.linux.dev,
linux-pm@vger.kernel.org
Cc: pbonzini@redhat.com, corbet@lwn.net, maz@kernel.org,
oupton@kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com,
yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org,
seanjc@google.com, tglx@kernel.org, mingo@redhat.com,
bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
hpa@zytor.com, luto@kernel.org, peterz@infradead.org,
willy@infradead.org, akpm@linux-foundation.org,
lorenzo.stoakes@oracle.com, vbabka@kernel.org, rppt@kernel.org,
surenb@google.com, mhocko@suse.com, ast@kernel.org,
daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev,
eddyz87@gmail.com, song@kernel.org, yonghong.song@linux.dev,
john.fastabend@gmail.com, kpsingh@kernel.org, sdf@fomichev.me,
haoluo@google.com, jolsa@kernel.org, jgg@ziepe.ca,
jhubbard@nvidia.com, peterx@redhat.com, jannh@google.com,
pfalcato@suse.de, skhan@linuxfoundation.org, riel@surriel.com,
ryan.roberts@arm.com, jgross@suse.com, yu-cheng.yu@intel.com,
kas@kernel.org, coxu@redhat.com, kevin.brodsky@arm.com,
ackerleytng@google.com, yosry@kernel.org, ajones@ventanamicro.com,
maobibo@loongson.cn, tabba@google.com, prsampat@amd.com,
wu.fei9@sanechips.com.cn, mlevitsk@redhat.com,
jmattson@google.com, jthoughton@google.com,
agordeev@linux.ibm.com, alex@ghiti.fr, aou@eecs.berkeley.edu,
borntraeger@linux.ibm.com, chenhuacai@kernel.org,
dev.jain@arm.com, gor@linux.ibm.com, hca@linux.ibm.com,
palmer@dabbelt.com, pjw@kernel.org, shijie@os.amperecomputing.com,
svens@linux.ibm.com, thuth@redhat.com, wyihan@google.com,
yang@os.amperecomputing.com, Jonathan.Cameron@huawei.com,
Liam.Howlett@oracle.com, urezki@gmail.com,
zhengqi.arch@bytedance.com, gerald.schaefer@linux.ibm.com,
jiayuan.chen@shopee.com, lenb@kernel.org, osalvador@suse.de,
pavel@kernel.org, rafael@kernel.org, vannapurve@google.com,
jackmanb@google.com, aneesh.kumar@kernel.org,
patrick.roy@linux.dev, Thomson, Jack, Itazuri, Takahiro,
Manwaring, Derek, Vlastimil Babka, Dan Williams, Alistair Popple
In-Reply-To: <20260317141031.514-5-kalyazin@amazon.com>
On 3/17/26 15:11, Kalyazin, Nikita wrote:
> From: Patrick Roy <patrick.roy@linux.dev>
>
> This drops an optimization in gup_fast_folio_allowed() where
> secretmem_mapping() was only called if CONFIG_SECRETMEM=y. secretmem is
> enabled by default since commit b758fe6df50d ("mm/secretmem: make it on
> by default"), so the secretmem check did not actually end up elided in
> most cases anymore anyway.
>
> This is in preparation of the generalization of handling mappings where
> direct map entries of folios are set to not present. Currently,
> mappings that match this description are secretmem mappings
> (memfd_secret()). Later, some guest_memfd configurations will also fall
> into this category.
>
> Signed-off-by: Patrick Roy <patrick.roy@linux.dev>
> Acked-by: Vlastimil Babka <vbabka@suse.cz>
> Acked-by: David Hildenbrand (Red Hat) <david@kernel.org>
> Signed-off-by: Nikita Kalyazin <kalyazin@amazon.com>
> ---
> mm/gup.c | 11 +----------
> 1 file changed, 1 insertion(+), 10 deletions(-)
>
> diff --git a/mm/gup.c b/mm/gup.c
> index 8e7dc2c6ee73..5856d35be385 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -2739,7 +2739,6 @@ static bool gup_fast_folio_allowed(struct folio *folio, unsigned int flags)
> {
> bool reject_file_backed = false;
> struct address_space *mapping;
> - bool check_secretmem = false;
> unsigned long mapping_flags;
>
> /*
> @@ -2751,14 +2750,6 @@ static bool gup_fast_folio_allowed(struct folio *folio, unsigned int flags)
> reject_file_backed = true;
>
> /* We hold a folio reference, so we can safely access folio fields. */
> -
> - /* secretmem folios are always order-0 folios. */
> - if (IS_ENABLED(CONFIG_SECRETMEM) && !folio_test_large(folio))
> - check_secretmem = true;
> -
> - if (!reject_file_backed && !check_secretmem)
> - return true;
> -
The AI review says that this will force all small folios through the
mapping check (which we obviously need later :) ).
It brings up two cases where page->mapping is not set up:
1) ZONE_DEVICE pages (like Device DAX and PCI P2PDMA)
2) large shmem folios in the swap cache
2) doesn't make sense, because the folio cannot be mapped in user space
when that happens.
I am also skeptical about 1), especially as large folios are also
supported for device dax and would be problematic here.
__dev_dax_pte_fault() clearly sets folio->mapping through dax_set_mapping().
If 1) is ever a case we could allow them by checking for
folio_is_zone_device(). But I am not sure if that is really required.
Sounds weird.
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v3 1/4] cpupower-idle-info.1: fix short option names
From: Shuah Khan @ 2026-03-23 18:31 UTC (permalink / raw)
To: Roberto Ricci, Thomas Renninger, Shuah Khan, John B. Wyatt IV,
John Kacur, linux-pm, linux-kernel, Shuah Khan
In-Reply-To: <20260312102029.14980-1-io@r-ricci.it>
On 3/12/26 04:20, Roberto Ricci wrote:
> The cpupower-idle-info(1) man page describes '-f' as the short form of
> the '--silent' option and '-e' as the short form of the '--proc' option.
> But they are not correct:
>
> $ cpupower idle-info -f
> idle-info: invalid option -- 'f'
> invalid or unknown argument
> $ cpupower idle-info -e
> idle-info: invalid option -- 'e'
> invalid or unknown argument
>
> The short form of '--silent' is actually '-s' and the short form of
> '--proc' is actually 'o':
>
> cpuidle-info.c:
> {"silent", no_argument, NULL, 's'},
> {"proc", no_argument, NULL, 'o'},
>
> Fixes e7d85a934182d5bde1eea865169fbf2e0637a3ed ("cpupower: Add cpupower-idle-info manpage")
There is no need t for Fixes tag in any of these patches.
Fixes tag is used when you fix a bug in code. Using Fixes
for every single patch adds lot of churn for stable releases.
Remove Fixes tag from all these 4 patches and run checkpatch
before sending patches to me adding version information.
Incorrect fixes style in all of these 4 patches. Running checkpatch
helps you catch these error before I see them.
ERROR: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit e7d85a934182 ("cpupower: Add cpupower-idle-info manpage")'
#86:
>
> Signed-off-by: Roberto Ricci <io@r-ricci.it>
> ---
Adding changes in since patch v1 makes reviewers job easier.
We can easily our comments are addressed or not.
> tools/power/cpupower/man/cpupower-idle-info.1 | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools/power/cpupower/man/cpupower-idle-info.1 b/tools/power/cpupower/man/cpupower-idle-info.1
> index 20b6345c53ad..b2f92aba5f5b 100644
> --- a/tools/power/cpupower/man/cpupower-idle-info.1
> +++ b/tools/power/cpupower/man/cpupower-idle-info.1
> @@ -11,10 +11,10 @@ A tool which prints out per cpu idle information helpful to developers and inter
> .SH "OPTIONS"
> .LP
> .TP
> -\fB\-f\fR \fB\-\-silent\fR
> +\fB\-s\fR \fB\-\-silent\fR
> Only print a summary of all available C-states in the system.
> .TP
> -\fB\-e\fR \fB\-\-proc\fR
> +\fB\-o\fR \fB\-\-proc\fR
> deprecated.
> Prints out idle information in old /proc/acpi/processor/*/power format. This
> interface has been removed from the kernel for quite some time, do not let
thanks,
-- Shuah
^ permalink raw reply
* Re: [PATCH v1] powercap: intel_rapl: Consolidate PL4 and PMU support flags into rapl_defaults
From: srinivas pandruvada @ 2026-03-23 18:20 UTC (permalink / raw)
To: Kuppuswamy Sathyanarayanan, Rafael J . Wysocki; +Cc: linux-pm, linux-kernel
In-Reply-To: <20260313190052.2370963-1-sathyanarayanan.kuppuswamy@linux.intel.com>
On Fri, 2026-03-13 at 12:00 -0700, Kuppuswamy Sathyanarayanan wrote:
> Currently, PL4 and MSR-based RAPL PMU support are detected using
> separate CPU ID tables (pl4_support_ids and pmu_support_ids) in the
> MSR driver probe path. This creates a maintenance burden since adding
> a new CPU requires updates in two places: the rapl_ids table and one
> or both of these capability tables.
>
> Consolidate PL4 and PMU capability information directly into
> struct rapl_defaults by adding msr_pl4_support and msr_pmu_support
> flags. This allows per-CPU capability to be expressed in a single
> place alongside other per-CPU defaults, eliminating the duplicate
> CPU ID tables entirely.
>
> No functional changes are intended.
>
> Co-developed-by: Zhang Rui <rui.zhang@intel.com>
> Signed-off-by: Zhang Rui <rui.zhang@intel.com>
> Signed-off-by: Kuppuswamy Sathyanarayanan
> <sathyanarayanan.kuppuswamy@linux.intel.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> ---
> drivers/powercap/intel_rapl_msr.c | 83 ++++++++++++++---------------
> --
> include/linux/intel_rapl.h | 2 +
> 2 files changed, 38 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/powercap/intel_rapl_msr.c
> b/drivers/powercap/intel_rapl_msr.c
> index cfb35973f0b5..a34543e66446 100644
> --- a/drivers/powercap/intel_rapl_msr.c
> +++ b/drivers/powercap/intel_rapl_msr.c
> @@ -216,33 +216,6 @@ static int rapl_msr_write_raw(int cpu, struct
> reg_action *ra)
> return ra->err;
> }
>
> -/* List of verified CPUs. */
> -static const struct x86_cpu_id pl4_support_ids[] = {
> - X86_MATCH_VFM(INTEL_ICELAKE_L, NULL),
> - X86_MATCH_VFM(INTEL_TIGERLAKE_L, NULL),
> - X86_MATCH_VFM(INTEL_ALDERLAKE, NULL),
> - X86_MATCH_VFM(INTEL_ALDERLAKE_L, NULL),
> - X86_MATCH_VFM(INTEL_ATOM_GRACEMONT, NULL),
> - X86_MATCH_VFM(INTEL_RAPTORLAKE, NULL),
> - X86_MATCH_VFM(INTEL_RAPTORLAKE_P, NULL),
> - X86_MATCH_VFM(INTEL_METEORLAKE, NULL),
> - X86_MATCH_VFM(INTEL_METEORLAKE_L, NULL),
> - X86_MATCH_VFM(INTEL_ARROWLAKE_U, NULL),
> - X86_MATCH_VFM(INTEL_ARROWLAKE_H, NULL),
> - X86_MATCH_VFM(INTEL_PANTHERLAKE_L, NULL),
> - X86_MATCH_VFM(INTEL_WILDCATLAKE_L, NULL),
> - X86_MATCH_VFM(INTEL_NOVALAKE, NULL),
> - X86_MATCH_VFM(INTEL_NOVALAKE_L, NULL),
> - {}
> -};
> -
> -/* List of MSR-based RAPL PMU support CPUs */
> -static const struct x86_cpu_id pmu_support_ids[] = {
> - X86_MATCH_VFM(INTEL_PANTHERLAKE_L, NULL),
> - X86_MATCH_VFM(INTEL_WILDCATLAKE_L, NULL),
> - {}
> -};
> -
> static int rapl_check_unit_atom(struct rapl_domain *rd)
> {
> struct reg_action ra;
> @@ -420,6 +393,23 @@ static const struct rapl_defaults
> rapl_defaults_amd = {
> .check_unit = rapl_default_check_unit,
> };
>
> +static const struct rapl_defaults rapl_defaults_core_pl4 = {
> + .floor_freq_reg_addr = 0,
> + .check_unit = rapl_default_check_unit,
> + .set_floor_freq = rapl_default_set_floor_freq,
> + .compute_time_window = rapl_default_compute_time_window,
> + .msr_pl4_support = 1,
> +};
> +
> +static const struct rapl_defaults rapl_defaults_core_pl4_pmu = {
> + .floor_freq_reg_addr = 0,
> + .check_unit = rapl_default_check_unit,
> + .set_floor_freq = rapl_default_set_floor_freq,
> + .compute_time_window = rapl_default_compute_time_window,
> + .msr_pl4_support = 1,
> + .msr_pmu_support = 1,
> +};
> +
> static const struct x86_cpu_id rapl_ids[] = {
> X86_MATCH_VFM(INTEL_SANDYBRIDGE, &rapl_defaul
> ts_core),
> X86_MATCH_VFM(INTEL_SANDYBRIDGE_X, &rapl_defaul
> ts_core),
> @@ -443,35 +433,35 @@ static const struct x86_cpu_id rapl_ids[] = {
> X86_MATCH_VFM(INTEL_KABYLAKE_L, &rap
> l_defaults_core),
> X86_MATCH_VFM(INTEL_KABYLAKE, &rapl_defaul
> ts_core),
> X86_MATCH_VFM(INTEL_CANNONLAKE_L, &rapl_defaul
> ts_core),
> -
> X86_MATCH_VFM(INTEL_ICELAKE_L, &rapl_defaults_core),
> + X86_MATCH_VFM(INTEL_ICELAKE_L, &rapl_defaul
> ts_core_pl4),
> X86_MATCH_VFM(INTEL_ICELAKE, &rapl_defaul
> ts_core),
> X86_MATCH_VFM(INTEL_ICELAKE_NNPI, &rapl_defaul
> ts_core),
> X86_MATCH_VFM(INTEL_ICELAKE_X, &rapl_defaul
> ts_hsw_server),
> X86_MATCH_VFM(INTEL_ICELAKE_D, &rapl_defaul
> ts_hsw_server),
> X86_MATCH_VFM(INTEL_COMETLAKE_L, &rapl_defaul
> ts_core),
> X86_MATCH_VFM(INTEL_COMETLAKE, &rapl_defaul
> ts_core),
> -
> X86_MATCH_VFM(INTEL_TIGERLAKE_L, &rapl_defaults_core),
> + X86_MATCH_VFM(INTEL_TIGERLAKE_L, &rapl_defaul
> ts_core_pl4),
> X86_MATCH_VFM(INTEL_TIGERLAKE, &rapl_defaul
> ts_core),
> X86_MATCH_VFM(INTEL_ROCKETLAKE, &rap
> l_defaults_core),
> -
> X86_MATCH_VFM(INTEL_ALDERLAKE, &rapl_defaults_core),
> -
> X86_MATCH_VFM(INTEL_ALDERLAKE_L, &rapl_defaults_core),
> -
> X86_MATCH_VFM(INTEL_ATOM_GRACEMONT, &rapl_defaults_core),
> -
> X86_MATCH_VFM(INTEL_RAPTORLAKE, &rapl_defaults_core),
> -
> X86_MATCH_VFM(INTEL_RAPTORLAKE_P, &rapl_defaults_core),
> + X86_MATCH_VFM(INTEL_ALDERLAKE, &rapl_defaul
> ts_core_pl4),
> + X86_MATCH_VFM(INTEL_ALDERLAKE_L, &rapl_defaul
> ts_core_pl4),
> + X86_MATCH_VFM(INTEL_ATOM_GRACEMONT, &rapl_defaul
> ts_core_pl4),
> + X86_MATCH_VFM(INTEL_RAPTORLAKE, &rap
> l_defaults_core_pl4),
> + X86_MATCH_VFM(INTEL_RAPTORLAKE_P, &rapl_defaul
> ts_core_pl4),
> X86_MATCH_VFM(INTEL_RAPTORLAKE_S, &rapl_defaul
> ts_core),
> X86_MATCH_VFM(INTEL_BARTLETTLAKE, &rapl_defaul
> ts_core),
> -
> X86_MATCH_VFM(INTEL_METEORLAKE, &rapl_defaults_core),
> -
> X86_MATCH_VFM(INTEL_METEORLAKE_L, &rapl_defaults_core),
> + X86_MATCH_VFM(INTEL_METEORLAKE, &rap
> l_defaults_core_pl4),
> + X86_MATCH_VFM(INTEL_METEORLAKE_L, &rapl_defaul
> ts_core_pl4),
> X86_MATCH_VFM(INTEL_SAPPHIRERAPIDS_X, &rapl_defaul
> ts_spr_server),
> X86_MATCH_VFM(INTEL_EMERALDRAPIDS_X, &rapl_defaul
> ts_spr_server),
> X86_MATCH_VFM(INTEL_LUNARLAKE_M, &rapl_defaul
> ts_core),
> -
> X86_MATCH_VFM(INTEL_PANTHERLAKE_L, &rapl_defaults_core),
> -
> X86_MATCH_VFM(INTEL_WILDCATLAKE_L, &rapl_defaults_core),
> -
> X86_MATCH_VFM(INTEL_NOVALAKE, &rapl_defaults_core),
> -
> X86_MATCH_VFM(INTEL_NOVALAKE_L, &rapl_defaults_core),
> -
> X86_MATCH_VFM(INTEL_ARROWLAKE_H, &rapl_defaults_core),
> + X86_MATCH_VFM(INTEL_PANTHERLAKE_L, &rapl_defaul
> ts_core_pl4_pmu),
> + X86_MATCH_VFM(INTEL_WILDCATLAKE_L, &rapl_defaul
> ts_core_pl4_pmu),
> + X86_MATCH_VFM(INTEL_NOVALAKE, &rapl_defaul
> ts_core_pl4),
> + X86_MATCH_VFM(INTEL_NOVALAKE_L, &rap
> l_defaults_core_pl4),
> + X86_MATCH_VFM(INTEL_ARROWLAKE_H, &rapl_defaul
> ts_core_pl4),
> X86_MATCH_VFM(INTEL_ARROWLAKE, &rapl_defaul
> ts_core),
> -
> X86_MATCH_VFM(INTEL_ARROWLAKE_U, &rapl_defaults_core),
> + X86_MATCH_VFM(INTEL_ARROWLAKE_U, &rapl_defaul
> ts_core_pl4),
> X86_MATCH_VFM(INTEL_LAKEFIELD, &rapl_defaul
> ts_core),
>
> X86_MATCH_VFM(INTEL_ATOM_SILVERMONT, &rapl_defaul
> ts_byt),
> @@ -498,7 +488,6 @@ MODULE_DEVICE_TABLE(x86cpu, rapl_ids);
>
> static int rapl_msr_probe(struct platform_device *pdev)
> {
> - const struct x86_cpu_id *id =
> x86_match_cpu(pl4_support_ids);
> int ret;
>
> switch (boot_cpu_data.x86_vendor) {
> @@ -518,16 +507,16 @@ static int rapl_msr_probe(struct
> platform_device *pdev)
> rapl_msr_priv->defaults = (const struct rapl_defaults
> *)pdev->dev.platform_data;
> rapl_msr_priv->rpi = rpi_msr;
>
> - if (id) {
> + if (rapl_msr_priv->defaults->msr_pl4_support) {
> rapl_msr_priv->limits[RAPL_DOMAIN_PACKAGE] |=
> BIT(POWER_LIMIT4);
> rapl_msr_priv-
> >regs[RAPL_DOMAIN_PACKAGE][RAPL_DOMAIN_REG_PL4].msr =
> MSR_VR_CURRENT_CONFIG;
> - pr_info("PL4 support detected.\n");
> + pr_info("PL4 support detected (updated).\n");
> }
>
> - if (x86_match_cpu(pmu_support_ids)) {
> + if (rapl_msr_priv->defaults->msr_pmu_support) {
> rapl_msr_pmu = true;
> - pr_info("MSR-based RAPL PMU support enabled\n");
> + pr_info("MSR-based RAPL PMU support enabled
> (updated)\n");
> }
>
> rapl_msr_priv->control_type =
> powercap_register_control_type(NULL, "intel-rapl", NULL);
> diff --git a/include/linux/intel_rapl.h b/include/linux/intel_rapl.h
> index 01f290de3586..328004f605c3 100644
> --- a/include/linux/intel_rapl.h
> +++ b/include/linux/intel_rapl.h
> @@ -135,6 +135,8 @@ struct rapl_defaults {
> unsigned int dram_domain_energy_unit;
> unsigned int psys_domain_energy_unit;
> bool spr_psys_bits;
> + bool msr_pl4_support;
> + bool msr_pmu_support;
> };
>
> #define PRIMITIVE_INFO_INIT(p, m, s, i, u, f) { \
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: power: reset: qcom-pon: Add new compatible PMM8654AU
From: Rob Herring @ 2026-03-23 18:18 UTC (permalink / raw)
To: Rakesh Kota
Cc: Sebastian Reichel, Krzysztof Kozlowski, Conor Dooley, Vinod Koul,
Bjorn Andersson, Konrad Dybcio, linux-pm, devicetree,
linux-kernel, linux-arm-msm, Dmitry Baryshkov
In-Reply-To: <20260323-b4-add_pwrkey_and_resin-v4-1-abef4e4dcc3d@oss.qualcomm.com>
On Mon, Mar 23, 2026 at 04:15:15PM +0530, Rakesh Kota wrote:
> PMM8654AU is a different PMIC from PMM8650AU, even though both share
> the same PMIC subtype. Add PON compatible string for PMM8654AU PMIC
> variant.
>
> The PMM8654AU PON block is compatible with the PMK8350 PON
> implementation, but PMM8654AU also implements additional PON registers
> beyond the baseline. Use the PMM8654AU naming to match the compatible
> string already present in the upstream pinctrl-spmi-gpio driver, keeping
> device tree and kernel driver naming consistent.
>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Rakesh Kota <rakesh.kota@oss.qualcomm.com>
> ---
> Changes in v4:
> - Remove the contain for PMK8350 and new if:then for PMM8654AU as
> suggested by Krzysztof Kozlowski
>
> Changes in v3:
> - Update the commit message.
>
> Changes in v2:
> - Introduces PMM8654AU compatible strings as suggested by Konrad Dybcio.
> ---
> .../devicetree/bindings/power/reset/qcom,pon.yaml | 32 +++++++++++++++++-----
> 1 file changed, 25 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml b/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml
> index 979a377cb4ffd577bfa51b9a3cd089acc202de0c..2a5d9182b8d5c1a286716ab175c7bb5e39b334e0 100644
> --- a/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml
> +++ b/Documentation/devicetree/bindings/power/reset/qcom,pon.yaml
> @@ -17,12 +17,16 @@ description: |
>
> properties:
> compatible:
> - enum:
> - - qcom,pm8916-pon
> - - qcom,pm8941-pon
> - - qcom,pms405-pon
> - - qcom,pm8998-pon
> - - qcom,pmk8350-pon
> + oneOf:
> + - enum:
> + - qcom,pm8916-pon
> + - qcom,pm8941-pon
> + - qcom,pms405-pon
> + - qcom,pm8998-pon
> + - qcom,pmk8350-pon
> + - items:
> + - const: qcom,pmm8654au-pon
> + - const: qcom,pmk8350-pon
>
> reg:
> description: |
> @@ -100,7 +104,6 @@ allOf:
> - if:
> properties:
> compatible:
> - contains:
> const: qcom,pmk8350-pon
> then:
> properties:
> @@ -113,6 +116,21 @@ allOf:
> - const: hlos
> - const: pbs
>
> + - if:
> + properties:
> + compatible:
> + const: qcom,pmm8654au-pon
> + then:
> + properties:
> + reg:
> + minItems: 1
> + maxItems: 2
> + reg-names:
> + minItems: 1
> + items:
> + - const: hlos
> + - const: pbs
I don't understand this. The existing if/then schema did the exact same
thing until you removed 'contains'. Now we just have the same schema
duplicated.
What does need changing now that I've looked at it is dropping 'reg'
in this schema as it just repeats what the top-level schema has.
Rob
^ permalink raw reply
* Re: [PATCH v8 8/9] dax/hmem, cxl: Defer and resolve Soft Reserved ownership
From: Dave Jiang @ 2026-03-23 18:17 UTC (permalink / raw)
To: Smita Koralahalli, linux-cxl, linux-kernel, nvdimm, linux-fsdevel,
linux-pm
Cc: Ard Biesheuvel, Alison Schofield, Vishal Verma, Ira Weiny,
Dan Williams, Jonathan Cameron, Yazen Ghannam, Davidlohr Bueso,
Matthew Wilcox, Jan Kara, Rafael J . Wysocki, Len Brown,
Pavel Machek, Li Ming, Jeff Johnson, Ying Huang, Yao Xingtao,
Peter Zijlstra, Greg Kroah-Hartman, Nathan Fontenot, Terry Bowman,
Robert Richter, Benjamin Cheatham, Zhijian Li, Borislav Petkov,
Tomasz Wolski
In-Reply-To: <20260322195343.206900-9-Smita.KoralahalliChannabasappa@amd.com>
On 3/22/26 12:53 PM, Smita Koralahalli wrote:
> The current probe time ownership check for Soft Reserved memory based
> solely on CXL window intersection is insufficient. dax_hmem probing is not
> always guaranteed to run after CXL enumeration and region assembly, which
> can lead to incorrect ownership decisions before the CXL stack has
> finished publishing windows and assembling committed regions.
>
> Introduce deferred ownership handling for Soft Reserved ranges that
> intersect CXL windows. When such a range is encountered during the
> initial dax_hmem probe, schedule deferred work to wait for the CXL stack
> to complete enumeration and region assembly before deciding ownership.
>
> Once the deferred work runs, evaluate each Soft Reserved range
> individually: if a CXL region fully contains the range, skip it and let
> dax_cxl bind. Otherwise, register it with dax_hmem. This per-range
> ownership model avoids the need for CXL region teardown and
> alloc_dax_region() resource exclusion prevents double claiming.
>
> Introduce a boolean flag dax_hmem_initial_probe to live inside device.c
> so it survives module reload. Ensure dax_cxl defers driver registration
> until dax_hmem has completed ownership resolution. dax_cxl calls
> dax_hmem_flush_work() before cxl_driver_register(), which both waits for
> the deferred work to complete and creates a module symbol dependency that
> forces dax_hmem.ko to load before dax_cxl.
>
> Co-developed-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
> ---
> drivers/dax/bus.h | 7 ++++
> drivers/dax/cxl.c | 1 +
> drivers/dax/hmem/device.c | 3 ++
> drivers/dax/hmem/hmem.c | 74 +++++++++++++++++++++++++++++++++++++++
> 4 files changed, 85 insertions(+)
>
> diff --git a/drivers/dax/bus.h b/drivers/dax/bus.h
> index cbbf64443098..ebbfe2d6da14 100644
> --- a/drivers/dax/bus.h
> +++ b/drivers/dax/bus.h
> @@ -49,6 +49,13 @@ void dax_driver_unregister(struct dax_device_driver *dax_drv);
> void kill_dev_dax(struct dev_dax *dev_dax);
> bool static_dev_dax(struct dev_dax *dev_dax);
>
> +#if IS_ENABLED(CONFIG_DEV_DAX_HMEM)
> +extern bool dax_hmem_initial_probe;
> +void dax_hmem_flush_work(void);
> +#else
> +static inline void dax_hmem_flush_work(void) { }
> +#endif
> +
> #define MODULE_ALIAS_DAX_DEVICE(type) \
> MODULE_ALIAS("dax:t" __stringify(type) "*")
> #define DAX_DEVICE_MODALIAS_FMT "dax:t%d"
> diff --git a/drivers/dax/cxl.c b/drivers/dax/cxl.c
> index a2136adfa186..3ab39b77843d 100644
> --- a/drivers/dax/cxl.c
> +++ b/drivers/dax/cxl.c
> @@ -44,6 +44,7 @@ static struct cxl_driver cxl_dax_region_driver = {
>
> static void cxl_dax_region_driver_register(struct work_struct *work)
> {
> + dax_hmem_flush_work();
> cxl_driver_register(&cxl_dax_region_driver);
> }
>
> diff --git a/drivers/dax/hmem/device.c b/drivers/dax/hmem/device.c
> index 56e3cbd181b5..991a4bf7d969 100644
> --- a/drivers/dax/hmem/device.c
> +++ b/drivers/dax/hmem/device.c
> @@ -8,6 +8,9 @@
> static bool nohmem;
> module_param_named(disable, nohmem, bool, 0444);
>
> +bool dax_hmem_initial_probe;
> +EXPORT_SYMBOL_GPL(dax_hmem_initial_probe);
> +
> static bool platform_initialized;
> static DEFINE_MUTEX(hmem_resource_lock);
> static struct resource hmem_active = {
> diff --git a/drivers/dax/hmem/hmem.c b/drivers/dax/hmem/hmem.c
> index ca752db03201..9ceda6b5cadf 100644
> --- a/drivers/dax/hmem/hmem.c
> +++ b/drivers/dax/hmem/hmem.c
> @@ -3,6 +3,7 @@
> #include <linux/memregion.h>
> #include <linux/module.h>
> #include <linux/dax.h>
> +#include <cxl/cxl.h>
> #include "../bus.h"
>
> static bool region_idle;
> @@ -58,6 +59,23 @@ static void release_hmem(void *pdev)
> platform_device_unregister(pdev);
> }
>
> +struct dax_defer_work {
> + struct platform_device *pdev;
> + struct work_struct work;
> +};
> +
> +static void process_defer_work(struct work_struct *w);
> +
> +static struct dax_defer_work dax_hmem_work = {
> + .work = __WORK_INITIALIZER(dax_hmem_work.work, process_defer_work),
> +};
> +
> +void dax_hmem_flush_work(void)
> +{
> + flush_work(&dax_hmem_work.work);
> +}
> +EXPORT_SYMBOL_GPL(dax_hmem_flush_work);
> +
> static int __hmem_register_device(struct device *host, int target_nid,
> const struct resource *res)
> {
> @@ -122,6 +140,11 @@ static int hmem_register_device(struct device *host, int target_nid,
> if (IS_ENABLED(CONFIG_DEV_DAX_CXL) &&
> region_intersects(res->start, resource_size(res), IORESOURCE_MEM,
> IORES_DESC_CXL) != REGION_DISJOINT) {
> + if (!dax_hmem_initial_probe) {
> + dev_dbg(host, "await CXL initial probe: %pr\n", res);
> + queue_work(system_long_wq, &dax_hmem_work.work);
> + return 0;
> + }
> dev_dbg(host, "deferring range to CXL: %pr\n", res);
> return 0;
> }
> @@ -129,8 +152,54 @@ static int hmem_register_device(struct device *host, int target_nid,
> return __hmem_register_device(host, target_nid, res);
> }
>
> +static int hmem_register_cxl_device(struct device *host, int target_nid,
> + const struct resource *res)
> +{
> + if (region_intersects(res->start, resource_size(res), IORESOURCE_MEM,
> + IORES_DESC_CXL) == REGION_DISJOINT)
> + return 0;
> +
> + if (cxl_region_contains_resource((struct resource *)res)) {
> + dev_dbg(host, "CXL claims resource, dropping: %pr\n", res);
> + return 0;
> + }
> +
> + dev_dbg(host, "CXL did not claim resource, registering: %pr\n", res);
> + return __hmem_register_device(host, target_nid, res);
> +}
> +
> +static void process_defer_work(struct work_struct *w)
> +{
> + struct dax_defer_work *work = container_of(w, typeof(*work), work);
> + struct platform_device *pdev;
> +
> + if (!work->pdev)
> + return;
> +
> + pdev = work->pdev;
> +
> + /* Relies on cxl_acpi and cxl_pci having had a chance to load */
> + wait_for_device_probe();
> +
> + guard(device)(&pdev->dev);
> + if (!pdev->dev.driver)
> + return;
> +
> + if (!dax_hmem_initial_probe) {
> + dax_hmem_initial_probe = true;
> + walk_hmem_resources(&pdev->dev, hmem_register_cxl_device);
> + }
> +}
> +
> static int dax_hmem_platform_probe(struct platform_device *pdev)
> {
> + if (work_pending(&dax_hmem_work.work))
> + return -EBUSY;
> +
> + if (!dax_hmem_work.pdev)
> + dax_hmem_work.pdev =
> + to_platform_device(get_device(&pdev->dev));
> +
> return walk_hmem_resources(&pdev->dev, hmem_register_device);
> }
>
> @@ -168,6 +237,11 @@ static __init int dax_hmem_init(void)
>
> static __exit void dax_hmem_exit(void)
> {
> + if (dax_hmem_work.pdev) {
> + flush_work(&dax_hmem_work.work);
> + put_device(&dax_hmem_work.pdev->dev);
> + }
> +
> platform_driver_unregister(&dax_hmem_driver);
> platform_driver_unregister(&dax_hmem_platform_driver);
> }
^ permalink raw reply
* Re: [PATCH v8 8/9] dax/hmem, cxl: Defer and resolve Soft Reserved ownership
From: Jonathan Cameron @ 2026-03-23 18:13 UTC (permalink / raw)
To: Smita Koralahalli
Cc: linux-cxl, linux-kernel, nvdimm, linux-fsdevel, linux-pm,
Ard Biesheuvel, Alison Schofield, Vishal Verma, Ira Weiny,
Dan Williams, Yazen Ghannam, Dave Jiang, Davidlohr Bueso,
Matthew Wilcox, Jan Kara, Rafael J . Wysocki, Len Brown,
Pavel Machek, Li Ming, Jeff Johnson, Ying Huang, Yao Xingtao,
Peter Zijlstra, Greg Kroah-Hartman, Nathan Fontenot, Terry Bowman,
Robert Richter, Benjamin Cheatham, Zhijian Li, Borislav Petkov,
Tomasz Wolski
In-Reply-To: <20260322195343.206900-9-Smita.KoralahalliChannabasappa@amd.com>
On Sun, 22 Mar 2026 19:53:41 +0000
Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com> wrote:
> The current probe time ownership check for Soft Reserved memory based
> solely on CXL window intersection is insufficient. dax_hmem probing is not
> always guaranteed to run after CXL enumeration and region assembly, which
> can lead to incorrect ownership decisions before the CXL stack has
> finished publishing windows and assembling committed regions.
>
> Introduce deferred ownership handling for Soft Reserved ranges that
> intersect CXL windows. When such a range is encountered during the
> initial dax_hmem probe, schedule deferred work to wait for the CXL stack
> to complete enumeration and region assembly before deciding ownership.
>
> Once the deferred work runs, evaluate each Soft Reserved range
> individually: if a CXL region fully contains the range, skip it and let
> dax_cxl bind. Otherwise, register it with dax_hmem. This per-range
> ownership model avoids the need for CXL region teardown and
> alloc_dax_region() resource exclusion prevents double claiming.
>
> Introduce a boolean flag dax_hmem_initial_probe to live inside device.c
> so it survives module reload. Ensure dax_cxl defers driver registration
> until dax_hmem has completed ownership resolution. dax_cxl calls
> dax_hmem_flush_work() before cxl_driver_register(), which both waits for
> the deferred work to complete and creates a module symbol dependency that
> forces dax_hmem.ko to load before dax_cxl.
>
> Co-developed-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
https://sashiko.dev/#/patchset/20260322195343.206900-1-Smita.KoralahalliChannabasappa%40amd.com
Might be worth a look. I think the last comment is potentially correct
though unlikely a platform_driver_register() actually fails.
I've not looked too closely at the others. Given this was doing something
unusual I thought I'd see what it found. Looks like some interesting
questions if nothing else.
> ---
> drivers/dax/bus.h | 7 ++++
> drivers/dax/cxl.c | 1 +
> drivers/dax/hmem/device.c | 3 ++
> drivers/dax/hmem/hmem.c | 74 +++++++++++++++++++++++++++++++++++++++
> 4 files changed, 85 insertions(+)
>
> diff --git a/drivers/dax/bus.h b/drivers/dax/bus.h
> index cbbf64443098..ebbfe2d6da14 100644
> --- a/drivers/dax/bus.h
> +++ b/drivers/dax/bus.h
> @@ -49,6 +49,13 @@ void dax_driver_unregister(struct dax_device_driver *dax_drv);
> void kill_dev_dax(struct dev_dax *dev_dax);
> bool static_dev_dax(struct dev_dax *dev_dax);
>
> +#if IS_ENABLED(CONFIG_DEV_DAX_HMEM)
> +extern bool dax_hmem_initial_probe;
> +void dax_hmem_flush_work(void);
> +#else
> +static inline void dax_hmem_flush_work(void) { }
> +#endif
> +
> #define MODULE_ALIAS_DAX_DEVICE(type) \
> MODULE_ALIAS("dax:t" __stringify(type) "*")
> #define DAX_DEVICE_MODALIAS_FMT "dax:t%d"
> diff --git a/drivers/dax/cxl.c b/drivers/dax/cxl.c
> index a2136adfa186..3ab39b77843d 100644
> --- a/drivers/dax/cxl.c
> +++ b/drivers/dax/cxl.c
> @@ -44,6 +44,7 @@ static struct cxl_driver cxl_dax_region_driver = {
>
> static void cxl_dax_region_driver_register(struct work_struct *work)
> {
> + dax_hmem_flush_work();
> cxl_driver_register(&cxl_dax_region_driver);
> }
>
> diff --git a/drivers/dax/hmem/device.c b/drivers/dax/hmem/device.c
> index 56e3cbd181b5..991a4bf7d969 100644
> --- a/drivers/dax/hmem/device.c
> +++ b/drivers/dax/hmem/device.c
> @@ -8,6 +8,9 @@
> static bool nohmem;
> module_param_named(disable, nohmem, bool, 0444);
>
> +bool dax_hmem_initial_probe;
> +EXPORT_SYMBOL_GPL(dax_hmem_initial_probe);
> +
> static bool platform_initialized;
> static DEFINE_MUTEX(hmem_resource_lock);
> static struct resource hmem_active = {
> diff --git a/drivers/dax/hmem/hmem.c b/drivers/dax/hmem/hmem.c
> index ca752db03201..9ceda6b5cadf 100644
> --- a/drivers/dax/hmem/hmem.c
> +++ b/drivers/dax/hmem/hmem.c
> @@ -3,6 +3,7 @@
> #include <linux/memregion.h>
> #include <linux/module.h>
> #include <linux/dax.h>
> +#include <cxl/cxl.h>
> #include "../bus.h"
>
> static bool region_idle;
> @@ -58,6 +59,23 @@ static void release_hmem(void *pdev)
> platform_device_unregister(pdev);
> }
>
> +struct dax_defer_work {
> + struct platform_device *pdev;
> + struct work_struct work;
> +};
> +
> +static void process_defer_work(struct work_struct *w);
> +
> +static struct dax_defer_work dax_hmem_work = {
> + .work = __WORK_INITIALIZER(dax_hmem_work.work, process_defer_work),
> +};
> +
> +void dax_hmem_flush_work(void)
> +{
> + flush_work(&dax_hmem_work.work);
> +}
> +EXPORT_SYMBOL_GPL(dax_hmem_flush_work);
> +
> static int __hmem_register_device(struct device *host, int target_nid,
> const struct resource *res)
> {
> @@ -122,6 +140,11 @@ static int hmem_register_device(struct device *host, int target_nid,
> if (IS_ENABLED(CONFIG_DEV_DAX_CXL) &&
> region_intersects(res->start, resource_size(res), IORESOURCE_MEM,
> IORES_DESC_CXL) != REGION_DISJOINT) {
> + if (!dax_hmem_initial_probe) {
> + dev_dbg(host, "await CXL initial probe: %pr\n", res);
> + queue_work(system_long_wq, &dax_hmem_work.work);
> + return 0;
> + }
> dev_dbg(host, "deferring range to CXL: %pr\n", res);
> return 0;
> }
> @@ -129,8 +152,54 @@ static int hmem_register_device(struct device *host, int target_nid,
> return __hmem_register_device(host, target_nid, res);
> }
>
> +static int hmem_register_cxl_device(struct device *host, int target_nid,
> + const struct resource *res)
> +{
> + if (region_intersects(res->start, resource_size(res), IORESOURCE_MEM,
> + IORES_DESC_CXL) == REGION_DISJOINT)
> + return 0;
> +
> + if (cxl_region_contains_resource((struct resource *)res)) {
> + dev_dbg(host, "CXL claims resource, dropping: %pr\n", res);
> + return 0;
> + }
> +
> + dev_dbg(host, "CXL did not claim resource, registering: %pr\n", res);
> + return __hmem_register_device(host, target_nid, res);
> +}
> +
> +static void process_defer_work(struct work_struct *w)
> +{
> + struct dax_defer_work *work = container_of(w, typeof(*work), work);
> + struct platform_device *pdev;
> +
> + if (!work->pdev)
> + return;
> +
> + pdev = work->pdev;
> +
> + /* Relies on cxl_acpi and cxl_pci having had a chance to load */
> + wait_for_device_probe();
> +
> + guard(device)(&pdev->dev);
> + if (!pdev->dev.driver)
> + return;
> +
> + if (!dax_hmem_initial_probe) {
> + dax_hmem_initial_probe = true;
> + walk_hmem_resources(&pdev->dev, hmem_register_cxl_device);
> + }
> +}
> +
> static int dax_hmem_platform_probe(struct platform_device *pdev)
> {
> + if (work_pending(&dax_hmem_work.work))
> + return -EBUSY;
> +
> + if (!dax_hmem_work.pdev)
> + dax_hmem_work.pdev =
> + to_platform_device(get_device(&pdev->dev));
> +
> return walk_hmem_resources(&pdev->dev, hmem_register_device);
> }
>
> @@ -168,6 +237,11 @@ static __init int dax_hmem_init(void)
>
> static __exit void dax_hmem_exit(void)
> {
> + if (dax_hmem_work.pdev) {
> + flush_work(&dax_hmem_work.work);
> + put_device(&dax_hmem_work.pdev->dev);
> + }
> +
> platform_driver_unregister(&dax_hmem_driver);
> platform_driver_unregister(&dax_hmem_platform_driver);
> }
^ permalink raw reply
* Re: [PATCH v11 10/16] KVM: guest_memfd: Add flag to remove from direct map
From: David Hildenbrand (Arm) @ 2026-03-23 18:05 UTC (permalink / raw)
To: Kalyazin, Nikita, kvm@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
bpf@vger.kernel.org, linux-kselftest@vger.kernel.org,
kernel@xen0n.name, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, loongarch@lists.linux.dev,
linux-pm@vger.kernel.org
Cc: pbonzini@redhat.com, corbet@lwn.net, maz@kernel.org,
oupton@kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com,
yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org,
seanjc@google.com, tglx@kernel.org, mingo@redhat.com,
bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
hpa@zytor.com, luto@kernel.org, peterz@infradead.org,
willy@infradead.org, akpm@linux-foundation.org,
lorenzo.stoakes@oracle.com, vbabka@kernel.org, rppt@kernel.org,
surenb@google.com, mhocko@suse.com, ast@kernel.org,
daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev,
eddyz87@gmail.com, song@kernel.org, yonghong.song@linux.dev,
john.fastabend@gmail.com, kpsingh@kernel.org, sdf@fomichev.me,
haoluo@google.com, jolsa@kernel.org, jgg@ziepe.ca,
jhubbard@nvidia.com, peterx@redhat.com, jannh@google.com,
pfalcato@suse.de, skhan@linuxfoundation.org, riel@surriel.com,
ryan.roberts@arm.com, jgross@suse.com, yu-cheng.yu@intel.com,
kas@kernel.org, coxu@redhat.com, kevin.brodsky@arm.com,
ackerleytng@google.com, yosry@kernel.org, ajones@ventanamicro.com,
maobibo@loongson.cn, tabba@google.com, prsampat@amd.com,
wu.fei9@sanechips.com.cn, mlevitsk@redhat.com,
jmattson@google.com, jthoughton@google.com,
agordeev@linux.ibm.com, alex@ghiti.fr, aou@eecs.berkeley.edu,
borntraeger@linux.ibm.com, chenhuacai@kernel.org,
dev.jain@arm.com, gor@linux.ibm.com, hca@linux.ibm.com,
palmer@dabbelt.com, pjw@kernel.org, shijie@os.amperecomputing.com,
svens@linux.ibm.com, thuth@redhat.com, wyihan@google.com,
yang@os.amperecomputing.com, Jonathan.Cameron@huawei.com,
Liam.Howlett@oracle.com, urezki@gmail.com,
zhengqi.arch@bytedance.com, gerald.schaefer@linux.ibm.com,
jiayuan.chen@shopee.com, lenb@kernel.org, osalvador@suse.de,
pavel@kernel.org, rafael@kernel.org, vannapurve@google.com,
jackmanb@google.com, aneesh.kumar@kernel.org,
patrick.roy@linux.dev, Thomson, Jack, Itazuri, Takahiro,
Manwaring, Derek
In-Reply-To: <20260317141031.514-11-kalyazin@amazon.com>
On 3/17/26 15:12, Kalyazin, Nikita wrote:
> From: Patrick Roy <patrick.roy@linux.dev>
>
> Add GUEST_MEMFD_FLAG_NO_DIRECT_MAP flag for KVM_CREATE_GUEST_MEMFD()
> ioctl. When set, guest_memfd folios will be removed from the direct map
> after preparation, with direct map entries only restored when the folios
> are freed.
>
> To ensure these folios do not end up in places where the kernel cannot
> deal with them, set AS_NO_DIRECT_MAP on the guest_memfd's struct
> address_space if GUEST_MEMFD_FLAG_NO_DIRECT_MAP is requested.
>
> Note that this flag causes removal of direct map entries for all
> guest_memfd folios independent of whether they are "shared" or "private"
> (although current guest_memfd only supports either all folios in the
> "shared" state, or all folios in the "private" state if
> GUEST_MEMFD_FLAG_MMAP is not set). The usecase for removing direct map
> entries of also the shared parts of guest_memfd are a special type of
> non-CoCo VM where, host userspace is trusted to have access to all of
> guest memory, but where Spectre-style transient execution attacks
> through the host kernel's direct map should still be mitigated. In this
> setup, KVM retains access to guest memory via userspace mappings of
> guest_memfd, which are reflected back into KVM's memslots via
> userspace_addr. This is needed for things like MMIO emulation on x86_64
> to work.
>
> Direct map entries are zapped right before guest or userspace mappings
> of gmem folios are set up, e.g. in kvm_gmem_fault_user_mapping() or
> kvm_gmem_get_pfn() [called from the KVM MMU code]. The only place where
> a gmem folio can be allocated without being mapped anywhere is
> kvm_gmem_populate(), where handling potential failures of direct map
> removal is not possible (by the time direct map removal is attempted,
> the folio is already marked as prepared, meaning attempting to re-try
> kvm_gmem_populate() would just result in -EEXIST without fixing up the
> direct map state). These folios are then removed form the direct map
> upon kvm_gmem_get_pfn(), e.g. when they are mapped into the guest later.
>
> Signed-off-by: Patrick Roy <patrick.roy@linux.dev>
I you changed this patch significantly, you should likely add a
Co-developed-by: Nikita Kalyazin <kalyazin@amazon.com>
above your sob.
(applies to other patches as well, please double check)
> Signed-off-by: Nikita Kalyazin <kalyazin@amazon.com>
> ---
> Documentation/virt/kvm/api.rst | 21 ++++++-----
> include/linux/kvm_host.h | 3 ++
> include/uapi/linux/kvm.h | 1 +
> virt/kvm/guest_memfd.c | 67 ++++++++++++++++++++++++++++++++--
> 4 files changed, 79 insertions(+), 13 deletions(-)
>
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index 032516783e96..8feec77b03fe 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
> @@ -6439,15 +6439,18 @@ a single guest_memfd file, but the bound ranges must not overlap).
> The capability KVM_CAP_GUEST_MEMFD_FLAGS enumerates the `flags` that can be
> specified via KVM_CREATE_GUEST_MEMFD. Currently defined flags:
>
> - ============================ ================================================
> - GUEST_MEMFD_FLAG_MMAP Enable using mmap() on the guest_memfd file
> - descriptor.
> - GUEST_MEMFD_FLAG_INIT_SHARED Make all memory in the file shared during
> - KVM_CREATE_GUEST_MEMFD (memory files created
> - without INIT_SHARED will be marked private).
> - Shared memory can be faulted into host userspace
> - page tables. Private memory cannot.
> - ============================ ================================================
> + ============================== ================================================
> + GUEST_MEMFD_FLAG_MMAP Enable using mmap() on the guest_memfd file
> + descriptor.
> + GUEST_MEMFD_FLAG_INIT_SHARED Make all memory in the file shared during
> + KVM_CREATE_GUEST_MEMFD (memory files created
> + without INIT_SHARED will be marked private).
> + Shared memory can be faulted into host userspace
> + page tables. Private memory cannot.
> + GUEST_MEMFD_FLAG_NO_DIRECT_MAP The guest_memfd instance will unmap the memory
> + backing it from the kernel's address space
> + before passing it off to userspace or the guest.
> + ============================== ================================================
>
> When the KVM MMU performs a PFN lookup to service a guest fault and the backing
> guest_memfd has the GUEST_MEMFD_FLAG_MMAP set, then the fault will always be
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index ce8c5fdf2752..c95747e2278c 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -738,6 +738,9 @@ static inline u64 kvm_gmem_get_supported_flags(struct kvm *kvm)
> if (!kvm || kvm_arch_supports_gmem_init_shared(kvm))
> flags |= GUEST_MEMFD_FLAG_INIT_SHARED;
>
> + if (!kvm || kvm_arch_gmem_supports_no_direct_map(kvm))
> + flags |= GUEST_MEMFD_FLAG_NO_DIRECT_MAP;
> +
> return flags;
> }
> #endif
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 80364d4dbebb..d864f67efdb7 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -1642,6 +1642,7 @@ struct kvm_memory_attributes {
> #define KVM_CREATE_GUEST_MEMFD _IOWR(KVMIO, 0xd4, struct kvm_create_guest_memfd)
> #define GUEST_MEMFD_FLAG_MMAP (1ULL << 0)
> #define GUEST_MEMFD_FLAG_INIT_SHARED (1ULL << 1)
> +#define GUEST_MEMFD_FLAG_NO_DIRECT_MAP (1ULL << 2)
>
> struct kvm_create_guest_memfd {
> __u64 size;
> diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
> index 651649623448..c9344647579c 100644
> --- a/virt/kvm/guest_memfd.c
> +++ b/virt/kvm/guest_memfd.c
> @@ -7,6 +7,7 @@
> #include <linux/mempolicy.h>
> #include <linux/pseudo_fs.h>
> #include <linux/pagemap.h>
> +#include <linux/set_memory.h>
>
> #include "kvm_mm.h"
>
> @@ -76,6 +77,35 @@ static int __kvm_gmem_prepare_folio(struct kvm *kvm, struct kvm_memory_slot *slo
> return 0;
> }
>
> +#define KVM_GMEM_FOLIO_NO_DIRECT_MAP BIT(0)
> +
> +static bool kvm_gmem_folio_no_direct_map(struct folio *folio)
> +{
> + return ((u64)folio->private) & KVM_GMEM_FOLIO_NO_DIRECT_MAP;
> +}
> +
> +static int kvm_gmem_folio_zap_direct_map(struct folio *folio)
> +{
> + u64 gmem_flags = GMEM_I(folio_inode(folio))->flags;
> + int r = 0;
> +
> + if (kvm_gmem_folio_no_direct_map(folio) || !(gmem_flags & GUEST_MEMFD_FLAG_NO_DIRECT_MAP))
The function is only called when
kvm_gmem_no_direct_map(folio_inode(folio))
Does it really make sense to check for GUEST_MEMFD_FLAG_NO_DIRECT_MAP again?
If, at all, it should be a warning if GUEST_MEMFD_FLAG_NO_DIRECT_MAP is
not set?
Further, kvm_gmem_folio_zap_direct_map() uses the folio lock to
synchronize, right? Might be worth pointing that out somehow (e.g.,
lockdep check if possible).
> + goto out;
> +
> + r = folio_zap_direct_map(folio);
> + if (!r)
> + folio->private = (void *)((u64)folio->private | KVM_GMEM_FOLIO_NO_DIRECT_MAP);
> +
> +out:
> + return r;
> +}
> +
> +static void kvm_gmem_folio_restore_direct_map(struct folio *folio)
> +{
kvm_gmem_folio_zap_direct_map() is allowed to be called on folios that
already have the directmap remove, kvm_gmem_folio_restore_direct_map()
cannot be called if the directmap was already restored.
Should we make that more consistent?
Hoping Sean can find some time to review
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v8 8/9] dax/hmem, cxl: Defer and resolve Soft Reserved ownership
From: Jonathan Cameron @ 2026-03-23 18:03 UTC (permalink / raw)
To: Smita Koralahalli
Cc: linux-cxl, linux-kernel, nvdimm, linux-fsdevel, linux-pm,
Ard Biesheuvel, Alison Schofield, Vishal Verma, Ira Weiny,
Dan Williams, Yazen Ghannam, Dave Jiang, Davidlohr Bueso,
Matthew Wilcox, Jan Kara, Rafael J . Wysocki, Len Brown,
Pavel Machek, Li Ming, Jeff Johnson, Ying Huang, Yao Xingtao,
Peter Zijlstra, Greg Kroah-Hartman, Nathan Fontenot, Terry Bowman,
Robert Richter, Benjamin Cheatham, Zhijian Li, Borislav Petkov,
Tomasz Wolski
In-Reply-To: <20260322195343.206900-9-Smita.KoralahalliChannabasappa@amd.com>
On Sun, 22 Mar 2026 19:53:41 +0000
Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com> wrote:
> The current probe time ownership check for Soft Reserved memory based
> solely on CXL window intersection is insufficient. dax_hmem probing is not
> always guaranteed to run after CXL enumeration and region assembly, which
> can lead to incorrect ownership decisions before the CXL stack has
> finished publishing windows and assembling committed regions.
>
> Introduce deferred ownership handling for Soft Reserved ranges that
> intersect CXL windows. When such a range is encountered during the
> initial dax_hmem probe, schedule deferred work to wait for the CXL stack
> to complete enumeration and region assembly before deciding ownership.
>
> Once the deferred work runs, evaluate each Soft Reserved range
> individually: if a CXL region fully contains the range, skip it and let
> dax_cxl bind. Otherwise, register it with dax_hmem. This per-range
> ownership model avoids the need for CXL region teardown and
> alloc_dax_region() resource exclusion prevents double claiming.
>
> Introduce a boolean flag dax_hmem_initial_probe to live inside device.c
> so it survives module reload. Ensure dax_cxl defers driver registration
> until dax_hmem has completed ownership resolution. dax_cxl calls
> dax_hmem_flush_work() before cxl_driver_register(), which both waits for
> the deferred work to complete and creates a module symbol dependency that
> forces dax_hmem.ko to load before dax_cxl.
>
> Co-developed-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> Signed-off-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
^ permalink raw reply
* Re: [PATCH v11 01/16] set_memory: set_direct_map_* to take address
From: Ackerley Tng @ 2026-03-23 18:00 UTC (permalink / raw)
To: Kalyazin, Nikita, kvm@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
bpf@vger.kernel.org, linux-kselftest@vger.kernel.org,
kernel@xen0n.name, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, loongarch@lists.linux.dev,
linux-pm@vger.kernel.org
Cc: pbonzini@redhat.com, corbet@lwn.net, maz@kernel.org,
oupton@kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com,
yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org,
seanjc@google.com, tglx@kernel.org, mingo@redhat.com,
bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
hpa@zytor.com, luto@kernel.org, peterz@infradead.org,
willy@infradead.org, akpm@linux-foundation.org, david@kernel.org,
lorenzo.stoakes@oracle.com, vbabka@kernel.org, rppt@kernel.org,
surenb@google.com, mhocko@suse.com, ast@kernel.org,
daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev,
eddyz87@gmail.com, song@kernel.org, yonghong.song@linux.dev,
john.fastabend@gmail.com, kpsingh@kernel.org, sdf@fomichev.me,
haoluo@google.com, jolsa@kernel.org, jgg@ziepe.ca,
jhubbard@nvidia.com, peterx@redhat.com, jannh@google.com,
pfalcato@suse.de, skhan@linuxfoundation.org, riel@surriel.com,
ryan.roberts@arm.com, jgross@suse.com, yu-cheng.yu@intel.com,
kas@kernel.org, coxu@redhat.com, kevin.brodsky@arm.com,
yosry@kernel.org, ajones@ventanamicro.com, maobibo@loongson.cn,
tabba@google.com, prsampat@amd.com, wu.fei9@sanechips.com.cn,
mlevitsk@redhat.com, jmattson@google.com, jthoughton@google.com,
agordeev@linux.ibm.com, alex@ghiti.fr, aou@eecs.berkeley.edu,
borntraeger@linux.ibm.com, chenhuacai@kernel.org,
dev.jain@arm.com, gor@linux.ibm.com, hca@linux.ibm.com,
palmer@dabbelt.com, pjw@kernel.org, shijie@os.amperecomputing.com,
svens@linux.ibm.com, thuth@redhat.com, wyihan@google.com,
yang@os.amperecomputing.com, Jonathan.Cameron@huawei.com,
Liam.Howlett@oracle.com, urezki@gmail.com,
zhengqi.arch@bytedance.com, gerald.schaefer@linux.ibm.com,
jiayuan.chen@shopee.com, lenb@kernel.org, osalvador@suse.de,
pavel@kernel.org, rafael@kernel.org, vannapurve@google.com,
jackmanb@google.com, aneesh.kumar@kernel.org,
patrick.roy@linux.dev, Thomson, Jack, Itazuri, Takahiro,
Manwaring, Derek
In-Reply-To: <20260317141031.514-2-kalyazin@amazon.com>
"Kalyazin, Nikita" <kalyazin@amazon.co.uk> writes:
> From: Nikita Kalyazin <kalyazin@amazon.com>
>
> This is to avoid excessive conversions folio->page->address when adding
> helpers on top of set_direct_map_valid_noflush() in the next patch.
>
I can't take credit for what Sashiko [1] spotted.
> Acked-by: David Hildenbrand (Arm) <david@kernel.org>
> Signed-off-by: Nikita Kalyazin <kalyazin@amazon.com>
> ---
> arch/arm64/include/asm/set_memory.h | 7 ++++---
> arch/arm64/mm/pageattr.c | 19 +++++++++----------
> arch/loongarch/include/asm/set_memory.h | 7 ++++---
> arch/loongarch/mm/pageattr.c | 25 +++++++++++--------------
> arch/riscv/include/asm/set_memory.h | 7 ++++---
> arch/riscv/mm/pageattr.c | 17 +++++++++--------
> arch/s390/include/asm/set_memory.h | 7 ++++---
> arch/s390/mm/pageattr.c | 13 +++++++------
> arch/x86/include/asm/set_memory.h | 7 ++++---
> arch/x86/mm/pat/set_memory.c | 23 ++++++++++++-----------
> include/linux/set_memory.h | 9 +++++----
> kernel/power/snapshot.c | 4 ++--
> mm/execmem.c | 6 ++++--
> mm/secretmem.c | 6 +++---
> mm/vmalloc.c | 11 +++++++----
> 15 files changed, 89 insertions(+), 79 deletions(-)
>
>
> [...snip...]
>
> diff --git a/arch/loongarch/mm/pageattr.c b/arch/loongarch/mm/pageattr.c
> index f5e910b68229..9e08905d3624 100644
> --- a/arch/loongarch/mm/pageattr.c
> +++ b/arch/loongarch/mm/pageattr.c
> @@ -198,32 +198,29 @@ bool kernel_page_present(struct page *page)
> return pte_present(ptep_get(pte));
> }
>
> -int set_direct_map_default_noflush(struct page *page)
> +int set_direct_map_default_noflush(const void *addr)
> {
> - unsigned long addr = (unsigned long)page_address(page);
> -
> - if (addr < vm_map_base)
> + if ((unsigned long)addr < vm_map_base)
> return 0;
>
> - return __set_memory(addr, 1, PAGE_KERNEL, __pgprot(0));
> + return __set_memory((unsigned long)addr, 1, PAGE_KERNEL, __pgprot(0));
> }
>
> -int set_direct_map_invalid_noflush(struct page *page)
> +int set_direct_map_invalid_noflush(const void *addr)
> {
> - unsigned long addr = (unsigned long)page_address(page);
> -
> - if (addr < vm_map_base)
> + if ((unsigned long)addr < vm_map_base)
> return 0;
>
> - return __set_memory(addr, 1, __pgprot(0), __pgprot(_PAGE_PRESENT | _PAGE_VALID));
> + return __set_memory((unsigned long)addr, 1, __pgprot(0),
> + __pgprot(_PAGE_PRESENT | _PAGE_VALID));
> }
>
> -int set_direct_map_valid_noflush(struct page *page, unsigned nr, bool valid)
> +int set_direct_map_valid_noflush(const void *addr, unsigned long numpages,
> + bool valid)
> {
> - unsigned long addr = (unsigned long)page_address(page);
> pgprot_t set, clear;
>
> - if (addr < vm_map_base)
> + if ((unsigned long)addr < vm_map_base)
> return 0;
>
> if (valid) {
> @@ -234,5 +231,5 @@ int set_direct_map_valid_noflush(struct page *page, unsigned nr, bool valid)
> clear = __pgprot(_PAGE_PRESENT | _PAGE_VALID);
> }
>
> - return __set_memory(addr, 1, set, clear);
> + return __set_memory((unsigned long)addr, 1, set, clear);
Sashiko also spotted that there is a hard-coded 1 here. Before this
change, it was already hard-coded to 1. Not sure if this is a
bug.
Could this be addressed in a separate patch series?
> }
>
> [...snip...]
>
> diff --git a/arch/x86/mm/pat/set_memory.c b/arch/x86/mm/pat/set_memory.c
> index 40581a720fe8..6aea1f470fd5 100644
> --- a/arch/x86/mm/pat/set_memory.c
> +++ b/arch/x86/mm/pat/set_memory.c
> @@ -2587,9 +2587,9 @@ int set_pages_rw(struct page *page, int numpages)
> return set_memory_rw(addr, numpages);
> }
>
> -static int __set_pages_p(struct page *page, int numpages)
> +static int __set_pages_p(const void *addr, int numpages)
> {
> - unsigned long tempaddr = (unsigned long) page_address(page);
> + unsigned long tempaddr = (unsigned long)addr;
> struct cpa_data cpa = { .vaddr = &tempaddr,
> .pgd = NULL,
> .numpages = numpages,
> @@ -2606,9 +2606,9 @@ static int __set_pages_p(struct page *page, int numpages)
> return __change_page_attr_set_clr(&cpa, 1);
> }
>
> -static int __set_pages_np(struct page *page, int numpages)
> +static int __set_pages_np(const void *addr, int numpages)
> {
> - unsigned long tempaddr = (unsigned long) page_address(page);
> + unsigned long tempaddr = (unsigned long)addr;
> struct cpa_data cpa = { .vaddr = &tempaddr,
> .pgd = NULL,
> .numpages = numpages,
> @@ -2625,22 +2625,23 @@ static int __set_pages_np(struct page *page, int numpages)
> return __change_page_attr_set_clr(&cpa, 1);
> }
>
I agree that in arch/x86/mm/pat/set_memory.c, __kernel_map_pages(), has
calls to __set_pages_p() and __set_pages_np() that seems to have been
missed out in this patch. Those calls still pass struct page *. Maybe
that's because __kernel_map_pages() was guarded by
CONFIG_DEBUG_PAGEALLOC, so if you were using an lsp-guided refactoring
that call was missed.
Should probably try a grep to see what else needs replacing :)
[1] https://sashiko.dev/#/patchset/20260317141031.514-1-kalyazin%40amazon.com
> -int set_direct_map_invalid_noflush(struct page *page)
> +int set_direct_map_invalid_noflush(const void *addr)
> {
> - return __set_pages_np(page, 1);
> + return __set_pages_np(addr, 1);
> }
>
> -int set_direct_map_default_noflush(struct page *page)
> +int set_direct_map_default_noflush(const void *addr)
> {
> - return __set_pages_p(page, 1);
> + return __set_pages_p(addr, 1);
> }
>
> -int set_direct_map_valid_noflush(struct page *page, unsigned nr, bool valid)
> +int set_direct_map_valid_noflush(const void *addr, unsigned long numpages,
> + bool valid)
> {
> if (valid)
> - return __set_pages_p(page, nr);
> + return __set_pages_p(addr, numpages);
>
> - return __set_pages_np(page, nr);
> + return __set_pages_np(addr, numpages);
> }
>
> #ifdef CONFIG_DEBUG_PAGEALLOC
>
> [...snip...]
>
^ permalink raw reply
* Re: [PATCH v8 2/9] dax/hmem: Factor HMEM registration into __hmem_register_device()
From: Jonathan Cameron @ 2026-03-23 17:59 UTC (permalink / raw)
To: Smita Koralahalli
Cc: linux-cxl, linux-kernel, nvdimm, linux-fsdevel, linux-pm,
Ard Biesheuvel, Alison Schofield, Vishal Verma, Ira Weiny,
Dan Williams, Yazen Ghannam, Dave Jiang, Davidlohr Bueso,
Matthew Wilcox, Jan Kara, Rafael J . Wysocki, Len Brown,
Pavel Machek, Li Ming, Jeff Johnson, Ying Huang, Yao Xingtao,
Peter Zijlstra, Greg Kroah-Hartman, Nathan Fontenot, Terry Bowman,
Robert Richter, Benjamin Cheatham, Zhijian Li, Borislav Petkov,
Tomasz Wolski
In-Reply-To: <20260322195343.206900-3-Smita.KoralahalliChannabasappa@amd.com>
On Sun, 22 Mar 2026 19:53:35 +0000
Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com> wrote:
> Separate the CXL overlap check from the HMEM registration path and keep
> the platform-device setup in a dedicated __hmem_register_device().
>
> This makes hmem_register_device() the policy entry point for deciding
> whether a range should be deferred to CXL, while __hmem_register_device()
> handles the HMEM registration flow.
>
> No functional changes.
>
> Signed-off-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
^ permalink raw reply
* Re: [PATCH v8 1/9] dax/bus: Use dax_region_put() in alloc_dax_region() error path
From: Jonathan Cameron @ 2026-03-23 17:57 UTC (permalink / raw)
To: Smita Koralahalli
Cc: linux-cxl, linux-kernel, nvdimm, linux-fsdevel, linux-pm,
Ard Biesheuvel, Alison Schofield, Vishal Verma, Ira Weiny,
Dan Williams, Yazen Ghannam, Dave Jiang, Davidlohr Bueso,
Matthew Wilcox, Jan Kara, Rafael J . Wysocki, Len Brown,
Pavel Machek, Li Ming, Jeff Johnson, Ying Huang, Yao Xingtao,
Peter Zijlstra, Greg Kroah-Hartman, Nathan Fontenot, Terry Bowman,
Robert Richter, Benjamin Cheatham, Zhijian Li, Borislav Petkov,
Tomasz Wolski
In-Reply-To: <20260322195343.206900-2-Smita.KoralahalliChannabasappa@amd.com>
On Sun, 22 Mar 2026 19:53:34 +0000
Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com> wrote:
> alloc_dax_region() calls kref_init() on the dax_region early in the
> function, but the error path for sysfs_create_groups() failure uses
> kfree() directly to free the dax_region. This bypasses the kref lifecycle.
>
> Use dax_region_put() instead to handle kref lifecycle correctly.
>
> Suggested-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> Signed-off-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> ---
> drivers/dax/bus.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dax/bus.c b/drivers/dax/bus.c
> index c94c09622516..299134c9b294 100644
> --- a/drivers/dax/bus.c
> +++ b/drivers/dax/bus.c
> @@ -668,7 +668,7 @@ struct dax_region *alloc_dax_region(struct device *parent, int region_id,
> };
>
> if (sysfs_create_groups(&parent->kobj, dax_region_attribute_groups)) {
> - kfree(dax_region);
> + dax_region_put(dax_region);
> return NULL;
> }
>
^ permalink raw reply
* Re: [PATCH v11 05/16] mm/gup: drop local variable in gup_fast_folio_allowed
From: David Hildenbrand (Arm) @ 2026-03-23 17:55 UTC (permalink / raw)
To: Kalyazin, Nikita, kvm@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
bpf@vger.kernel.org, linux-kselftest@vger.kernel.org,
kernel@xen0n.name, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, loongarch@lists.linux.dev,
linux-pm@vger.kernel.org
Cc: pbonzini@redhat.com, corbet@lwn.net, maz@kernel.org,
oupton@kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com,
yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org,
seanjc@google.com, tglx@kernel.org, mingo@redhat.com,
bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
hpa@zytor.com, luto@kernel.org, peterz@infradead.org,
willy@infradead.org, akpm@linux-foundation.org,
lorenzo.stoakes@oracle.com, vbabka@kernel.org, rppt@kernel.org,
surenb@google.com, mhocko@suse.com, ast@kernel.org,
daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev,
eddyz87@gmail.com, song@kernel.org, yonghong.song@linux.dev,
john.fastabend@gmail.com, kpsingh@kernel.org, sdf@fomichev.me,
haoluo@google.com, jolsa@kernel.org, jgg@ziepe.ca,
jhubbard@nvidia.com, peterx@redhat.com, jannh@google.com,
pfalcato@suse.de, skhan@linuxfoundation.org, riel@surriel.com,
ryan.roberts@arm.com, jgross@suse.com, yu-cheng.yu@intel.com,
kas@kernel.org, coxu@redhat.com, kevin.brodsky@arm.com,
ackerleytng@google.com, yosry@kernel.org, ajones@ventanamicro.com,
maobibo@loongson.cn, tabba@google.com, prsampat@amd.com,
wu.fei9@sanechips.com.cn, mlevitsk@redhat.com,
jmattson@google.com, jthoughton@google.com,
agordeev@linux.ibm.com, alex@ghiti.fr, aou@eecs.berkeley.edu,
borntraeger@linux.ibm.com, chenhuacai@kernel.org,
dev.jain@arm.com, gor@linux.ibm.com, hca@linux.ibm.com,
palmer@dabbelt.com, pjw@kernel.org, shijie@os.amperecomputing.com,
svens@linux.ibm.com, thuth@redhat.com, wyihan@google.com,
yang@os.amperecomputing.com, Jonathan.Cameron@huawei.com,
Liam.Howlett@oracle.com, urezki@gmail.com,
zhengqi.arch@bytedance.com, gerald.schaefer@linux.ibm.com,
jiayuan.chen@shopee.com, lenb@kernel.org, osalvador@suse.de,
pavel@kernel.org, rafael@kernel.org, vannapurve@google.com,
jackmanb@google.com, aneesh.kumar@kernel.org,
patrick.roy@linux.dev, Thomson, Jack, Itazuri, Takahiro,
Manwaring, Derek
In-Reply-To: <20260317141031.514-6-kalyazin@amazon.com>
On 3/17/26 15:11, Kalyazin, Nikita wrote:
> From: Nikita Kalyazin <kalyazin@amazon.com>
>
> Move the check for pinning closer to where the result is used.
> No functional changes.
>
> Signed-off-by: Nikita Kalyazin <kalyazin@amazon.com>
> ---
> mm/gup.c | 23 ++++++++++++-----------
> 1 file changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/mm/gup.c b/mm/gup.c
> index 5856d35be385..869d79c8daa4 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -2737,18 +2737,9 @@ EXPORT_SYMBOL(get_user_pages_unlocked);
> */
> static bool gup_fast_folio_allowed(struct folio *folio, unsigned int flags)
> {
> - bool reject_file_backed = false;
> struct address_space *mapping;
> unsigned long mapping_flags;
>
> - /*
> - * If we aren't pinning then no problematic write can occur. A long term
> - * pin is the most egregious case so this is the one we disallow.
> - */
> - if ((flags & (FOLL_PIN | FOLL_LONGTERM | FOLL_WRITE)) ==
> - (FOLL_PIN | FOLL_LONGTERM | FOLL_WRITE))
> - reject_file_backed = true;
> -
> /* We hold a folio reference, so we can safely access folio fields. */
> if (WARN_ON_ONCE(folio_test_slab(folio)))
> return false;
> @@ -2793,8 +2784,18 @@ static bool gup_fast_folio_allowed(struct folio *folio, unsigned int flags)
> */
> if (secretmem_mapping(mapping))
> return false;
> - /* The only remaining allowed file system is shmem. */
> - return !reject_file_backed || shmem_mapping(mapping);
> +
> + /*
> + * If we aren't pinning then no problematic write can occur. A writable
> + * long term pin is the most egregious case, so this is the one we
> + * allow only for ...
> + */
> + if ((flags & (FOLL_PIN | FOLL_LONGTERM | FOLL_WRITE)) !=
> + (FOLL_PIN | FOLL_LONGTERM | FOLL_WRITE))
> + return true;
> +
> + /* ... hugetlb (which we allowed above already) and shared memory. */
> + return shmem_mapping(mapping);
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
I'm wondering if it would be a good idea to check for a hugetlb mapping
here instead of having the folio_test_hugetlb() check above.
Something to ponder about :)
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v11 03/16] mm/secretmem: make use of folio_{zap,restore}_direct_map
From: David Hildenbrand (Arm) @ 2026-03-23 17:53 UTC (permalink / raw)
To: Kalyazin, Nikita, kvm@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
bpf@vger.kernel.org, linux-kselftest@vger.kernel.org,
kernel@xen0n.name, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, loongarch@lists.linux.dev,
linux-pm@vger.kernel.org
Cc: pbonzini@redhat.com, corbet@lwn.net, maz@kernel.org,
oupton@kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com,
yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org,
seanjc@google.com, tglx@kernel.org, mingo@redhat.com,
bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
hpa@zytor.com, luto@kernel.org, peterz@infradead.org,
willy@infradead.org, akpm@linux-foundation.org,
lorenzo.stoakes@oracle.com, vbabka@kernel.org, rppt@kernel.org,
surenb@google.com, mhocko@suse.com, ast@kernel.org,
daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev,
eddyz87@gmail.com, song@kernel.org, yonghong.song@linux.dev,
john.fastabend@gmail.com, kpsingh@kernel.org, sdf@fomichev.me,
haoluo@google.com, jolsa@kernel.org, jgg@ziepe.ca,
jhubbard@nvidia.com, peterx@redhat.com, jannh@google.com,
pfalcato@suse.de, skhan@linuxfoundation.org, riel@surriel.com,
ryan.roberts@arm.com, jgross@suse.com, yu-cheng.yu@intel.com,
kas@kernel.org, coxu@redhat.com, kevin.brodsky@arm.com,
ackerleytng@google.com, yosry@kernel.org, ajones@ventanamicro.com,
maobibo@loongson.cn, tabba@google.com, prsampat@amd.com,
wu.fei9@sanechips.com.cn, mlevitsk@redhat.com,
jmattson@google.com, jthoughton@google.com,
agordeev@linux.ibm.com, alex@ghiti.fr, aou@eecs.berkeley.edu,
borntraeger@linux.ibm.com, chenhuacai@kernel.org,
dev.jain@arm.com, gor@linux.ibm.com, hca@linux.ibm.com,
palmer@dabbelt.com, pjw@kernel.org, shijie@os.amperecomputing.com,
svens@linux.ibm.com, thuth@redhat.com, wyihan@google.com,
yang@os.amperecomputing.com, Jonathan.Cameron@huawei.com,
Liam.Howlett@oracle.com, urezki@gmail.com,
zhengqi.arch@bytedance.com, gerald.schaefer@linux.ibm.com,
jiayuan.chen@shopee.com, lenb@kernel.org, osalvador@suse.de,
pavel@kernel.org, rafael@kernel.org, vannapurve@google.com,
jackmanb@google.com, aneesh.kumar@kernel.org,
patrick.roy@linux.dev, Thomson, Jack, Itazuri, Takahiro,
Manwaring, Derek
In-Reply-To: <20260317141031.514-4-kalyazin@amazon.com>
On 3/17/26 15:11, Kalyazin, Nikita wrote:
> From: Nikita Kalyazin <kalyazin@amazon.com>
>
Describe your change :)
Ans also worth mentioning that we now flush the TLB even though
filemap_add_folio() failed -- which shouldn't matter in practice I guess.
With that
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH v11 02/16] set_memory: add folio_{zap,restore}_direct_map helpers
From: David Hildenbrand (Arm) @ 2026-03-23 17:51 UTC (permalink / raw)
To: Kalyazin, Nikita, kvm@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev,
linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
bpf@vger.kernel.org, linux-kselftest@vger.kernel.org,
kernel@xen0n.name, linux-riscv@lists.infradead.org,
linux-s390@vger.kernel.org, loongarch@lists.linux.dev,
linux-pm@vger.kernel.org
Cc: pbonzini@redhat.com, corbet@lwn.net, maz@kernel.org,
oupton@kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com,
yuzenghui@huawei.com, catalin.marinas@arm.com, will@kernel.org,
seanjc@google.com, tglx@kernel.org, mingo@redhat.com,
bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org,
hpa@zytor.com, luto@kernel.org, peterz@infradead.org,
willy@infradead.org, akpm@linux-foundation.org,
lorenzo.stoakes@oracle.com, vbabka@kernel.org, rppt@kernel.org,
surenb@google.com, mhocko@suse.com, ast@kernel.org,
daniel@iogearbox.net, andrii@kernel.org, martin.lau@linux.dev,
eddyz87@gmail.com, song@kernel.org, yonghong.song@linux.dev,
john.fastabend@gmail.com, kpsingh@kernel.org, sdf@fomichev.me,
haoluo@google.com, jolsa@kernel.org, jgg@ziepe.ca,
jhubbard@nvidia.com, peterx@redhat.com, jannh@google.com,
pfalcato@suse.de, skhan@linuxfoundation.org, riel@surriel.com,
ryan.roberts@arm.com, jgross@suse.com, yu-cheng.yu@intel.com,
kas@kernel.org, coxu@redhat.com, kevin.brodsky@arm.com,
ackerleytng@google.com, yosry@kernel.org, ajones@ventanamicro.com,
maobibo@loongson.cn, tabba@google.com, prsampat@amd.com,
wu.fei9@sanechips.com.cn, mlevitsk@redhat.com,
jmattson@google.com, jthoughton@google.com,
agordeev@linux.ibm.com, alex@ghiti.fr, aou@eecs.berkeley.edu,
borntraeger@linux.ibm.com, chenhuacai@kernel.org,
dev.jain@arm.com, gor@linux.ibm.com, hca@linux.ibm.com,
palmer@dabbelt.com, pjw@kernel.org, shijie@os.amperecomputing.com,
svens@linux.ibm.com, thuth@redhat.com, wyihan@google.com,
yang@os.amperecomputing.com, Jonathan.Cameron@huawei.com,
Liam.Howlett@oracle.com, urezki@gmail.com,
zhengqi.arch@bytedance.com, gerald.schaefer@linux.ibm.com,
jiayuan.chen@shopee.com, lenb@kernel.org, osalvador@suse.de,
pavel@kernel.org, rafael@kernel.org, vannapurve@google.com,
jackmanb@google.com, aneesh.kumar@kernel.org,
patrick.roy@linux.dev, Thomson, Jack, Itazuri, Takahiro,
Manwaring, Derek
In-Reply-To: <20260317141031.514-3-kalyazin@amazon.com>
On 3/17/26 15:10, Kalyazin, Nikita wrote:
> From: Nikita Kalyazin <kalyazin@amazon.com>
>
> Let's provide folio_{zap,restore}_direct_map helpers as preparation for
> supporting removal of the direct map for guest_memfd folios.
> In folio_zap_direct_map(), flush TLB to make sure the data is not
> accessible.
>
> The new helpers need to be accessible to KVM on architectures that
> support guest_memfd (x86 and arm64).
>
> Direct map removal gives guest_memfd the same protection that
> memfd_secret does, such as hardening against Spectre-like attacks
> through in-kernel gadgets.
Maybe mention that there might be a double TLB flush on some
architectures, but that that is something to figure out later. Same
behavior in secretmem code where this will be used next.
>
> Signed-off-by: Nikita Kalyazin <kalyazin@amazon.com>
> ---
> include/linux/set_memory.h | 13 ++++++++++++
> mm/memory.c | 42 ++++++++++++++++++++++++++++++++++++++
> 2 files changed, 55 insertions(+)
>
> diff --git a/include/linux/set_memory.h b/include/linux/set_memory.h
> index 1a2563f525fc..24caea2931f9 100644
> --- a/include/linux/set_memory.h
> +++ b/include/linux/set_memory.h
> @@ -41,6 +41,15 @@ static inline int set_direct_map_valid_noflush(const void *addr,
> return 0;
> }
>
> +static inline int folio_zap_direct_map(struct folio *folio)
> +{
> + return 0;
Should we return -ENOSYS here or similar?
> +}
> +
> +static inline void folio_restore_direct_map(struct folio *folio)
> +{
> +}
> +
> static inline bool kernel_page_present(struct page *page)
> {
> return true;
> @@ -57,6 +66,10 @@ static inline bool can_set_direct_map(void)
> }
> #define can_set_direct_map can_set_direct_map
> #endif
> +
> +int folio_zap_direct_map(struct folio *folio);
> +void folio_restore_direct_map(struct folio *folio);
> +
> #endif /* CONFIG_ARCH_HAS_SET_DIRECT_MAP */
>
> #ifdef CONFIG_X86_64
> diff --git a/mm/memory.c b/mm/memory.c
> index 07778814b4a8..cab6bb237fc0 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -78,6 +78,7 @@
> #include <linux/sched/sysctl.h>
> #include <linux/pgalloc.h>
> #include <linux/uaccess.h>
> +#include <linux/set_memory.h>
>
> #include <trace/events/kmem.h>
>
> @@ -7478,3 +7479,44 @@ void vma_pgtable_walk_end(struct vm_area_struct *vma)
> if (is_vm_hugetlb_page(vma))
> hugetlb_vma_unlock_read(vma);
> }
> +
> +#ifdef CONFIG_ARCH_HAS_SET_DIRECT_MAP
> +/**
> + * folio_zap_direct_map - remove a folio from the kernel direct map
> + * @folio: folio to remove from the direct map
> + *
> + * Removes the folio from the kernel direct map and flushes the TLB. This may
> + * require splitting huge pages in the direct map, which can fail due to memory
> + * allocation.
Best to mention
"So far, only order-0 folios are supported." and then ...
> + *
> + * Return: 0 on success, or a negative error code on failure.
> + */
> +int folio_zap_direct_map(struct folio *folio)
> +{
> + const void *addr = folio_address(folio);
> + int ret;
> +
if (folio_test_large(folio))
return -EINVAL;
With that,
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
--
Cheers,
David
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox