Re: [PATCH v2 3/7] syscall.h: add syscall_set_arguments() and syscall_set_return_value()
On January 17, 2025 7:45:02 AM PST, Eugene Syromyatnikov wrote: >On Fri, Jan 17, 2025 at 2:03 AM H. Peter Anvin wrote: >> >> I link the concept of this patchset, but *please* make it clear in the >> comments that this does not solve the issue of 64-bit kernel arguments >> on 32-bit systems being ABI specific. > >Sorry, but I don't see how this is relevant; each architecture has its >own ABI with its own set of peculiarities, and there's a lot of >(completely unrelated) work needed in order to make an ABI that is >architecture-agnostic. All this patch set does is provides a >consistent way to manipulate scno and args across architectures; it >doesn't address the fact that some architectures have mmap2/mmap_pgoff >syscall, or that some have fadvise64_64 in addition to fadvise64, or >the existence of clone2, or socketcall, or ipc; or that some >architectures don't have open or stat; or that scnos on different >architectures or even different bit-widths within the "same" >architecture are different. > >> This isn't unique to this patch in any way; the only way to handle it is >> by keeping track of each ABI. > >That's true, but this patch doesn't even try to address that. > I just want it noted in the comment, that's all.
[powerpc:merge] BUILD SUCCESS e5b94ed319deb5534cee1cdefe93f128c7fab863
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge branch HEAD: e5b94ed319deb5534cee1cdefe93f128c7fab863 Automatic merge of 'next' into merge (2025-01-17 10:12) elapsed time: 1449m configs tested: 123 configs skipped: 3 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alpha allnoconfiggcc-14.2.0 alphaallyesconfiggcc-14.2.0 arc allmodconfiggcc-13.2.0 arc allnoconfiggcc-13.2.0 arc allyesconfiggcc-13.2.0 arcnsimosci_defconfiggcc-13.2.0 arc randconfig-001-20250117gcc-13.2.0 arc randconfig-001-20250118gcc-13.2.0 arc randconfig-002-20250117gcc-13.2.0 arc randconfig-002-20250118gcc-13.2.0 arm allmodconfiggcc-14.2.0 arm allnoconfigclang-17 arm allyesconfiggcc-14.2.0 arm lpc32xx_defconfigclang-20 arm moxart_defconfiggcc-14.2.0 arm randconfig-001-20250117clang-18 arm randconfig-001-20250118gcc-14.2.0 arm randconfig-002-20250117gcc-14.2.0 arm randconfig-002-20250118clang-20 arm randconfig-003-20250117gcc-14.2.0 arm randconfig-004-20250117clang-16 arm64allmodconfigclang-18 arm64 allnoconfiggcc-14.2.0 arm64 randconfig-001-20250117gcc-14.2.0 arm64 randconfig-002-20250117clang-18 arm64 randconfig-003-20250117clang-20 arm64 randconfig-004-20250117gcc-14.2.0 csky allnoconfiggcc-14.2.0 csky randconfig-001-20250117gcc-14.2.0 csky randconfig-001-20250118gcc-14.2.0 csky randconfig-002-20250117gcc-14.2.0 csky randconfig-002-20250118gcc-14.2.0 hexagon allmodconfigclang-20 hexagon allnoconfigclang-20 hexagon allyesconfigclang-18 hexagon randconfig-001-20250117clang-20 hexagon randconfig-001-20250118clang-20 hexagon randconfig-002-20250117clang-20 hexagon randconfig-002-20250118clang-20 i386 allmodconfiggcc-12 i386 allnoconfiggcc-12 i386 allyesconfiggcc-12 i386buildonly-randconfig-001-20250117clang-19 i386buildonly-randconfig-001-20250118gcc-12 i386buildonly-randconfig-002-20250117clang-19 i386buildonly-randconfig-002-20250118clang-19 i386buildonly-randconfig-003-20250117gcc-12 i386buildonly-randconfig-003-20250118clang-19 i386buildonly-randconfig-004-20250117gcc-12 i386buildonly-randconfig-004-20250118gcc-11 i386buildonly-randconfig-005-20250117clang-19 i386buildonly-randconfig-005-20250118clang-19 i386buildonly-randconfig-006-20250117gcc-11 i386buildonly-randconfig-006-20250118clang-19 i386defconfigclang-19 loongarch allnoconfiggcc-14.2.0 loongarch randconfig-001-20250117gcc-14.2.0 loongarch randconfig-001-20250118gcc-14.2.0 loongarch randconfig-002-20250117gcc-14.2.0 loongarch randconfig-002-20250118gcc-14.2.0 m68k allmodconfiggcc-14.2.0 m68k allnoconfiggcc-14.2.0 m68k allyesconfiggcc-14.2.0 m68k m5208evb_defconfiggcc-14.2.0 microblazeallnoconfiggcc-14.2.0 mips allnoconfiggcc-14.2.0 nios2 allnoconfiggcc-14.2.0 nios2 randconfig-001-20250117gcc-14.2.0 nios2 randconfig-001-20250118gcc-14.2.0 nios2 randconfig-002-20250117gcc-14.2.0 nios2 randconfig-002-20250118gcc-14.2.0 openrisc allnoconfiggcc-14.2.0 openrisc allyesconfiggcc-14.2.0 openriscdefconfiggcc-14.2.0 pariscallnoconfiggcc-14.2.0 parisc allyesconfiggcc-14.2.0 parisc defconfiggcc-14.2.0 pariscrandconfig-001-20250117gcc-14.
[powerpc:next] BUILD SUCCESS 7fee0217538ab11b9563d39822a0fc5e006ca84b
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next branch HEAD: 7fee0217538ab11b9563d39822a0fc5e006ca84b MAINTAINERS: powerpc: Update my status elapsed time: 1442m configs tested: 138 configs skipped: 3 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alpha allnoconfiggcc-14.2.0 alphaallyesconfiggcc-14.2.0 arc allmodconfiggcc-13.2.0 arc allnoconfiggcc-13.2.0 arc allyesconfiggcc-13.2.0 arc defconfiggcc-13.2.0 arcnsimosci_defconfiggcc-13.2.0 arc randconfig-001-20250117gcc-13.2.0 arc randconfig-002-20250117gcc-13.2.0 arcvdk_hs38_smp_defconfiggcc-13.2.0 arm allmodconfiggcc-14.2.0 arm allnoconfigclang-17 arm allyesconfiggcc-14.2.0 arm lpc32xx_defconfigclang-20 arm moxart_defconfiggcc-14.2.0 arm pxa3xx_defconfigclang-20 arm randconfig-001-20250117clang-18 arm randconfig-002-20250117gcc-14.2.0 arm randconfig-003-20250117gcc-14.2.0 arm randconfig-004-20250117clang-16 arm64 allnoconfiggcc-14.2.0 arm64 randconfig-001-20250117gcc-14.2.0 arm64 randconfig-002-20250117clang-18 arm64 randconfig-003-20250117clang-20 arm64 randconfig-004-20250117gcc-14.2.0 csky alldefconfiggcc-14.2.0 csky allnoconfiggcc-14.2.0 csky randconfig-001-20250117gcc-14.2.0 csky randconfig-001-20250118gcc-14.2.0 csky randconfig-002-20250117gcc-14.2.0 csky randconfig-002-20250118gcc-14.2.0 hexagon allnoconfigclang-20 hexagon randconfig-001-20250117clang-20 hexagon randconfig-001-20250118clang-20 hexagon randconfig-002-20250117clang-20 hexagon randconfig-002-20250118clang-20 i386 allmodconfiggcc-12 i386 allnoconfiggcc-12 i386buildonly-randconfig-001-20250117clang-19 i386buildonly-randconfig-001-20250118gcc-12 i386buildonly-randconfig-002-20250117clang-19 i386buildonly-randconfig-002-20250118clang-19 i386buildonly-randconfig-003-20250117gcc-12 i386buildonly-randconfig-003-20250118clang-19 i386buildonly-randconfig-004-20250117gcc-12 i386buildonly-randconfig-004-20250118gcc-11 i386buildonly-randconfig-005-20250117clang-19 i386buildonly-randconfig-005-20250118clang-19 i386buildonly-randconfig-006-20250117gcc-11 i386buildonly-randconfig-006-20250118clang-19 i386defconfigclang-19 loongarchallmodconfiggcc-14.2.0 loongarch allnoconfiggcc-14.2.0 loongarch randconfig-001-20250117gcc-14.2.0 loongarch randconfig-001-20250118gcc-14.2.0 loongarch randconfig-002-20250117gcc-14.2.0 loongarch randconfig-002-20250118gcc-14.2.0 m68k allmodconfiggcc-14.2.0 m68k allnoconfiggcc-14.2.0 m68k allyesconfiggcc-14.2.0 m68k m5208evb_defconfiggcc-14.2.0 microblazeallnoconfiggcc-14.2.0 mips allnoconfiggcc-14.2.0 nios2 allnoconfiggcc-14.2.0 nios2 randconfig-001-20250117gcc-14.2.0 nios2 randconfig-001-20250118gcc-14.2.0 nios2 randconfig-002-20250117gcc-14.2.0 nios2 randconfig-002-20250118gcc-14.2.0 openrisc allnoconfiggcc-14.2.0 openrisc allyesconfiggcc-14.2.0 openriscdefconfiggcc-14.2.0 parisc allmodconfiggcc-14.2.0 pariscallnoconfiggcc-14.2.0 parisc allyesconfiggcc-14.2.0 parisc defconfiggcc-14.2.0 pariscrandconfig-001-20250117gcc-14.2.0 pariscrandconfig-001-20250118gcc-14.2.0 pariscrandconfig-002-20250117gcc-14.2.0 parisc
Re: [RESEND PATCH] powerpc/kprobes: don't save r13 register in kprobe context
On Sat, Jan 18, 2025 at 15:40:01PM +0800, pangliyuan wrote:
> Le 16/01/2025 à 09:45, pangliyuan a écrit :
>> [Vous ne recevez pas souvent de courriers de pangliyu...@huawei.com.
>> Découvrez pourquoi ceci est important à
>> https://aka.ms/LearnAboutSenderIdentification ]
>>
>> When CONFIG_STACKPROTECTOR_STRONG is enabled and FTRACE is disabled on
>> powerpc64, repeatedly triggering the kprobe process may cause stack check
>> failures and panic.
>>
>> Case:
>> There is a kprobe(do nothing in handler) attached to the "shmem_get_inode",
>> and a process A is creating file on tmpfs.
>>
>> CPU0
>> A |r13 = paca_ptrs[0], paca_ptrs[0]->canary=A->stack_canary
>>|touch a file on tmpfs
>>|shmem_mknod():
>>|load A's canary through r13 and stored it in A's stack
>>|shmem_get_inode():
>>|enter kprobe first
>>|optinsn_slot():
>>|stored r13 (paca_ptrs[0]) in stack
>>
>>..
>>
>>==> schedule, B run on CPU0, A run on CPU1
>>
>> CPU0
>> B |r13 = paca_ptrs[0], paca_ptrs[0]->canary=B->stack_canary
>>|do something...
>> CPU1
>> A |r13 = paca_ptrs[1], paca_ptrs[1]->canary=A->stack_canary
>>|about to leave 'optinsn_slot', restore r13 from A's stack
>>|r13 = paca_ptrs[0], paca_ptrs[0]->canary=B->stack_canary
>>|leave optinsn_slot, back to shmem_get_inode
>>|leave shmem_get_inode, back to shmem_mknod
>>|do canary check in shmem_mknod, but canary stored in A's stack (A's
>> canary) doesn't match the canary loaded through r13 (B's canary),
>> so panic
>>
>> When A(on CPU0) entring optinsn_slot, it stored r13(paca_ptrs[0]) in stack,
>> then A is scheduled to CPU1 and restore r13 from A's stack when leaving
>> 'optinsn_slot'. Now A is running on CPU1 but r13 point to CPU0's
>> paca_ptrs[0], at this time paca_ptrs[0]->__current points to another
>> process B, which cause A use B's canary to do stack check and panic.
>>
>> This can be simply fixed by not saving and restoring the r13 register,
>> because on powerpc64, r13 is a special register that reserved to point
>> to the current process, no need to restore the outdated r13 if scheduled
>> had happened.
>
> Does r13 really points to current process ? I thought it was pointing to
> PACA which is a structure attached to a given CPU not a given process.
You are right, r13 points to the paca structure attached to a given CPU, There
are issues with my description here, I will fix them in my next patch.
>
>By the way, don't we have the same problem on powerpc32 with register r2 ?
On ppc32, r2 really points to current process. Assume there is a process PA,
no matter which CPU the PA is running on, r2 on that CPU will point to PA,
therefore, saving and restoring r2 still make r2 point to the same PA.
On ppc64, each cpu has it's own paca structure pointed by r13. If you save
the r13 while runing on cpu A, and then switch to cpu B and restore the r13,
it will cause r13 on cpu B point to the paca attached to cpu A. So if you
get current process on cpu B, you will actually get the process running on
cpu A.
>>
>> Fixes: 51c9c0843993 ("powerpc/kprobes: Implement Optprobes")
>> Signed-off-by: pangliyuan
>> ---
>> arch/powerpc/kernel/optprobes_head.S | 12 ++--
>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/arch/powerpc/kernel/optprobes_head.S
>> b/arch/powerpc/kernel/optprobes_head.S
>> index 35932f45fb4e..bf0d77e62ba8 100644
>> --- a/arch/powerpc/kernel/optprobes_head.S
>> +++ b/arch/powerpc/kernel/optprobes_head.S
>> @@ -10,12 +10,12 @@
>> #include
>>
>> #ifdef CONFIG_PPC64
>> -#define SAVE_30GPRS(base) SAVE_GPRS(2, 31, base)
>> -#define REST_30GPRS(base) REST_GPRS(2, 31, base)
>> +#define SAVE_NEEDED_GPRS(base) SAVE_GPRS(2, 12, base); SAVE_GPRS(14, 31,
>> base)
>> +#define REST_NEEDED_GPRS(base) REST_GPRS(2, 12, base); REST_GPRS(14, 31,
>> base)
>
> This macro name seems a bit sketchy, as far as I understand r0 and r1
> also need to be saved/restored allthough they are not handled by this macro.
Yes, the name of this macro is indeed not very accurate. Do you have any better
suggestions? How about using SAVE_29GRPS/REST_29GRPS for ppc64 while keeping
SAVE_30GRPS/REST_30GRPS for ppc32?
Re: [PATCH 1/2] arch/powerpc/perf: Check the instruction type before creating sample with perf_mem_data_src
Hi Athira,
kernel test robot noticed the following build errors:
[auto build test ERROR on powerpc/next]
[also build test ERROR on powerpc/fixes linus/master v6.13-rc7 next-20250117]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Athira-Rajeev/arch-powerpc-perf-Update-get_mem_data_src-function-to-use-saved-values-of-sier-and-mmcra-regs/20250113-143059
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
patch link:
https://lore.kernel.org/r/20250113062818.33187-1-atrajeev%40linux.vnet.ibm.com
patch subject: [PATCH 1/2] arch/powerpc/perf: Check the instruction type before
creating sample with perf_mem_data_src
config: powerpc-gamecube_defconfig
(https://download.01.org/0day-ci/archive/20250118/202501180825.lprg6wye-...@intel.com/config)
compiler: clang version 16.0.6 (https://github.com/llvm/llvm-project
7cbf1a2591520c2491aa35339f227775f4d3adf6)
reproduce (this is a W=1 build):
(https://download.01.org/0day-ci/archive/20250118/202501180825.lprg6wye-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202501180825.lprg6wye-...@intel.com/
All errors (new ones prefixed by >>):
>> arch/powerpc/perf/core-book3s.c:2303:22: error: use of undeclared identifier
>> 'ISA207_SIER_TYPE_MASK'
val = (regs->dar & ISA207_SIER_TYPE_MASK) >>
ISA207_SIER_TYPE_SHIFT;
^
>> arch/powerpc/perf/core-book3s.c:2303:48: error: use of undeclared identifier
>> 'ISA207_SIER_TYPE_SHIFT'
val = (regs->dar & ISA207_SIER_TYPE_MASK) >>
ISA207_SIER_TYPE_SHIFT;
^
2 errors generated.
vim +/ISA207_SIER_TYPE_MASK +2303 arch/powerpc/perf/core-book3s.c
2223 #define PERF_SAMPLE_ADDR_TYPE (PERF_SAMPLE_ADDR | \
2224 PERF_SAMPLE_PHYS_ADDR | \
2225 PERF_SAMPLE_DATA_PAGE_SIZE)
2226 /*
2227 * A counter has overflowed; update its count and record
2228 * things if requested. Note that interrupts are hard-disabled
2229 * here so there is no possibility of being interrupted.
2230 */
2231 static void record_and_restart(struct perf_event *event, unsigned long
val,
2232 struct pt_regs *regs)
2233 {
2234 u64 period = event->hw.sample_period;
2235 s64 prev, delta, left;
2236 int record = 0;
2237
2238 if (event->hw.state & PERF_HES_STOPPED) {
2239 write_pmc(event->hw.idx, 0);
2240 return;
2241 }
2242
2243 /* we don't have to worry about interrupts here */
2244 prev = local64_read(&event->hw.prev_count);
2245 delta = check_and_compute_delta(prev, val);
2246 local64_add(delta, &event->count);
2247
2248 /*
2249 * See if the total period for this event has expired,
2250 * and update for the next period.
2251 */
2252 val = 0;
2253 left = local64_read(&event->hw.period_left) - delta;
2254 if (delta == 0)
2255 left++;
2256 if (period) {
2257 if (left <= 0) {
2258 left += period;
2259 if (left <= 0)
2260 left = period;
2261
2262 /*
2263 * If address is not requested in the sample via
2264 * PERF_SAMPLE_IP, just record that sample
irrespective
2265 * of SIAR valid check.
2266 */
2267 if (event->attr.sample_type & PERF_SAMPLE_IP)
2268 record = siar_valid(regs);
2269 else
2270 record = 1;
2271
2272 event->hw.last_period = event->hw.sample_period;
2273 }
2274 if (left < 0x8000LL)
2275 val = 0x8000LL - left;
2276 }
2277
2278 write_pmc(event->hw.idx, val);
2279 local64_set(&event->hw.prev_count, val);
2280 local64_set(&event->hw.period_left, left);
2281 perf_event_update_userpage(event);
2282
Re: [PATCH v13 5/5] rust: Use gendwarfksyms + extended modversions for CONFIG_MODVERSIONS
On Wed, Jan 15, 2025 at 3:58 AM Sami Tolvanen wrote:
>
> On Tue, Jan 14, 2025 at 10:22:15AM +0900, Masahiro Yamada wrote:
> > On Tue, Jan 14, 2025 at 5:04 AM Sami Tolvanen
> > wrote:
> > >
> > > Hi Masahiro,
> > >
> > > On Fri, Jan 10, 2025 at 6:26 PM Masahiro Yamada
> > > wrote:
> > > >
> > > > On Sat, Jan 4, 2025 at 2:37 AM Matthew Maurer
> > > > wrote:
> > > > >
> > > > > From: Sami Tolvanen
> > > > >
> > > > > Previously, two things stopped Rust from using MODVERSIONS:
> > > > > 1. Rust symbols are occasionally too long to be represented in the
> > > > >original versions table
> > > > > 2. Rust types cannot be properly hashed by the existing genksyms
> > > > >approach because:
> > > > > * Looking up type definitions in Rust is more complex than C
> > > > > * Type layout is potentially dependent on the compiler in
> > > > > Rust,
> > > > > not just the source type declaration.
> > > > >
> > > > > CONFIG_EXTENDED_MODVERSIONS addresses the first point, and
> > > > > CONFIG_GENDWARFKSYMS the second. If Rust wants to use MODVERSIONS,
> > > > > allow
> > > > > it to do so by selecting both features.
> > > > >
> > > > > Signed-off-by: Sami Tolvanen
> > > > > Co-developed-by: Matthew Maurer
> > > > > Signed-off-by: Matthew Maurer
> > > > > ---
> > > > > init/Kconfig | 3 ++-
> > > > > rust/Makefile | 34 --
> > > > > 2 files changed, 34 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/init/Kconfig b/init/Kconfig
> > > > > index
> > > > > c1f9eb3d5f2e892e977ba1425599502dc830f552..b60acfd9431e0ac2bf401ecb6523b5104ad31150
> > > > > 100644
> > > > > --- a/init/Kconfig
> > > > > +++ b/init/Kconfig
> > > > > @@ -1959,7 +1959,8 @@ config RUST
> > > > > bool "Rust support"
> > > > > depends on HAVE_RUST
> > > > > depends on RUST_IS_AVAILABLE
> > > > > - depends on !MODVERSIONS
> > > > > + select EXTENDED_MODVERSIONS if MODVERSIONS
> > > > > + depends on !MODVERSIONS || GENDWARFKSYMS
> > > > > depends on !GCC_PLUGIN_RANDSTRUCT
> > > > > depends on !RANDSTRUCT
> > > > > depends on !DEBUG_INFO_BTF || PAHOLE_HAS_LANG_EXCLUDE
> > > > > diff --git a/rust/Makefile b/rust/Makefile
> > > > > index
> > > > > a40a3936126d603836e0ec9b42a1285916b60e45..80f970ad81f7989afe5ff2b5f633f50feb7f6006
> > > > > 100644
> > > > > --- a/rust/Makefile
> > > > > +++ b/rust/Makefile
> > > > > @@ -329,10 +329,11 @@ $(obj)/bindings/bindings_helpers_generated.rs:
> > > > > private bindgen_target_extra = ;
> > > > > $(obj)/bindings/bindings_helpers_generated.rs:
> > > > > $(src)/helpers/helpers.c FORCE
> > > > > $(call if_changed_dep,bindgen)
> > > > >
> > > > > +rust_exports = $(NM) -p --defined-only $(1) | awk '$$2~/(T|R|D|B)/
> > > > > && $$3!~/__cfi/ { printf $(2),$(3) }'
> > > > > +
> > > > > quiet_cmd_exports = EXPORTS $@
> > > > >cmd_exports = \
> > > > > - $(NM) -p --defined-only $< \
> > > > > - | awk '$$2~/(T|R|D|B)/ && $$3!~/__cfi/ {printf
> > > > > "EXPORT_SYMBOL_RUST_GPL(%s);\n",$$3}' > $@
> > > > > + $(call rust_exports,$<,"EXPORT_SYMBOL_RUST_GPL(%s);\n",$$3) >
> > > > > $@
> > > >
> > > > I noticed a nit:
> > > >
> > > > Both of the two callsites of rust_exports pass
> > > > '$$3' to the last parameter instead of hardcoding it.
> > > >
> > > > Is it a flexibility for future extensions?
> > > >
> > > > I cannot think of any other use except for printing
> > > > the third column, i.e. symbol name.
> > >
> > > Good catch, the last parameter isn't necessary anymore. It was used in
> > > early versions of the series to also pass symbol addresses to
> > > gendwarfksyms, but that's not needed since we read the symbol table
> > > directly now.
> >
> > If you submit a diff, I will squash it to 5/5.
> > (You do not need to input commit description body)
>
> Thanks, here's a diff that drops the last parameter.
Squashed.
Thanks!
--
Best Regards
Masahiro Yamada
Re: [PATCH] powerpc/prom_init: Fixup missing #size-cells on PowerBook6,7
On Mon, Jan 13, 2025 at 11:19 AM Andreas Schwab wrote:
>
> Similar to the PowerMac3,1, the PowerBook6,7 is missing the #size-cells
> property on the i2s node.
>
> Depends-on: 045b14ca5c36 ("of: WARN on deprecated #address-cells/#size-cells
> handling")
> Signed-off-by: Andreas Schwab
> ---
> arch/powerpc/kernel/prom_init.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Acked-by: Rob Herring (Arm)
Re: [PATCH v2 3/7] syscall.h: add syscall_set_arguments() and syscall_set_return_value()
On Fri, Jan 17, 2025 at 2:03 AM H. Peter Anvin wrote:
>
> I link the concept of this patchset, but *please* make it clear in the
> comments that this does not solve the issue of 64-bit kernel arguments
> on 32-bit systems being ABI specific.
Sorry, but I don't see how this is relevant; each architecture has its
own ABI with its own set of peculiarities, and there's a lot of
(completely unrelated) work needed in order to make an ABI that is
architecture-agnostic. All this patch set does is provides a
consistent way to manipulate scno and args across architectures; it
doesn't address the fact that some architectures have mmap2/mmap_pgoff
syscall, or that some have fadvise64_64 in addition to fadvise64, or
the existence of clone2, or socketcall, or ipc; or that some
architectures don't have open or stat; or that scnos on different
architectures or even different bit-widths within the "same"
architecture are different.
> This isn't unique to this patch in any way; the only way to handle it is
> by keeping track of each ABI.
That's true, but this patch doesn't even try to address that.
--
Eugene Syromyatnikov
mailto:evg...@gmail.com
xmpp:esyr@jabber.{ru|org}
Re: [PATCH v3 1/2] powerpc/fadump: allocate memory for additional parameters early
Le 13/11/2024 à 08:06, Sourabh Jain a écrit :
From: Hari Bathini
Memory for passing additional parameters to fadump capture kernel
is allocated during subsys_initcall level, using memblock. But
as slab is already available by this time, allocation happens via
the buddy allocator. This may work for radix MMU but is likely to
fail in most cases for hash MMU as hash MMU needs this memory in
the first memory block for it to be accessible in real mode in the
capture kernel (second boot). So, allocate memory for additional
parameters area as soon as MMU mode is obvious.
Fixes: 683eab94da75 ("powerpc/fadump: setup additional parameters for dump capture
kernel")
Reported-by: Venkat Rao Bagalkote
Closes:
https://lore.kernel.org/lkml/a70e4064-a040-447b-8556-1fd02f193...@linux.vnet.ibm.com/T/#u
Cc: Mahesh Salgaonkar
Cc: Michael Ellerman
Reviewed-by: Ritesh Harjani (IBM)
Signed-off-by: Hari Bathini
Signed-off-by: Sourabh Jain
Version v2 of this series was applied.
If needed, can you rebase this patch ?
Re: [PATCH v3 1/2] powerpc/fadump: allocate memory for additional parameters early
Hello Christophe,
On 17/01/25 17:43, Christophe Leroy wrote:
Le 13/11/2024 à 08:06, Sourabh Jain a écrit :
From: Hari Bathini
Memory for passing additional parameters to fadump capture kernel
is allocated during subsys_initcall level, using memblock. But
as slab is already available by this time, allocation happens via
the buddy allocator. This may work for radix MMU but is likely to
fail in most cases for hash MMU as hash MMU needs this memory in
the first memory block for it to be accessible in real mode in the
capture kernel (second boot). So, allocate memory for additional
parameters area as soon as MMU mode is obvious.
Fixes: 683eab94da75 ("powerpc/fadump: setup additional parameters for
dump capture kernel")
Reported-by: Venkat Rao Bagalkote
Closes:
https://lore.kernel.org/lkml/a70e4064-a040-447b-8556-1fd02f193...@linux.vnet.ibm.com/T/#u
Cc: Mahesh Salgaonkar
Cc: Michael Ellerman
Reviewed-by: Ritesh Harjani (IBM)
Signed-off-by: Hari Bathini
Signed-off-by: Sourabh Jain
Version v2 of this series was applied.
If needed, can you rebase this patch ?
Sorry, I didn't get that. Rebase on top of which tree/branch?
FYI, there was no functional change from v2 to v3. Only a
"Reviewed-by" tag was added.
Thanks,
Sourabh Jain
Re: [PATCH] of: address: Unify resource bounds overflow checking
On Fri, Jan 17, 2025 at 12:23:53PM +0530, Basharath Hussain Khaja wrote:
> >> >> Thomas Weißschuh writes:
> >> >> > The members "start" and "end" of struct resource are of type
> >> >> > "resource_size_t" which can be 32bit wide.
> >> >> > Values read from OF however are always 64bit wide.
> >> >> >
> >> >> > Refactor the diff overflow checks into a helper function.
> >> >> > Also extend the checks to validate each calculation step.
> >> >> >
> >> >> > Signed-off-by: Thomas Weißschuh
> >> >> > ---
> >> >> > drivers/of/address.c | 45
> >> >> > ++---
> >> >> > 1 file changed, 26 insertions(+), 19 deletions(-)
> >> >> >
> >> >> > diff --git a/drivers/of/address.c b/drivers/of/address.c
> >> >> > index 7e59283a4472..df854bb427ce 100644
> >> >> > --- a/drivers/of/address.c
> >> >> > +++ b/drivers/of/address.c
> >> >> > @@ -198,6 +198,25 @@ static u64 of_bus_pci_map(__be32 *addr, const
> >> >> > __be32
> >> >> > *range, int na, int ns,
> >> >> >
> >> >> > #endif /* CONFIG_PCI */
> >> >> >
> >> >> > +static int __of_address_resource_bounds(struct resource *r, u64
> >> >> > start, u64
> >> >> > size)
> >> >> > +{
> >> >> > + u64 end = start;
> >> >> > +
> >> >> > + if (overflows_type(start, r->start))
> >> >> > + return -EOVERFLOW;
> >> >> > + if (size == 0)
> >> >> > + return -EOVERFLOW;
> >> >> > + if (check_add_overflow(end, size - 1, &end))
> >> >> > + return -EOVERFLOW;
> >> >> > + if (overflows_type(end, r->end))
> >> >> > + return -EOVERFLOW;
> >> >>
> >> >> This breaks PCI on powerpc qemu. Part of the PCI probe reads a resource
> >> >> that's zero sized, which used to succeed but now fails due to the size
> >> >> check above.
> >> >>
> >> >> The diff below fixes it for me.
> >> >
> >> > I fixed it up with your change.
> >>
> >>
> >> This commit is breaking Ethernet functionality on the TI AM57xx platform
> >> due to
> >> zero byte SRAM block size allocation during initialization. Prior to this
> >> patch, zero byte block sizes were handled properly.
> >
> > What driver and where exactly?
>
> We found an issue while developing the driver [1] and more
> specifically in [2] (lines 313-327), but it looks like this is a
> generic issue which can block 1 byte of memory, when a zero size
> request has been initiated for the reserved region.
>
> static int __of_address_resource_bounds(struct resource *r, u64 start, u64
> size)
> {
> u64 end = start;
>
> if (overflows_type(start, r->start))
> return -EOVERFLOW;
> if (size && check_add_overflow(end, size - 1, &end))
> return -EOVERFLOW;
> if (overflows_type(end, r->end))
> return -EOVERFLOW;
>
> r->start = start;
> r->end = end;
>
> return 0;
> }
>
> Though we have the start address handling already in place above, we
> do see an issue with the end address, because there is an
> unconditional +1 afterwards in resource_size() API below which is
> responsible for reserving the extra byte
>
> static inline resource_size_t resource_size(const struct resource *res)
> {
> return res->end - res->start + 1;
> }
Now the report makes more sense.
> We have 4 ways of fixing it.
>
> Option 1: Modify the function to handle the size zero case
>
> diff --git a/drivers/of/address.c b/drivers/of/address.c
> index c1f1c810e810..8db6ae9a12b8 100644
> --- a/drivers/of/address.c
> +++ b/drivers/of/address.c
> @@ -204,6 +204,12 @@ static int __of_address_resource_bounds(struct resource
> *r, u64 start, u64 size)
>
> if (overflows_type(start, r->start))
> return -EOVERFLOW;
> + if (!size) {
> + r->start = start;
> + r->end = end - 1;
> +
> + return 0;
> + }
> if (size && check_add_overflow(end, size - 1, &end))
> return -EOVERFLOW;
> if (overflows_type(end, r->end))
>
> This seems to be the simplest solution.
Fixing it in __of_address_resource_bounds() looks correct to me.
The proposed solution doesn't look as clean as I'd like though,
this is highly subjective, though.
What about the following (untested)?
static int __of_address_resource_bounds(struct resource *r, u64 start, u64 size)
{
if (overflows_type(start, r->start))
return -EOVERFLOW;
r->start = start;
r->end = start;
if (!size)
r->end -= 1; /* May underflow for empty resources. */
else if (check_add_overflow(r->end, size - 1, &r->end))
return -EOVERFLOW;
return 0;
}
A kunit test looks to be in order in any case, to make sure all the
edgecases are handled.
> Option 2: Handle in resource_size().
> static inline resource_size_t resource_size(const struct resource *res)
> {
> return (res->end == res->start) ? 0 : (res->end - res->start + 1);
> }
> There are plenty of places where we are using this API and there is an
Re: [PATCH] selftests: livepatch: handle PRINTK_CALLER in check_result()
Hi,
On Thu, 16 Jan 2025, Petr Mladek wrote:
> On Thu 2025-01-16 08:10:44, Joe Lawrence wrote:
> > On 1/16/25 04:29, Petr Mladek wrote:
> > > On Tue 2025-01-14 20:01:44, Madhavan Srinivasan wrote:
> > >> Some arch configs (like ppc64) enable CONFIG_PRINTK_CALLER, which
> > >> adds the caller id as part of the dmesg. Due to this, even though
> > >> the expected vs observed are same, end testcase results are failed.
> > >
> > > CONFIG_PRINTK_CALLER is not the only culprit. We (SUSE) have it enabled
> > > as well and the selftests pass without this patch.
> > >
> > > The difference might be in dmesg. It shows the caller only when
> > > the messages are read via the syslog syscall (-S) option. It should
> > > not show the caller when the messages are read via /dev/kmsg
> > > which should be the default.
> > >
> > > I wonder if you define an alias to dmesg which adds the "-S" option
> > > or if /dev/kmsg is not usable from some reason.
> > >
> >
> > Hi Petr,
> >
> > To see the thread markers on a RHEL-9.6 machine, I built and installed
> > the latest dmesg from:
> >
> > https://github.com/util-linux/util-linux
> >
> > and ran Madhavan's tests. I don't think there was any alias involved:
> >
> > $ alias | grep dmesg
> > (nothing)
> >
> > $ ~/util-linux/dmesg | tail -n1
> > [ 4361.322790] [ T98877] % rmmod test_klp_livepatch
>
> Good to know. I havn't seen this yet.
>
> > >From util-linux's 467a5b3192f1 ("dmesg: add caller_id support"):
> >
> > The dmesg -S using the old syslog interface supports printing the
> > PRINTK_CALLER field but currently standard dmesg does not support
> > printing the field if present. There are utilities that use dmesg and
> > so it would be optimal if dmesg supported PRINTK_CALLER as well.
> >
> > does that imply that printing the thread IDs is now a (util-linux's)
> > dmesg default?
>
> It looks like. The caller ID information is available also via
> /dev/kmsg but the older dmesg version did not show it. I guess that
> they just added support to parse and show it. It actually makes
> sense to show the same output independently on whether the messages
> are read via syslog or /dev/kmsg.
>
> So, we need this patch, definitely ;-)
Yes.
Madhavan, could you add the above findings to the commit log when you
submit a new version, please?
Thank you,
Miroslav
Re: [PATCH v5 05/17] arm64: pgtable: use mmu gather to free p4d level page table
On Tue, Jan 14, 2025 at 10:26:54AM +0800, Qi Zheng wrote:
> Hi Will,
>
> On 2025/1/14 00:26, Will Deacon wrote:
> > On Wed, Jan 08, 2025 at 02:57:21PM +0800, Qi Zheng wrote:
> > > Like other levels of page tables, also use mmu gather mechanism to free
> > > p4d level page table.
> > >
> > > Signed-off-by: Qi Zheng
> > > Originally-by: Peter Zijlstra (Intel)
> > > Reviewed-by: Kevin Brodsky
> > > Cc: linux-arm-ker...@lists.infradead.org
> > > ---
> > > arch/arm64/include/asm/pgalloc.h | 1 -
> > > arch/arm64/include/asm/tlb.h | 14 ++
> > > 2 files changed, 14 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm64/include/asm/pgalloc.h
> > > b/arch/arm64/include/asm/pgalloc.h
> > > index 2965f5a7e39e3..1b4509d3382c6 100644
> > > --- a/arch/arm64/include/asm/pgalloc.h
> > > +++ b/arch/arm64/include/asm/pgalloc.h
> > > @@ -85,7 +85,6 @@ static inline void pgd_populate(struct mm_struct *mm,
> > > pgd_t *pgdp, p4d_t *p4dp)
> > > __pgd_populate(pgdp, __pa(p4dp), pgdval);
> > > }
> > > -#define __p4d_free_tlb(tlb, p4d, addr) p4d_free((tlb)->mm, p4d)
> > > #else
> > > static inline void __pgd_populate(pgd_t *pgdp, phys_addr_t p4dp,
> > > pgdval_t prot)
> > > {
> > > diff --git a/arch/arm64/include/asm/tlb.h b/arch/arm64/include/asm/tlb.h
> > > index a947c6e784ed2..445282cde9afb 100644
> > > --- a/arch/arm64/include/asm/tlb.h
> > > +++ b/arch/arm64/include/asm/tlb.h
> > > @@ -111,4 +111,18 @@ static inline void __pud_free_tlb(struct mmu_gather
> > > *tlb, pud_t *pudp,
> > > }
> > > #endif
> > > +#if CONFIG_PGTABLE_LEVELS > 4
> > > +static inline void __p4d_free_tlb(struct mmu_gather *tlb, p4d_t *p4dp,
> > > + unsigned long addr)
> > > +{
> > > + struct ptdesc *ptdesc = virt_to_ptdesc(p4dp);
> > > +
> > > + if (!pgtable_l5_enabled())
> > > + return;
> > > +
> > > + pagetable_p4d_dtor(ptdesc);
> > > + tlb_remove_ptdesc(tlb, ptdesc);
> > > +}
> >
> > Should we update p4d_free() to call the destructor, too? It looks like
> > it just does free_page() atm.
>
> The patch #3 introduces the generic p4d_free() and lets arm64 to use it.
> The patch #4 adds the destructor to generic p4d_free(). So IIUC, there
> is no problem here.
Sorry, I missed that. In which case:
Acked-by: Will Deacon
Will
Re: [PATCH v3 1/2] powerpc/fadump: allocate memory for additional parameters early
Le 17/01/2025 à 13:32, Sourabh Jain a écrit :
Hello Christophe,
On 17/01/25 17:43, Christophe Leroy wrote:
Le 13/11/2024 à 08:06, Sourabh Jain a écrit :
From: Hari Bathini
Memory for passing additional parameters to fadump capture kernel
is allocated during subsys_initcall level, using memblock. But
as slab is already available by this time, allocation happens via
the buddy allocator. This may work for radix MMU but is likely to
fail in most cases for hash MMU as hash MMU needs this memory in
the first memory block for it to be accessible in real mode in the
capture kernel (second boot). So, allocate memory for additional
parameters area as soon as MMU mode is obvious.
Fixes: 683eab94da75 ("powerpc/fadump: setup additional parameters for
dump capture kernel")
Reported-by: Venkat Rao Bagalkote
Closes: https://eur01.safelinks.protection.outlook.com/?
url=https%3A%2F%2Flore.kernel.org%2Flkml%2Fa70e4064-
a040-447b-8556-1fd02f19383d%40linux.vnet.ibm.com%2FT%2F%23u&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C9df078759a2c42b044cf08dd36f3183b%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C638727139896068824%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=iZfkQKw4wJAvwAj%2BbGOS5kcrVtAg8xg%2FFl6ojEYZ6ls%3D&reserved=0
Cc: Mahesh Salgaonkar
Cc: Michael Ellerman
Reviewed-by: Ritesh Harjani (IBM)
Signed-off-by: Hari Bathini
Signed-off-by: Sourabh Jain
Version v2 of this series was applied.
If needed, can you rebase this patch ?
Sorry, I didn't get that. Rebase on top of which tree/branch?
I meant on top of any tree including the applied version.
FYI, there was no functional change from v2 to v3. Only a
"Reviewed-by" tag was added.
Then I guess there is nothing to do.
Christophe
Re: [PATCH v2 1/6] powerpc: Document APIv2 KVM hcall spec for Hostwide counters
On Wed, Jan 15, 2025 at 08:09:42PM +0530, Vaibhav Jain wrote: > Update kvm-nested APIv2 documentation to include five new > Guest-State-Elements to fetch the hostwide counters. These counters are > per L1-Lpar and indicate the amount of Heap/Page-table memory allocated, > available and Page-table memory reclaimed for all L2-Guests active > instances > > Cc: linux-...@vger.kernel.org > Cc: linuxppc-dev@lists.ozlabs.org > Cc: Madhavan Srinivasan > Cc: Nicholas Piggin > Signed-off-by: Vaibhav Jain > > --- > Changelog > > v1->v2: > * Reworded section on GSID [Gautam] > --- > Documentation/arch/powerpc/kvm-nested.rst | 40 +-- > 1 file changed, 30 insertions(+), 10 deletions(-) > > diff --git a/Documentation/arch/powerpc/kvm-nested.rst > b/Documentation/arch/powerpc/kvm-nested.rst > index 5defd13cc6c1..8e468a4db0dc 100644 > --- a/Documentation/arch/powerpc/kvm-nested.rst > +++ b/Documentation/arch/powerpc/kvm-nested.rst > @@ -208,13 +208,9 @@ associated values for each ID in the GSB:: >flags: > Bit 0: getGuestWideState: Request state of the Guest instead > of an individual VCPU. > - Bit 1: takeOwnershipOfVcpuState Indicate the L1 is taking > - over ownership of the VCPU state and that the L0 can free > - the storage holding the state. The VCPU state will need to > - be returned to the Hypervisor via H_GUEST_SET_STATE prior > - to H_GUEST_RUN_VCPU being called for this VCPU. The data > - returned in the dataBuffer is in a Hypervisor internal > - format. > + Bit 1: getHostWideState: Request stats of the Host. This causes > + the guestId and vcpuId parameters to be ignored and attempting > + to get the VCPU/Guest state will cause an error. > Bits 2-63: Reserved >guestId: ID obtained from H_GUEST_CREATE >vcpuId: ID of the vCPU pass to H_GUEST_CREATE_VCPU > @@ -406,9 +402,10 @@ the partition like the timebase offset and partition > scoped page > table information. > > ++---+++--+ > -| ID | Size | RW | Thread | Details | > -|| Bytes || Guest | | > -|| || Scope | | > +| ID | Size | RW |(H)ost | Details | > +|| Bytes ||(G)uest | | > +|| ||(T)hread| | > +|| ||Scope | | > ++===+++==+ > | 0x | | RW | TG | NOP element | > ++---+++--+ > @@ -434,6 +431,29 @@ table information. > || |||- 0x8 Table size. | > ++---+++--+ > | 0x0007-| ||| Reserved | > +| 0x07FF | ||| | > +++---+++--+ > +| 0x0800 | 0x08 | R | H| Current usage in bytes of the| > +|| ||| L0's Guest Management Space | > +|| ||| for an L1-Lpar. | > +++---+++--+ > +| 0x0801 | 0x08 | R | H| Max bytes available in the | > +|| ||| L0's Guest Management Space for | > +|| ||| an L1-Lpar | > +++---+++--+ > +| 0x0802 | 0x08 | R | H| Current usage in bytes of the| > +|| ||| L0's Guest Page Table Management | > +|| ||| Space for an L1-Lpar | > +++---+++--+ > +| 0x0803 | 0x08 | R | H| Max bytes available in the L0's | > +|| ||| Guest Page Table Management | > +|| ||| Space for an L1-Lpar | > +++---+++--+ > +| 0x0804 | 0x08 | R | H| Amount of reclaimed L0 Guest's | > +|| ||| Page Table Management Space due | > +|| ||| to overcommit for an L1-Lpar | Nit s/Amount of reclaimed/Space in bytes reclaimed in > +++---+++--+ > +| 0x0805-| ||| Reserved | > | 0x0BFF | ||| | > ++---+++--+ > | 0x0C00 | 0x10 | RW | T|Run vCPU Input Buffer:
Re: [PATCH v2 4/6] kvm powerpc/book3s-apiv2: Introduce kvm-hv specific PMU
Thanks for catching this build warning kernel-test-robot. I will
spin-off a v3 fixing this.
kernel test robot writes:
> Hi Vaibhav,
>
> kernel test robot noticed the following build warnings:
>
> [auto build test WARNING on powerpc/topic/ppc-kvm]
> [also build test WARNING on powerpc/next powerpc/fixes kvm/queue kvm/next
> mst-vhost/linux-next linus/master v6.13-rc7 next-20250116]
> [cannot apply to kvm/linux-next]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch#_base_tree_information]
>
> url:
> https://github.com/intel-lab-lkp/linux/commits/Vaibhav-Jain/powerpc-Document-APIv2-KVM-hcall-spec-for-Hostwide-counters/20250116-024240
> base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git
> topic/ppc-kvm
> patch link:
> https://lore.kernel.org/r/20250115143948.369379-5-vaibhav%40linux.ibm.com
> patch subject: [PATCH v2 4/6] kvm powerpc/book3s-apiv2: Introduce kvm-hv
> specific PMU
> config: powerpc-allnoconfig
> (https://download.01.org/0day-ci/archive/20250117/202501171030.3x0gqw8g-...@intel.com/config)
> compiler: powerpc-linux-gcc (GCC) 14.2.0
> reproduce (this is a W=1 build):
> (https://download.01.org/0day-ci/archive/20250117/202501171030.3x0gqw8g-...@intel.com/reproduce)
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version
> of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot
> | Closes:
> https://lore.kernel.org/oe-kbuild-all/202501171030.3x0gqw8g-...@intel.com/
>
> All warnings (new ones prefixed by >>):
>
>In file included from arch/powerpc/include/asm/kvm_ppc.h:22,
> from arch/powerpc/include/asm/dbell.h:17,
> from arch/powerpc/kernel/asm-offsets.c:36:
>>> arch/powerpc/include/asm/kvm_book3s.h:357:13: warning:
>>> 'kvmppc_unregister_pmu' defined but not used [-Wunused-function]
> 357 | static void kvmppc_unregister_pmu(void)
> | ^
>>> arch/powerpc/include/asm/kvm_book3s.h:352:12: warning:
>>> 'kvmppc_register_pmu' defined but not used [-Wunused-function]
> 352 | static int kvmppc_register_pmu(void)
> |^~~
> --
>In file included from arch/powerpc/include/asm/kvm_ppc.h:22,
> from arch/powerpc/include/asm/dbell.h:17,
> from arch/powerpc/kernel/asm-offsets.c:36:
>>> arch/powerpc/include/asm/kvm_book3s.h:357:13: warning:
>>> 'kvmppc_unregister_pmu' defined but not used [-Wunused-function]
> 357 | static void kvmppc_unregister_pmu(void)
> | ^
>>> arch/powerpc/include/asm/kvm_book3s.h:352:12: warning:
>>> 'kvmppc_register_pmu' defined but not used [-Wunused-function]
> 352 | static int kvmppc_register_pmu(void)
> |^~~
>
>
> vim +/kvmppc_unregister_pmu +357 arch/powerpc/include/asm/kvm_book3s.h
>
>351
> > 352static int kvmppc_register_pmu(void)
>353{
>354return 0;
>355}
>356
> > 357static void kvmppc_unregister_pmu(void)
>358{
>359}
>360
>
> --
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki
--
Cheers
~ Vaibhav
Re: [PATCH v2 4/6] kvm powerpc/book3s-apiv2: Introduce kvm-hv specific PMU
On Wed, Jan 15, 2025 at 08:09:45PM +0530, Vaibhav Jain wrote:
> Introduce a new PMU named 'kvm-hv' to report Book3s kvm-hv specific
> performance counters. This will expose KVM-HV specific performance
> attributes to user-space via kernel's PMU infrastructure and would enable
> users to monitor active kvm-hv based guests.
>
> The patch creates necessary scaffolding to for the new PMU callbacks and
> introduces two new exports kvmppc_{,un}register_pmu() that are called from
> kvm-hv init and exit function to perform initialize and cleanup for the
> 'kvm-hv' PMU. The patch doesn't introduce any perf-events yet, which will
> be introduced in later patches
>
> Signed-off-by: Vaibhav Jain
>
> ---
> Changelog
>
> v1->v2:
> * Fixed an issue of kvm-hv not loading on baremetal kvm [Gautam]
> ---
> arch/powerpc/include/asm/kvm_book3s.h | 12 +++
> arch/powerpc/kvm/Makefile | 6 ++
> arch/powerpc/kvm/book3s_hv.c | 9 ++
> arch/powerpc/kvm/book3s_hv_pmu.c | 133 ++
> 4 files changed, 160 insertions(+)
> create mode 100644 arch/powerpc/kvm/book3s_hv_pmu.c
>
> diff --git a/arch/powerpc/include/asm/kvm_book3s.h
> b/arch/powerpc/include/asm/kvm_book3s.h
> index e1ff291ba891..cf91a1493159 100644
> --- a/arch/powerpc/include/asm/kvm_book3s.h
> +++ b/arch/powerpc/include/asm/kvm_book3s.h
> @@ -334,6 +334,9 @@ static inline bool kvmhv_is_nestedv1(void)
> return !static_branch_likely(&__kvmhv_is_nestedv2);
> }
>
> +int kvmppc_register_pmu(void);
> +void kvmppc_unregister_pmu(void);
> +
> #else
>
> static inline bool kvmhv_is_nestedv2(void)
> @@ -346,6 +349,15 @@ static inline bool kvmhv_is_nestedv1(void)
> return false;
> }
>
> +static int kvmppc_register_pmu(void)
> +{
> + return 0;
> +}
> +
> +static void kvmppc_unregister_pmu(void)
> +{
> +}
> +
> #endif
>
> int __kvmhv_nestedv2_reload_ptregs(struct kvm_vcpu *vcpu, struct pt_regs
> *regs);
> diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile
> index 4bd9d1230869..094c3916d9d0 100644
> --- a/arch/powerpc/kvm/Makefile
> +++ b/arch/powerpc/kvm/Makefile
> @@ -92,6 +92,12 @@ kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_HANDLER)
> += \
> $(kvm-book3s_64-builtin-tm-objs-y) \
> $(kvm-book3s_64-builtin-xics-objs-y)
>
> +# enable kvm_hv perf events
> +ifdef CONFIG_HAVE_PERF_EVENTS
> +kvm-book3s_64-builtin-objs-$(CONFIG_KVM_BOOK3S_64_HANDLER) += \
> + book3s_hv_pmu.o
> +endif
> +
> obj-$(CONFIG_GUEST_STATE_BUFFER_TEST) += test-guest-state-buffer.o
> endif
>
> diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> index 25429905ae90..6365b8126574 100644
> --- a/arch/powerpc/kvm/book3s_hv.c
> +++ b/arch/powerpc/kvm/book3s_hv.c
> @@ -6662,6 +6662,14 @@ static int kvmppc_book3s_init_hv(void)
> return r;
> }
>
> + r = kvmppc_register_pmu();
> + if (r == -EOPNOTSUPP) {
> + pr_info("KVM-HV: PMU not supported %d\n", r);
> + } else if (r) {
> + pr_err("KVM-HV: Unable to register PMUs %d\n", r);
> + goto err;
> + }
> +
I believe we can simplify this part as follows:
r = kvmppc_register_pmu();
if (r) {
pr_err("KVM-HV: Unable to register PMUs %d\n", r);
goto err;
}
This would also require a minor change in kvmppc_register_pmu(), see below
> kvm_ops_hv.owner = THIS_MODULE;
> kvmppc_hv_ops = &kvm_ops_hv;
>
> @@ -6676,6 +6684,7 @@ static int kvmppc_book3s_init_hv(void)
>
> static void kvmppc_book3s_exit_hv(void)
> {
> + kvmppc_unregister_pmu();
> kvmppc_uvmem_free();
> kvmppc_free_host_rm_ops();
> if (kvmppc_radix_possible())
> diff --git a/arch/powerpc/kvm/book3s_hv_pmu.c
> b/arch/powerpc/kvm/book3s_hv_pmu.c
> new file mode 100644
> index ..8c6ed30b7654
> --- /dev/null
> +++ b/arch/powerpc/kvm/book3s_hv_pmu.c
> @@ -0,0 +1,133 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Description: PMUs specific to running nested KVM-HV guests
> + * on Book3S processors (specifically POWER9 and later).
> + */
> +
> +#define pr_fmt(fmt) "kvmppc-pmu: " fmt
> +
> +#include "asm-generic/local64.h"
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +enum kvmppc_pmu_eventid {
> + KVMPPC_EVENT_MAX,
> +};
> +
> +static struct attribute *kvmppc_pmu_events_attr[] = {
> + NULL,
> +};
> +
> +static const struct attribute_group kvmppc_pmu_events_group = {
> + .name = "events",
> + .attrs = kvmppc_pmu_events_attr,
> +};
> +
> +PMU_FORMAT_ATTR(event, "config:0");
> +static struct attribute *kvmppc_pmu_format_attr[] = {
> + &format_attr_event.attr,
> + NULL,
> +};
> +
> +static struct attribute_group kvmppc_pmu_format_group = {
> + .name = "format",
> + .attr
Re: [PATCH v2 5/6] powerpc/book3s-hv-pmu: Implement GSB message-ops for hostwide counters
On Wed, Jan 15, 2025 at 08:09:46PM +0530, Vaibhav Jain wrote:
> Implement and setup necessary structures to send a prepolulated
> Guest-State-Buffer(GSB) requesting hostwide counters to L0-PowerVM and have
> the returned GSB holding the values of these counters parsed. This is done
> via existing GSB implementation and with the newly added support of
> Hostwide elements in GSB.
>
> The request to L0-PowerVM to return Hostwide counters is done using a
> pre-allocated GSB named 'gsb_l0_stats'. To be able to populate this GSB
> with the needed Guest-State-Elements (GSIDs) a instance of 'struct
> kvmppc_gs_msg' named 'gsm_l0_stats' is introduced. The 'gsm_l0_stats' is
> tied to an instance of 'struct kvmppc_gs_msg_ops' named 'gsb_ops_l0_stats'
> which holds various callbacks to be compute the size ( hostwide_get_size()
> ), populate the GSB ( hostwide_fill_info() ) and
> refresh ( hostwide_refresh_info() ) the contents of
> 'l0_stats' that holds the Hostwide counters returned from L0-PowerVM.
>
> To protect these structures from simultaneous access a spinlock
> 'lock_l0_stats' has been introduced. The allocation and initialization of
> the above structures is done in newly introduced kvmppc_init_hostwide() and
> similarly the cleanup is performed in newly introduced
> kvmppc_cleanup_hostwide().
>
> Signed-off-by: Vaibhav Jain
>
> ---
> Changelog
>
> v1->v2:
> * Added error handling to hostwide_fill_info() [Gautam]
> ---
> arch/powerpc/kvm/book3s_hv_pmu.c | 199 +++
> 1 file changed, 199 insertions(+)
>
> diff --git a/arch/powerpc/kvm/book3s_hv_pmu.c
> b/arch/powerpc/kvm/book3s_hv_pmu.c
> index 8c6ed30b7654..0107ed3b03e3 100644
> --- a/arch/powerpc/kvm/book3s_hv_pmu.c
> +++ b/arch/powerpc/kvm/book3s_hv_pmu.c
> @@ -27,10 +27,31 @@
> #include
> #include
>
> +#include "asm/guest-state-buffer.h"
> +
> enum kvmppc_pmu_eventid {
> KVMPPC_EVENT_MAX,
> };
>
> +#define KVMPPC_PMU_EVENT_ATTR(_name, _id) \
> + PMU_EVENT_ATTR_ID(_name, power_events_sysfs_show, _id)
> +
> +/* Holds the hostwide stats */
> +static struct kvmppc_hostwide_stats {
> + u64 guest_heap;
> + u64 guest_heap_max;
> + u64 guest_pgtable_size;
> + u64 guest_pgtable_size_max;
> + u64 guest_pgtable_reclaim;
> +} l0_stats;
> +
> +/* Protect access to l0_stats */
> +static DEFINE_SPINLOCK(lock_l0_stats);
> +
> +/* GSB related structs needed to talk to L0 */
> +static struct kvmppc_gs_msg *gsm_l0_stats;
> +static struct kvmppc_gs_buff *gsb_l0_stats;
> +
> static struct attribute *kvmppc_pmu_events_attr[] = {
> NULL,
> };
> @@ -90,6 +111,177 @@ static void kvmppc_pmu_read(struct perf_event *event)
> {
> }
>
> +/* Return the size of the needed guest state buffer */
> +static size_t hostwide_get_size(struct kvmppc_gs_msg *gsm)
> +
> +{
> + size_t size = 0;
> + const u16 ids[] = {
> + KVMPPC_GSID_L0_GUEST_HEAP,
> + KVMPPC_GSID_L0_GUEST_HEAP_MAX,
> + KVMPPC_GSID_L0_GUEST_PGTABLE_SIZE,
> + KVMPPC_GSID_L0_GUEST_PGTABLE_SIZE_MAX,
> + KVMPPC_GSID_L0_GUEST_PGTABLE_RECLAIM
> + };
> +
> + for (int i = 0; i < ARRAY_SIZE(ids); i++)
> + size += kvmppc_gse_total_size(kvmppc_gsid_size(ids[i]));
> + return size;
> +}
> +
> +/* Populate the request guest state buffer */
> +static int hostwide_fill_info(struct kvmppc_gs_buff *gsb,
> + struct kvmppc_gs_msg *gsm)
> +{
> + int rc = 0;
> + struct kvmppc_hostwide_stats *stats = gsm->data;
> +
> + /*
> + * It doesn't matter what values are put into request buffer as
> + * they are going to be overwritten anyways. But for the sake of
> + * testcode and symmetry contents of existing stats are put
> + * populated into the request guest state buffer.
> + */
> + if (kvmppc_gsm_includes(gsm, KVMPPC_GSID_L0_GUEST_HEAP))
> + rc = kvmppc_gse_put_u64(gsb,
> + KVMPPC_GSID_L0_GUEST_HEAP,
> + stats->guest_heap);
> +
> + if (!rc && kvmppc_gsm_includes(gsm, KVMPPC_GSID_L0_GUEST_HEAP_MAX))
> + rc = kvmppc_gse_put_u64(gsb,
> + KVMPPC_GSID_L0_GUEST_HEAP_MAX,
> + stats->guest_heap_max);
> +
> + if (!rc && kvmppc_gsm_includes(gsm, KVMPPC_GSID_L0_GUEST_PGTABLE_SIZE))
> + rc = kvmppc_gse_put_u64(gsb,
> + KVMPPC_GSID_L0_GUEST_PGTABLE_SIZE,
> + stats->guest_pgtable_size);
> + if (!rc &&
> + kvmppc_gsm_includes(gsm, KVMPPC_GSID_L0_GUEST_PGTABLE_SIZE_MAX))
> + rc = kvmppc_gse_put_u64(gsb,
> + KVMPPC_GSID_L0_GUEST_PGTABLE_SIZE_MAX,
> + stats->guest_pgtable_size_max);
> + if (!rc &&
> + kvmppc_gsm_includes(gsm, KVMPPC_GSID_L0_GUEST_PGTABLE_RECLAIM))
> +
Re: [PATCH v2] cpufreq: Use str_enable_disable-like helpers
On Wed, Jan 15, 2025 at 8:12 AM Viresh Kumar wrote: > > On 14-01-25, 20:06, Krzysztof Kozlowski wrote: > > Replace ternary (condition ? "enable" : "disable") syntax with helpers > > from string_choices.h because: > > 1. Simple function call with one argument is easier to read. Ternary > >operator has three arguments and with wrapping might lead to quite > >long code. > > 2. Is slightly shorter thus also easier to read. > > 3. It brings uniformity in the text - same string. > > 4. Allows deduping by the linker, which results in a smaller binary > >file. > > > > Signed-off-by: Krzysztof Kozlowski > > Acked-by: Viresh Kumar Applied as 6.14 material, thanks!
Re: [PATCH RFC v2 16/29] mm: asi: Map kernel text and static data as nonsensitive
On Fri, 10 Jan 2025 at 19:41, Brendan Jackman wrote: > + asi_clone_pgd(asi_global_nonsensitive_pgd, init_mm.pgd, > VMEMMAP_START); > + asi_clone_pgd(asi_global_nonsensitive_pgd, init_mm.pgd, > + VMEMMAP_START + (1UL << PGDIR_SHIFT)); There's a bug here that Yosry has fixed in our internal version, I neglected to incorporate that here. Under KASLR, vmemmap is not necessarily exactly 2 PGDs like this is assuming. In fact it can share a PGD entry with the vmalloc area. So to be correct this cloning logic needs to actually look at the alignment and then navigate the page table hierarchy appropriately. To be fixed for the next version. As Yosry noted internally we also need to think about vmmemap getting updated under memory hotplug.
[PATCH] powerpc/powermac: Use str_enabled_disabled() and str_on_off() helpers
Remove hard-coded strings by using the str_enabled_disabled() and
str_on_off() helper functions.
Signed-off-by: Thorsten Blum
---
arch/powerpc/platforms/powermac/setup.c | 4 ++--
arch/powerpc/platforms/powermac/time.c | 3 ++-
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/powermac/setup.c
b/arch/powerpc/platforms/powermac/setup.c
index 6de1cd5d8a58..e119ced05d10 100644
--- a/arch/powerpc/platforms/powermac/setup.c
+++ b/arch/powerpc/platforms/powermac/setup.c
@@ -45,6 +45,7 @@
#include
#include
#include
+#include
#include
#include
@@ -238,8 +239,7 @@ static void __init l2cr_init(void)
_set_L2CR(0);
_set_L2CR(*l2cr);
pr_info("L2CR overridden (0x%x), backside cache
is %s\n",
- *l2cr, ((*l2cr) & 0x8000) ?
- "enabled" : "disabled");
+ *l2cr, str_enabled_disabled((*l2cr) &
0x8000));
}
of_node_put(np);
break;
diff --git a/arch/powerpc/platforms/powermac/time.c
b/arch/powerpc/platforms/powermac/time.c
index 8633891b7aa5..b4426a35aca3 100644
--- a/arch/powerpc/platforms/powermac/time.c
+++ b/arch/powerpc/platforms/powermac/time.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -77,7 +78,7 @@ long __init pmac_time_init(void)
delta |= 0xFF00UL;
dst = ((pmac_xpram_read(PMAC_XPRAM_MACHINE_LOC + 0x8) & 0x80) != 0);
printk("GMT Delta read from XPRAM: %d minutes, DST: %s\n", delta/60,
- dst ? "on" : "off");
+ str_on_off(dst));
#endif
return delta;
}
--
2.48.0
