Re: [PATCH v3 3/3] block: sed-opal: keyring support for SED keys
On 12/1/22 19:03, Greg Joyce wrote: On Wed, 2022-11-30 at 08:00 +0100, Hannes Reinecke wrote: On 11/30/22 00:25, gjo...@linux.vnet.ibm.com wrote: From: Greg Joyce Extend the SED block driver so it can alternatively obtain a key from a sed-opal kernel keyring. The SED ioctls will indicate the source of the key, either directly in the ioctl data or from the keyring. This allows the use of SED commands in scripts such as udev scripts so that drives may be automatically unlocked as they become available. Signed-off-by: Greg Joyce Reviewed-by: Jonathan Derrick --- block/Kconfig | 1 + block/sed-opal.c | 174 +- include/linux/sed-opal.h | 3 + include/uapi/linux/sed-opal.h | 8 +- 4 files changed, 183 insertions(+), 3 deletions(-) + ret = opal_get_key(dev, &opal_lrs->session.opal_key); + if (ret) + return ret; mutex_lock(&dev->dev_lock); setup_opal_dev(dev); ret = execute_steps(dev, lr_steps, ARRAY_SIZE(lr_steps)); @@ -2622,6 +2759,14 @@ static int opal_set_new_pw(struct opal_dev *dev, struct opal_new_pw *opal_pw) ret = execute_steps(dev, pw_steps, ARRAY_SIZE(pw_steps)); mutex_unlock(&dev->dev_lock); + if (ret) + return ret; + + /* update keyring with new password */ + ret = update_sed_opal_key(OPAL_AUTH_KEY, + opal_pw->new_user_pw.opal_key.key, + opal_pw- new_user_pw.opal_key.key_len); + return ret; } What about key revocation? You only allow to set a new key, but what happens with the old ones? My understanding was that key_create_or_update() would not allow duplicates so there shouldn't be old ones. Is that incorrect? Ah, right, you only have one key. But still, you might want to revoke that one, too, no? (Think of decommissioning old drives ...) Cheers, Hannes -- Dr. Hannes ReineckeKernel Storage Architect h...@suse.de +49 911 74053 688 SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg HRB 36809 (AG Nürnberg), Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman
Re: [powerpc:next] BUILD REGRESSION 3604661f206238a0295df53e38b7986a91c00cc4
kernel test robot writes: > tree/branch: > https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next > branch HEAD: 3604661f206238a0295df53e38b7986a91c00cc4 Merge branch > 'topic/qspinlock' into next > > Error/Warning reports: > > https://lore.kernel.org/oe-kbuild-all/202212020435.dr1chxrp-...@intel.com > > Error/Warning: (recently discovered and may have been fixed) > > lockdep.c:(.text.lockdep_register_key+0x174): undefined reference to > `queued_spin_lock_slowpath' > rtas.c:(.text.lock_rtas+0xc0): undefined reference to > `queued_spin_lock_slowpath' > rtas.c:(.text.rtas_give_timebase+0xd0): undefined reference to > `queued_spin_lock_slowpath' > rtas.c:(.text.rtas_take_timebase+0xc4): undefined reference to > `queued_spin_lock_slowpath' > traps.c:(.text.oops_begin+0x10c): undefined reference to > `queued_spin_lock_slowpath' > > Error/Warning ids grouped by kconfigs: > > gcc_recent_errors > `-- powerpc-allmodconfig > |-- > lockdep.c:(.text.lockdep_register_key):undefined-reference-to-queued_spin_lock_slowpath > |-- > rtas.c:(.text.lock_rtas):undefined-reference-to-queued_spin_lock_slowpath > |-- > rtas.c:(.text.rtas_give_timebase):undefined-reference-to-queued_spin_lock_slowpath > |-- > rtas.c:(.text.rtas_take_timebase):undefined-reference-to-queued_spin_lock_slowpath > `-- > traps.c:(.text.oops_begin):undefined-reference-to-queued_spin_lock_slowpath That's a 32-bit allmodconfig, which is not obvious. Nick sent me a hunk to fix this but I didn't squash it in, will fix. cheers
Re: [PATCH v3 2/7] selftests/powerpc: Add ptrace setup_core_pattern() null-terminator
On Mon, 2022-11-28 at 15:19 +1100, Benjamin Gray wrote:
> - malloc() does not zero the buffer,
> - fread() does not null-terminate it's output,
> - `cat /proc/sys/kernel/core_pattern | hexdump -C` shows the file is
> not inherently null-terminated
>
> So using string operations on the buffer is risky. Explicitly add a
> null
> character to the end to make it safer.
>
> Signed-off-by: Benjamin Gray
Reviewed-by: Andrew Donnellan
> ---
> tools/testing/selftests/powerpc/ptrace/core-pkey.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/tools/testing/selftests/powerpc/ptrace/core-pkey.c
> b/tools/testing/selftests/powerpc/ptrace/core-pkey.c
> index bbc05ffc5860..5c82ed9e7c65 100644
> --- a/tools/testing/selftests/powerpc/ptrace/core-pkey.c
> +++ b/tools/testing/selftests/powerpc/ptrace/core-pkey.c
> @@ -383,7 +383,7 @@ static int setup_core_pattern(char
> **core_pattern_, bool *changed_)
> goto out;
> }
>
> - ret = fread(core_pattern, 1, PATH_MAX, f);
> + ret = fread(core_pattern, 1, PATH_MAX - 1, f);
> fclose(f);
> if (!ret) {
> perror("Error reading core_pattern file");
> @@ -391,6 +391,8 @@ static int setup_core_pattern(char
> **core_pattern_, bool *changed_)
> goto out;
> }
>
> + core_pattern[ret] = '\0';
> +
> /* Check whether we can predict the name of the core file. */
> if (!strcmp(core_pattern, "core") || !strcmp(core_pattern,
> "core.%p"))
> *changed_ = false;
--
Andrew DonnellanOzLabs, ADL Canberra
a...@linux.ibm.com IBM Australia Limited
linux-next: boot failure after merge of the powerpc tree
Hi all,
After merging all the trees, today's linux-next qemu run (powerpc
pseries_le_defconfig with kvm) crashed like this:
Memory: 2029504K/2097152K available (14592K kernel code, 2944K rwdata, 18176K
rodata, 5120K init, 1468K bss, 67648K reserved, 0K cma-reserved)
SLUB: HWalign=128, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
BUG: Kernel NULL pointer dereference on read at 0x001c
Faulting instruction address: 0xc047e9bc
Oops: Kernel access of bad area, sig: 7 [#1]
LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 6.1.0-rc7 #1
Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf05
of:SLOF,HEAD hv:linux,kvm pSeries
NIP: c047e9bc LR: c0e06718 CTR: c047e970
REGS: c2773770 TRAP: 0300 Not tainted (6.1.0-rc7)
MSR: 82001033 CR: 22004220 XER:
CFAR: c0070508 DAR: 001c DSISR: 0008 IRQMASK: 3
GPR00: c0e06718 c2773a10 c116fc00
GPR04: 2900 2800
GPR08: 000e c27afc00 4000
GPR12: c047e970 c295 013c8ff0
GPR16: 000d 02be00d0 0001 013c8e60
GPR20: 013c8fa8 013c8d90 c27b2160
GPR24: 0005 c27b3568 c0e06718 2900
GPR28: 2900 07fff33f c2773bc8
NIP [c047e9bc] kmem_cache_alloc+0x5c/0x610
LR [c0e06718] mas_alloc_nodes+0xe8/0x350
Call Trace:
[c2773a10] [0040] 0x40 (unreliable)
[c2773a70] [c0e06718] mas_alloc_nodes+0xe8/0x350
[c2773ad0] [c0e0f7f4] mas_expected_entries+0x94/0x110
[c2773b10] [c012cc44] dup_mmap+0x194/0x730
[c2773c80] [c012d260] dup_mm+0x80/0x180
[c2773cc0] [c008e7c0] text_area_cpu_up_mm+0x20/0x1a0
[c2773d20] [c013367c] cpuhp_invoke_callback+0x15c/0x810
[c2773db0] [c01348dc] cpuhp_issue_call+0x28c/0x2a0
[c2773e00] [c0134e44] __cpuhp_setup_state_cpuslocked+0x154/0x3e0
[c2773eb0] [c0135180] __cpuhp_setup_state+0xb0/0x1d0
[c2773f10] [c2016f9c] poking_init+0x40/0x9c
[c2773f30] [c200434c] start_kernel+0x598/0x914
[c2773fe0] [c000d990] start_here_common+0x1c/0x20
Code: fb81ffe0 7c9b2378 3b293968 fbc1fff0 f8010010 7c7e1b78 fba1ffe8 fbe1fff8
91610008 f821ffa1 f8410018 83b9 <83e3001c> 7fbd2038 7bbc0020 7f84e378
---[ end trace ]---
Kernel panic - not syncing: Attempted to kill the idle task!
Reverting commits
55a02e6ea958 ("powerpc/code-patching: Use temporary mm for Radix MMU")
d0462ee02fdd ("powerpc/code-patching: Consolidate and cache per-cpu patching
context")
(this second just because it follows the other and modifies the same file)
fixes the panic. I have done that in linux-next today.
--
Cheers,
Stephen Rothwell
pgpXI6gLKrvmu.pgp
Description: OpenPGP digital signature
Re: [PATCH 1/5] dt-bindings: net: qca,ar71xx: remove label = "cpu" from examples
On Wed, 30 Nov 2022 17:10:36 +0300, Arınç ÜNAL wrote: > This is not used by the DSA dt-binding, so remove it from the examples. > > Signed-off-by: Arınç ÜNAL > --- > Documentation/devicetree/bindings/net/qca,ar71xx.yaml | 1 - > 1 file changed, 1 deletion(-) > Acked-by: Rob Herring
[powerpc:merge] BUILD SUCCESS 4a8e43570ec8d94403b4ecdfb8f3d4e4807d165e
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge branch HEAD: 4a8e43570ec8d94403b4ecdfb8f3d4e4807d165e Automatic merge of 'master' into merge (2022-11-30 22:02) elapsed time: 2287m configs tested: 86 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: um x86_64_defconfig um i386_defconfig s390defconfig s390 allmodconfig arc defconfig alpha defconfig s390 allyesconfig x86_64 rhel-8.3-func x86_64rhel-8.3-kselftests m68k allyesconfig m68k allmodconfig arc allyesconfig alphaallyesconfig powerpc allnoconfig mips allyesconfig powerpc allmodconfig sh allmodconfig x86_64 rhel-8.3-kvm x86_64 rhel-8.3-syz x86_64 rhel-8.3-kunit ia64 allmodconfig i386 allyesconfig i386defconfig x86_64 defconfig x86_64 allyesconfig x86_64 rhel-8.3 x86_64 randconfig-a002-20221128 x86_64 randconfig-a001-20221128 x86_64 randconfig-a004-20221128 x86_64 randconfig-a006-20221128 x86_64 randconfig-a005-20221128 x86_64 randconfig-a003-20221128 i386 randconfig-a001-20221128 i386 randconfig-a005-20221128 i386 randconfig-a006-20221128 i386 randconfig-a004-20221128 i386 randconfig-a003-20221128 i386 randconfig-a002-20221128 x86_64randconfig-a011 x86_64randconfig-a013 x86_64randconfig-a015 arc randconfig-r043-20221201 riscvrandconfig-r042-20221201 s390 randconfig-r044-20221201 x86_64randconfig-a006 x86_64randconfig-a004 x86_64randconfig-a002 i386 randconfig-a012 i386 randconfig-a014 i386 randconfig-a016 arm64allyesconfig arm defconfig arm allyesconfig i386 randconfig-a003 i386 randconfig-a001 i386 randconfig-a005 clang tested configs: s390 randconfig-r044-20221128 hexagon randconfig-r041-20221128 riscvrandconfig-r042-20221128 hexagon randconfig-r045-20221128 i386 randconfig-a002 i386 randconfig-a006 i386 randconfig-a004 i386 randconfig-a014-20221128 i386 randconfig-a011-20221128 i386 randconfig-a013-20221128 i386 randconfig-a016-20221128 i386 randconfig-a012-20221128 i386 randconfig-a015-20221128 x86_64 randconfig-a011-20221128 x86_64 randconfig-a014-20221128 x86_64 randconfig-a012-20221128 x86_64 randconfig-a013-20221128 x86_64 randconfig-a016-20221128 x86_64 randconfig-a015-20221128 x86_64randconfig-a005 x86_64randconfig-a003 x86_64randconfig-a001 x86_64randconfig-a012 x86_64randconfig-a014 x86_64randconfig-a016 hexagon randconfig-r041-20221201 hexagon randconfig-r045-20221201 i386 randconfig-a013 i386 randconfig-a015 i386 randconfig-a011 -- 0-DAY CI Kernel Test Service https://01.org/lkp
Re: linux-next: build failure after merge of the tip tree
On Fri, 2022-12-02 at 11:26 +1100, Stephen Rothwell wrote: > Though, I wonder if the powerpc tree should > use mm_alloc() instead of copy_init_mm() as well? The tip tree > commit > says: > > Instead of duplicating init_mm, allocate a fresh mm. The > advantage is > that mm_alloc() has much simpler dependencies. Additionally it > makes > more conceptual sense, init_mm has no (and must not have) user > state > to duplicate. > Yes, that seems fine. All we need is that the page table isn't shared and the kernel mappings are the same as in init_mm. It seems mm_alloc() does this at some point.
[powerpc:next] BUILD REGRESSION 3604661f206238a0295df53e38b7986a91c00cc4
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next branch HEAD: 3604661f206238a0295df53e38b7986a91c00cc4 Merge branch 'topic/qspinlock' into next Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202212020435.dr1chxrp-...@intel.com Error/Warning: (recently discovered and may have been fixed) lockdep.c:(.text.lockdep_register_key+0x174): undefined reference to `queued_spin_lock_slowpath' rtas.c:(.text.lock_rtas+0xc0): undefined reference to `queued_spin_lock_slowpath' rtas.c:(.text.rtas_give_timebase+0xd0): undefined reference to `queued_spin_lock_slowpath' rtas.c:(.text.rtas_take_timebase+0xc4): undefined reference to `queued_spin_lock_slowpath' traps.c:(.text.oops_begin+0x10c): undefined reference to `queued_spin_lock_slowpath' Error/Warning ids grouped by kconfigs: gcc_recent_errors `-- powerpc-allmodconfig |-- lockdep.c:(.text.lockdep_register_key):undefined-reference-to-queued_spin_lock_slowpath |-- rtas.c:(.text.lock_rtas):undefined-reference-to-queued_spin_lock_slowpath |-- rtas.c:(.text.rtas_give_timebase):undefined-reference-to-queued_spin_lock_slowpath |-- rtas.c:(.text.rtas_take_timebase):undefined-reference-to-queued_spin_lock_slowpath `-- traps.c:(.text.oops_begin):undefined-reference-to-queued_spin_lock_slowpath elapsed time: 726m configs tested: 50 configs skipped: 2 gcc tested configs: arc defconfig powerpc allnoconfig alpha defconfig um x86_64_defconfig um i386_defconfig x86_64rhel-8.3-kselftests x86_64 rhel-8.3-func s390 allmodconfig s390defconfig sh allmodconfig mips allyesconfig powerpc allmodconfig m68k allyesconfig s390 allyesconfig m68k allmodconfig arc allyesconfig alphaallyesconfig x86_64 rhel-8.3-syz x86_64 rhel-8.3-kunit x86_64 rhel-8.3-kvm ia64 allmodconfig x86_64 rhel-8.3 x86_64 defconfig x86_64 allyesconfig x86_64randconfig-a013 x86_64randconfig-a011 x86_64randconfig-a015 arc randconfig-r043-20221201 riscv randconfig-r042-20221201 s390 randconfig-r044-20221201 i386 randconfig-a003 x86_64allnoconfig i386 randconfig-a001 i386 randconfig-a005 i386 allyesconfig i386defconfig arm64allyesconfig arm defconfig arm allyesconfig i386 randconfig-a012 i386 randconfig-a014 i386 randconfig-a016 clang tested configs: x86_64randconfig-a014 x86_64randconfig-a016 x86_64randconfig-a012 hexagon randconfig-r041-20221201 hexagon randconfig-r045-20221201 i386 randconfig-a004 i386 randconfig-a002 i386 randconfig-a006 -- 0-DAY CI Kernel Test Service https://01.org/lkp
[powerpc:topic/ppc-kvm] BUILD SUCCESS 6c645b01e536757a9e1a9f72c13767f9b3f8559f
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git topic/ppc-kvm branch HEAD: 6c645b01e536757a9e1a9f72c13767f9b3f8559f KVM: PPC: Book3E: Fix CONFIG_TRACE_IRQFLAGS support elapsed time: 2230m configs tested: 156 configs skipped: 145 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: um x86_64_defconfig um i386_defconfig s390defconfig s390 allmodconfig arc defconfig alpha defconfig s390 allyesconfig x86_64 rhel-8.3-func x86_64rhel-8.3-kselftests m68k allyesconfig m68k allmodconfig arc allyesconfig alphaallyesconfig powerpc allnoconfig mips allyesconfig powerpc allmodconfig sh allmodconfig x86_64 rhel-8.3-kvm x86_64 rhel-8.3-syz x86_64 rhel-8.3-kunit ia64 allmodconfig i386 randconfig-a001-20221128 i386 randconfig-a005-20221128 i386 randconfig-a006-20221128 i386 randconfig-a004-20221128 i386 randconfig-a003-20221128 i386 randconfig-a002-20221128 i386 allyesconfig i386defconfig x86_64randconfig-a006 x86_64randconfig-a004 x86_64randconfig-a002 i386 randconfig-a012 i386 randconfig-a014 i386 randconfig-a016 x86_64 defconfig x86_64 allyesconfig x86_64 rhel-8.3 x86_64allnoconfig x86_64 randconfig-a002-20221128 x86_64 randconfig-a001-20221128 x86_64 randconfig-a004-20221128 x86_64 randconfig-a006-20221128 x86_64 randconfig-a005-20221128 x86_64 randconfig-a003-20221128 arm64allyesconfig arm defconfig arm allyesconfig x86_64randconfig-a011 x86_64randconfig-a013 x86_64randconfig-a015 arm u8500_defconfig sh se7780_defconfig openrisc virt_defconfig arm eseries_pxa_defconfig arm sunxi_defconfig powerpc ps3_defconfig mipsmaltaup_xpa_defconfig powerpc allyesconfig riscv defconfig riscvallmodconfig riscvallyesconfig nios2allyesconfig nios2 defconfig parisc defconfig parisc64defconfig parisc allyesconfig i386 randconfig-c001 arc randconfig-r043-20221201 riscvrandconfig-r042-20221201 s390 randconfig-r044-20221201 i386 debian-10.3-kvm i386debian-10.3-kunit i386 debian-10.3-func microblaze defconfig arm iop32x_defconfig armpleb_defconfig sh sdk7780_defconfig sh secureedge5410_defconfig sparc sparc32_defconfig arm badge4_defconfig armoxnas_v6_defconfig arcnsim_700_defconfig arm h3600_defconfig m68k hp300_defconfig sh r7785rp_defconfig powerpc mpc837x_rdb_defconfig xtensa common_defconfig powerpcadder875_defconfig arc alldefconfig microblaze mmu_defconfig powerpc tqm8555_defconfig sparc sparc64_defconfig arc nsimosci_hs_smp_defconfig arm viper_defconfig armmps2_defconfig loongarch defconfig loongarch allnoconfig loongarchallmodconfig alpha allnoconfig sh
[powerpc:next-test] BUILD SUCCESS c4027f8490ab77605d0522069755ccbef0ffe616
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next-test branch HEAD: c4027f8490ab77605d0522069755ccbef0ffe616 selftests/powerpc: Add ptrace setup_core_pattern() null-terminator elapsed time: 725m configs tested: 50 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. gcc tested configs: x86_64 rhel-8.3-kunit powerpc allnoconfig x86_64 rhel-8.3-kvm x86_64 rhel-8.3-syz um i386_defconfig arc defconfig um x86_64_defconfig alpha defconfig x86_64rhel-8.3-kselftests x86_64 rhel-8.3-func s390 allmodconfig s390defconfig sh allmodconfig s390 allyesconfig x86_64 defconfig mips allyesconfig m68k allyesconfig powerpc allmodconfig alphaallyesconfig ia64 allmodconfig m68k allmodconfig arc allyesconfig x86_64 rhel-8.3 x86_64 allyesconfig arc randconfig-r043-20221201 x86_64randconfig-a013 x86_64randconfig-a011 x86_64randconfig-a015 i386 randconfig-a001 s390 randconfig-r044-20221201 i386 randconfig-a003 riscvrandconfig-r042-20221201 i386 randconfig-a005 x86_64allnoconfig i386 allyesconfig i386defconfig arm64allyesconfig arm defconfig arm allyesconfig i386 randconfig-a012 i386 randconfig-a014 i386 randconfig-a016 clang tested configs: x86_64randconfig-a014 x86_64randconfig-a012 hexagon randconfig-r041-20221201 x86_64randconfig-a016 hexagon randconfig-r045-20221201 i386 randconfig-a002 i386 randconfig-a004 i386 randconfig-a006 -- 0-DAY CI Kernel Test Service https://01.org/lkp
linux-next: build failure after merge of the tip tree
Hi all,
After merging the tip tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
arch/powerpc/lib/code-patching.c: In function 'text_area_cpu_up_mm':
arch/powerpc/lib/code-patching.c:157:14: error: implicit declaration of
function 'copy_init_mm' [-Werror=implicit-function-declaration]
157 | mm = copy_init_mm();
| ^~~~
Caused by commit
107b6828a7cd ("x86/mm: Use mm_alloc() in poking_init()")
interacting with commit
55a02e6ea958 ("powerpc/code-patching: Use temporary mm for Radix MMU")
from the powerpc tree.
I partially reverted commit 107b6828a7cd - I left the change to
arch/x86/mm/init.c applied. Though, I wonder if the powerpc tree should
use mm_alloc() instead of copy_init_mm() as well? The tip tree commit
says:
Instead of duplicating init_mm, allocate a fresh mm. The advantage is
that mm_alloc() has much simpler dependencies. Additionally it makes
more conceptual sense, init_mm has no (and must not have) user state
to duplicate.
--
Cheers,
Stephen Rothwell
pgp3WNyp_rAsc.pgp
Description: OpenPGP digital signature
Re: [PATCH 5/5] powerpc: dts: remove label = "cpu" from DSA dt-binding
On Thu, Dec 01, 2022 at 06:39:02PM +0100, Pali Rohár wrote:
> On Thursday 01 December 2022 21:40:03 Michael Ellerman wrote:
> > Arınç ÜNAL writes:
> > > This is not used by the DSA dt-binding, so remove it from all devicetrees.
> > >
> > > Signed-off-by: Arınç ÜNAL
> > > ---
> > > arch/powerpc/boot/dts/turris1x.dts | 2 --
> > > 1 file changed, 2 deletions(-)
> >
> > Adding Pali to Cc.
> >
> > These were only recently updated in commit:
> >
> > 8bf056f57f1d ("powerpc: dts: turris1x.dts: Fix labels in DSA cpu port
> > nodes")
> >
> > Which said:
> >
> > DSA cpu port node has to be marked with "cpu" label.
> >
> > But if the binding doesn't use them then I'm confused why they needed to
> > be updated.
> >
> > cheers
>
> I was told by Marek (CCed) that DSA port connected to CPU should have
> label "cpu" and not "cpu". Modern way for specifying CPU port is
> by defining reference to network device, which there is already (&enet1
> and &enet0). So that change just "fixed" incorrect naming cpu0 and cpu1.
>
> So probably linux kernel does not need label = "cpu" in DTS anymore. But
> this is not the reason to remove this property. Linux kernel does not
> use lot of other nodes and properties too... Device tree should describe
> hardware and not its usage in Linux. "label" property is valid in device
> tree and it exactly describes what or where is this node connected. And
> it may be used for other systems.
>
> So I do not see a point in removing "label" properties from turris1x.dts
> file, nor from any other dts file.
Well, it seems like a bit of an abuse of 'label' to me. 'label' should
be aligned with a sticker or other identifier identifying something to a
human. Software should never care what the value of 'label' is.
Rob
Re: [PATCH 2/5] arm: dts: remove label = "cpu" from DSA dt-binding
On Wed, Nov 30, 2022 at 05:10:37PM +0300, Arınç ÜNAL wrote: [..] > arch/arm/boot/dts/qcom-ipq8064-rb3011.dts | 2 -- Acked-by: Bjorn Andersson Regards, Bjorn
Re: [PATCH v2 21/50] KVM: MIPS: Hardcode callbacks to hardware virtualization extensions
On Thu, Dec 01, 2022, Philippe Mathieu-Daudé wrote:
> On 1/12/22 00:09, Sean Christopherson wrote:
> > Now that KVM no longer supports trap-and-emulate (see commit 45c7e8af4a5e
> > "MIPS: Remove KVM_TE support"), hardcode the MIPS callbacks to the
> > virtualization callbacks.
> >
> > Harcoding the callbacks eliminates the technically-unnecessary check on
> > non-NULL kvm_mips_callbacks in kvm_arch_init(). MIPS has never supported
> > multiple in-tree modules, i.e. barring an out-of-tree module, where
> > copying and renaming kvm.ko counts as "out-of-tree", KVM could never
> > encounter a non-NULL set of callbacks during module init.
> >
> > The callback check is also subtly broken, as it is not thread safe,
> > i.e. if there were multiple modules, loading both concurrently would
> > create a race between checking and setting kvm_mips_callbacks.
> >
> > Given that out-of-tree shenanigans are not the kernel's responsibility,
> > hardcode the callbacks to simplify the code.
> >
> > Signed-off-by: Sean Christopherson
> > ---
> > arch/mips/include/asm/kvm_host.h | 2 +-
> > arch/mips/kvm/Makefile | 2 +-
> > arch/mips/kvm/callback.c | 14 --
> > arch/mips/kvm/mips.c | 9 ++---
> > arch/mips/kvm/vz.c | 7 ---
> > 5 files changed, 8 insertions(+), 26 deletions(-)
> > delete mode 100644 arch/mips/kvm/callback.c
> >
> > diff --git a/arch/mips/include/asm/kvm_host.h
> > b/arch/mips/include/asm/kvm_host.h
> > index 28f0ba97db71..2803c9c21ef9 100644
> > --- a/arch/mips/include/asm/kvm_host.h
> > +++ b/arch/mips/include/asm/kvm_host.h
> > @@ -758,7 +758,7 @@ struct kvm_mips_callbacks {
> > void (*vcpu_reenter)(struct kvm_vcpu *vcpu);
> > };
> > extern struct kvm_mips_callbacks *kvm_mips_callbacks;
>
> IIUC we could even constify this pointer.
Good point. Protecting the pointer itself is a bit gross, but it is a nice
stopgap until the callbacks are gone. I'll fold this in. Thanks!
extern const struct kvm_mips_callbacks * const kvm_mips_callbacks;
Re: [PATCH v2 21/50] KVM: MIPS: Hardcode callbacks to hardware virtualization extensions
On 1/12/22 00:09, Sean Christopherson wrote:
Now that KVM no longer supports trap-and-emulate (see commit 45c7e8af4a5e
"MIPS: Remove KVM_TE support"), hardcode the MIPS callbacks to the
virtualization callbacks.
Harcoding the callbacks eliminates the technically-unnecessary check on
non-NULL kvm_mips_callbacks in kvm_arch_init(). MIPS has never supported
multiple in-tree modules, i.e. barring an out-of-tree module, where
copying and renaming kvm.ko counts as "out-of-tree", KVM could never
encounter a non-NULL set of callbacks during module init.
The callback check is also subtly broken, as it is not thread safe,
i.e. if there were multiple modules, loading both concurrently would
create a race between checking and setting kvm_mips_callbacks.
Given that out-of-tree shenanigans are not the kernel's responsibility,
hardcode the callbacks to simplify the code.
Signed-off-by: Sean Christopherson
---
arch/mips/include/asm/kvm_host.h | 2 +-
arch/mips/kvm/Makefile | 2 +-
arch/mips/kvm/callback.c | 14 --
arch/mips/kvm/mips.c | 9 ++---
arch/mips/kvm/vz.c | 7 ---
5 files changed, 8 insertions(+), 26 deletions(-)
delete mode 100644 arch/mips/kvm/callback.c
diff --git a/arch/mips/include/asm/kvm_host.h b/arch/mips/include/asm/kvm_host.h
index 28f0ba97db71..2803c9c21ef9 100644
--- a/arch/mips/include/asm/kvm_host.h
+++ b/arch/mips/include/asm/kvm_host.h
@@ -758,7 +758,7 @@ struct kvm_mips_callbacks {
void (*vcpu_reenter)(struct kvm_vcpu *vcpu);
};
extern struct kvm_mips_callbacks *kvm_mips_callbacks;
IIUC we could even constify this pointer.
Anyway,
Reviewed-by: Philippe Mathieu-Daudé
diff --git a/arch/mips/kvm/mips.c b/arch/mips/kvm/mips.c
index af29490d9740..f0a6c245d1ff 100644
--- a/arch/mips/kvm/mips.c
+++ b/arch/mips/kvm/mips.c
@@ -1012,17 +1012,12 @@ long kvm_arch_vm_ioctl(struct file *filp, unsigned int
ioctl, unsigned long arg)
int kvm_arch_init(void *opaque)
{
- if (kvm_mips_callbacks) {
- kvm_err("kvm: module already exists\n");
- return -EEXIST;
- }
-
- return kvm_mips_emulation_init(&kvm_mips_callbacks);
+ return kvm_mips_emulation_init();
}
void kvm_arch_exit(void)
{
- kvm_mips_callbacks = NULL;
+
}
int kvm_arch_vcpu_ioctl_get_sregs(struct kvm_vcpu *vcpu,
diff --git a/arch/mips/kvm/vz.c b/arch/mips/kvm/vz.c
index c706f5890a05..dafab003ea0d 100644
--- a/arch/mips/kvm/vz.c
+++ b/arch/mips/kvm/vz.c
@@ -3304,7 +3304,10 @@ static struct kvm_mips_callbacks kvm_vz_callbacks = {
.vcpu_reenter = kvm_vz_vcpu_reenter,
};
-int kvm_mips_emulation_init(struct kvm_mips_callbacks **install_callbacks)
+/* FIXME: Get rid of the callbacks now that trap-and-emulate is gone. */
+struct kvm_mips_callbacks *kvm_mips_callbacks = &kvm_vz_callbacks;
Re: [PATCH v3 3/3] block: sed-opal: keyring support for SED keys
On Wed, 2022-11-30 at 08:00 +0100, Hannes Reinecke wrote:
> On 11/30/22 00:25, gjo...@linux.vnet.ibm.com wrote:
> > From: Greg Joyce
> >
> > Extend the SED block driver so it can alternatively
> > obtain a key from a sed-opal kernel keyring. The SED
> > ioctls will indicate the source of the key, either
> > directly in the ioctl data or from the keyring.
> >
> > This allows the use of SED commands in scripts such as
> > udev scripts so that drives may be automatically unlocked
> > as they become available.
> >
> > Signed-off-by: Greg Joyce
> > Reviewed-by: Jonathan Derrick
> > ---
> > block/Kconfig | 1 +
> > block/sed-opal.c | 174
> > +-
> > include/linux/sed-opal.h | 3 +
> > include/uapi/linux/sed-opal.h | 8 +-
> > 4 files changed, 183 insertions(+), 3 deletions(-)
> >
> > + ret = opal_get_key(dev, &opal_lrs->session.opal_key);
> > + if (ret)
> > + return ret;
> > mutex_lock(&dev->dev_lock);
> > setup_opal_dev(dev);
> > ret = execute_steps(dev, lr_steps, ARRAY_SIZE(lr_steps));
> > @@ -2622,6 +2759,14 @@ static int opal_set_new_pw(struct opal_dev
> > *dev, struct opal_new_pw *opal_pw)
> > ret = execute_steps(dev, pw_steps, ARRAY_SIZE(pw_steps));
> > mutex_unlock(&dev->dev_lock);
> >
> > + if (ret)
> > + return ret;
> > +
> > + /* update keyring with new password */
> > + ret = update_sed_opal_key(OPAL_AUTH_KEY,
> > + opal_pw->new_user_pw.opal_key.key,
> > + opal_pw-
> > >new_user_pw.opal_key.key_len);
> > +
> > return ret;
> > }
> >
> What about key revocation?
> You only allow to set a new key, but what happens with the old ones?
My understanding was that key_create_or_update() would not allow
duplicates so there shouldn't be old ones. Is that incorrect?
>
> > +static int __init sed_opal_init(void)
> > +{
> > + struct key *kr;
> > +
> > + kr = keyring_alloc(".sed_opal",
> > + GLOBAL_ROOT_UID, GLOBAL_ROOT_GID,
> > current_cred(),
> > + (KEY_POS_ALL & ~KEY_POS_SETATTR) |
> > KEY_USR_VIEW |
> > + KEY_USR_READ | KEY_USR_SEARCH |
> > KEY_USR_WRITE,
> > + KEY_ALLOC_NOT_IN_QUOTA,
> > + NULL, NULL);
> > + if (IS_ERR(kr))
> > + return PTR_ERR(kr);
> > +
> > + sed_opal_keyring = kr;
> > +
> > + return 0;
> > +}
> > +late_initcall(sed_opal_init);
>
> Shouldn't you free the keyring on exit?
The SED Opal driver is part of the block driver and does not build as a
module so it will not exit. I had looked at "blacklist" as an example
and saw that it allocated but did not free its keyring.
> Cheers,
>
> Hannes
Thanks for the comments on the keyring. I'm not very familiar with the
keyring code, so I'd appreciate suggestions on code changes if any are
needed for your two comments.
-Greg
[linux-next:master] BUILD REGRESSION 2934ceb4e967b9233d0f97732e47175574a11406
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 2934ceb4e967b9233d0f97732e47175574a11406 Add linux-next specific files for 20221201 Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202211041320.coq8eelj-...@intel.com https://lore.kernel.org/oe-kbuild-all/202211090634.ryfkk0ws-...@intel.com https://lore.kernel.org/oe-kbuild-all/202211242021.fdzrfna8-...@intel.com https://lore.kernel.org/oe-kbuild-all/202211242120.mzzvguln-...@intel.com https://lore.kernel.org/oe-kbuild-all/202211301840.y7rrob13-...@intel.com https://lore.kernel.org/oe-kbuild-all/202212011005.7x5xasmg-...@intel.com https://lore.kernel.org/oe-kbuild-all/202212020122.myyqvrxj-...@intel.com Error/Warning: (recently discovered and may have been fixed) arch/arm/mach-s3c/devs.c:32:10: fatal error: linux/platform_data/dma-s3c24xx.h: No such file or directory arch/loongarch/kernel/ftrace_dyn.c:47:36: error: invalid use of undefined type 'struct module' arch/powerpc/kernel/kvm_emul.o: warning: objtool: kvm_template_end(): can't find starting instruction arch/powerpc/kernel/optprobes_head.o: warning: objtool: optprobe_template_end(): can't find starting instruction drivers/gpu/drm/amd/amdgpu/../display/dc/irq/dcn201/irq_service_dcn201.c:40:20: warning: no previous prototype for 'to_dal_irq_source_dcn201' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/engine/fifo/gf100.c:451:1: warning: no previous prototype for 'gf100_fifo_nonstall_block' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/engine/fifo/gf100.c:451:1: warning: no previous prototype for function 'gf100_fifo_nonstall_block' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/engine/fifo/runl.c:34:1: warning: no previous prototype for 'nvkm_engn_cgrp_get' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/engine/fifo/runl.c:34:1: warning: no previous prototype for function 'nvkm_engn_cgrp_get' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c:210:1: warning: no previous prototype for 'tu102_gr_load' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c:210:1: warning: no previous prototype for function 'tu102_gr_load' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/nvfw/acr.c:49:1: warning: no previous prototype for 'wpr_generic_header_dump' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/nvfw/acr.c:49:1: warning: no previous prototype for function 'wpr_generic_header_dump' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/subdev/acr/lsfw.c:221:21: warning: variable 'loc' set but not used [-Wunused-but-set-variable] drivers/irqchip/irq-loongarch-cpu.c:96:12: warning: no previous prototype for 'loongarch_cpu_irq_of_init' [-Wmissing-prototypes] drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c:1849:38: warning: unused variable 'mt8173_jpeg_drvdata' [-Wunused-const-variable] drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c:1864:38: warning: unused variable 'mtk_jpeg_drvdata' [-Wunused-const-variable] drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c:1890:38: warning: unused variable 'mtk8195_jpegdec_drvdata' [-Wunused-const-variable] drivers/regulator/tps65219-regulator.c:310:60: warning: parameter 'dev' set but not used [-Wunused-but-set-parameter] drivers/regulator/tps65219-regulator.c:370:26: warning: ordered comparison of pointer with integer zero [-Wextra] net/netfilter/nf_conntrack_netlink.c:2674:6: warning: unused variable 'mark' [-Wunused-variable] vmlinux.o: warning: objtool: __btrfs_map_block+0x1d77: unreachable instruction Error/Warning ids grouped by kconfigs: gcc_recent_errors |-- alpha-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-irq-dcn201-irq_service_dcn201.c:warning:no-previous-prototype-for-to_dal_irq_source_dcn201 | |-- drivers-gpu-drm-nouveau-nvkm-engine-fifo-gf100.c:warning:no-previous-prototype-for-gf100_fifo_nonstall_block | |-- drivers-gpu-drm-nouveau-nvkm-engine-fifo-runl.c:warning:no-previous-prototype-for-nvkm_engn_cgrp_get | |-- drivers-gpu-drm-nouveau-nvkm-engine-gr-tu102.c:warning:no-previous-prototype-for-tu102_gr_load | |-- drivers-gpu-drm-nouveau-nvkm-nvfw-acr.c:warning:no-previous-prototype-for-wpr_generic_header_dump | |-- drivers-gpu-drm-nouveau-nvkm-subdev-acr-lsfw.c:warning:variable-loc-set-but-not-used | |-- drivers-regulator-tps65219-regulator.c:warning:ordered-comparison-of-pointer-with-integer-zero | `-- drivers-regulator-tps65219-regulator.c:warning:parameter-dev-set-but-not-used |-- alpha-randconfig-r005-20221128 | |-- drivers-gpu-drm-nouveau-nvkm-engine-fifo-gf100.c:warning:no-previous-prototype-for-gf100_fifo_nonstall_block | |-- drivers-gpu-drm-nouveau-nvkm-engine-fifo-runl.c:warning:no-previous-prototype-for-nvkm_engn_cgrp_get | |-- drivers-gpu-drm-nouve
Re: [PATCH 2/3] selftests/powerpc: Bump up rlimit for perf-hwbreak test
Hi, I have verified and tested this patch. No issues found. Changes look good. Tested-by: Rohan Deshpande
Re: [PATCH v8 3/3] ASoC: SOF: Fix deadlock when shutdown a frozen userspace
Hi Oliver
On Thu, 1 Dec 2022 at 14:22, 'Oliver Neukum' via Chromeos Kdump
wrote:
>
> On 01.12.22 14:03, Ricardo Ribalda wrote:
>
> Hi,
>
> > This patchset does not modify this behaviour. It simply fixes the
> > stall for kexec().
> >
> > The patch that introduced the stall:
> > 83bfc7e793b5 ("ASoC: SOF: core: unregister clients and machine drivers
> > in .shutdown")
>
> That patch is problematic. I would go as far as saying that
> it needs to be reverted.
>
It fixes a real issue. We have not had any complaints until we tried
to kexec in the platform.
I wont recommend reverting it until we have an alternative implementation.
kexec is far less common than suspend/reboot.
> > was sent as a generalised version of:
> > https://github.com/thesofproject/linux/pull/3388
> >
> > AFAIK, we would need a similar patch for every single board which
> > I am not sure it is doable in a reasonable timeframe.
> >
> > On the meantime this seems like a decent compromises. Yes, a
> > miss-behaving userspace can still stall during suspend, but that was
> > not introduced in this patch.
>
> Well, I mean if you know what wrong then I'd say at least return to
> a sanely broken state.
>
> The whole approach is wrong. You need to be able to deal with user
> space talking to removed devices by returning an error and keeping
> the resources association with the open file allocated until
> user space calls close()
In general, the whole shutdown is broken for all the subsystems ;).
It is a complicated issue. Users handling fds, devices with DMAs in
the middle of an operation, dma fences
Unfortunately I am not that familiar with the sound subsystem to make
a proper patch for this.
>
> Regards
> Oliver
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Chromeos Kdump" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to chromeos-kdump+unsubscr...@google.com.
> To view this discussion on the web, visit
> https://groups.google.com/a/google.com/d/msgid/chromeos-kdump/d3730d1d-6f92-700a-06c4-0e0a35e270b0%40suse.com.
--
Ricardo Ribalda
Re: [PATCH v8 3/3] ASoC: SOF: Fix deadlock when shutdown a frozen userspace
On 01.12.22 14:03, Ricardo Ribalda wrote:
Hi,
This patchset does not modify this behaviour. It simply fixes the
stall for kexec().
The patch that introduced the stall:
83bfc7e793b5 ("ASoC: SOF: core: unregister clients and machine drivers
in .shutdown")
That patch is problematic. I would go as far as saying that
it needs to be reverted.
was sent as a generalised version of:
https://github.com/thesofproject/linux/pull/3388
AFAIK, we would need a similar patch for every single board which
I am not sure it is doable in a reasonable timeframe.
On the meantime this seems like a decent compromises. Yes, a
miss-behaving userspace can still stall during suspend, but that was
not introduced in this patch.
Well, I mean if you know what wrong then I'd say at least return to
a sanely broken state.
The whole approach is wrong. You need to be able to deal with user
space talking to removed devices by returning an error and keeping
the resources association with the open file allocated until
user space calls close()
Regards
Oliver
Re: [PATCH v8 3/3] ASoC: SOF: Fix deadlock when shutdown a frozen userspace
Hi Oliver
Thanks for your review
On Thu, 1 Dec 2022 at 13:29, Oliver Neukum wrote:
>
> On 01.12.22 12:08, Ricardo Ribalda wrote:
> > If we are shutting down due to kexec and the userspace is frozen, the
> > system will stall forever waiting for userspace to complete.
> >
> > Do not wait for the clients to complete in that case.
>
> Hi,
>
> I am afraid I have to state that this approach is bad in every case,
> not just this corner case. It basically means that user space can stall
> the kernel for an arbitrary amount of time. And we cannot have that.
>
> Regards
> Oliver
This patchset does not modify this behaviour. It simply fixes the
stall for kexec().
The patch that introduced the stall:
83bfc7e793b5 ("ASoC: SOF: core: unregister clients and machine drivers
in .shutdown")
was sent as a generalised version of:
https://github.com/thesofproject/linux/pull/3388
AFAIK, we would need a similar patch for every single board which
I am not sure it is doable in a reasonable timeframe.
On the meantime this seems like a decent compromises. Yes, a
miss-behaving userspace can still stall during suspend, but that was
not introduced in this patch.
Regards!
>
--
Ricardo Ribalda
Re: [PATCH v8 3/3] ASoC: SOF: Fix deadlock when shutdown a frozen userspace
On 01.12.22 12:08, Ricardo Ribalda wrote: If we are shutting down due to kexec and the userspace is frozen, the system will stall forever waiting for userspace to complete. Do not wait for the clients to complete in that case. Hi, I am afraid I have to state that this approach is bad in every case, not just this corner case. It basically means that user space can stall the kernel for an arbitrary amount of time. And we cannot have that. Regards Oliver
Re: [PATCH 0/5] remove label = "cpu" from DSA dt-binding
On 1.12.2022 13:42, Michael Ellerman wrote: Arınç ÜNAL writes: On 30.11.2022 18:55, Andrew Lunn wrote: On Wed, Nov 30, 2022 at 05:10:35PM +0300, Arınç ÜNAL wrote: Hello folks, With this patch series, we're completely getting rid of 'label = "cpu";' which is not used by the DSA dt-binding at all. Information for taking the patches for maintainers: Patch 1: netdev maintainers (based off netdev/net-next.git main) Patch 2-3: SoC maintainers (based off soc/soc.git soc/dt) Patch 4: MIPS maintainers (based off mips/linux.git mips-next) Patch 5: PowerPC maintainers (based off powerpc/linux.git next-test) Hi Arınç So your plan is that each architecture maintainer merges one patch? Initially, I sent this series to s...@kernel.org to take it all but Rob said it must be this way instead. That is fine, but it is good to be explicit, otherwise patches will fall through the cracks because nobody picks them up. I generally use To: to indicate who i expect to merge a patch, and everybody else in the Cc: Thanks for this, I'll follow suit if I don't see any activity for a few weeks. IMHO the best solution if the patches are truly independent is to send them independantly to each maintainer. That way there's no confusion about whether someone else will take the series. It's also simpler for maintainers to apply a single standalone patch vs pick a single patch from a larger series. I agree. I'll do that next time. Cheers. Arınç
Re: [RFC PATCH] Disable Book-E KVM support?
Am 1. Dezember 2022 06:06:16 UTC schrieb Nicholas Piggin : >On Thu Dec 1, 2022 at 6:45 AM AEST, Crystal Wood wrote: >> On Mon, 2022-11-28 at 14:36 +1000, Nicholas Piggin wrote: >> > BookE KVM is in a deep maintenance state, I'm not sure how much testing >> > it gets. I don't have a test setup, and it does not look like QEMU has >> > any HV architecture enabled. It hasn't been too painful but there are >> > some cases where it causes a bit of problem not being able to test, e.g., >> > >> > https://lists.ozlabs.org/pipermail/linuxppc-dev/2022-November/251452.html >> > >> > Time to begin removal process, or are there still people using it? I'm >> > happy to to keep making occasional patches to try keep it going if >> > there are people testing upstream. Getting HV support into QEMU would >> > help with long term support, not sure how big of a job that would be. >> >> Not sure what you mean about QEMU not having e500 HV support? I don't know >> if >> it's bitrotted, but it's there. >> >> I don't know whether anyone is still using this, but if they are, it's >> probably e500mc and not e500v2 (which involved a bunch of hacks to get >> almost- >> sorta-usable performance out of hardware not designed for virtualization). I >> do see that there have been a few recent patches on QEMU e500 (beyond the >> treewide cleanup type stuff), though I don't know if they're using KVM. >> CCing >> them and the QEMU list. Thanks for CCing! No, I'm not using KVM on e500. The goal of my patches is to run software in QEMU on an x86_64 host rather than on a real PPC machine to optimize our development process. Best regards, Bernhard >Well I could be wrong about it, but it doesn't look it implements LPIDR >or GSPRs. The only use of MSR_GS seems to be a couple of places >including an instruction that aborts because no HV implementation. It >does have an MMU index selector but before d764184ddb22 that apparently >didn't really work. > >QEMU probably should be able to run BookE KVM in PR mode at least. > >> I have an e6500 I could occasionally test on, if it turns out people do still >> care about this. Don't count me as the use case, though. :-) > >Do you have a KVM setup on it? And it works with recentish upstream? > >> FWIW, as far as the RECONCILE_IRQ_STATE issue, that used to be done in >> kvmppc_handle_exit(), but was moved in commit 9bd880a2c882 to be "cleaner and >> faster". :-P > >Yeah that was probably reasonable at the time, that was the common way >to do it and thie patch avoids an unnecessary expensive write to MSR >(which my patch retains). > >I think it must have always clobbered r4 though. It's possible it wasn't >tested with the right build option, or the right tracer active, or maybe >the call was simple enough that it was lucky and the compiler didn't use >r4. Easy bug to miss when it's not obvious that macro can call into C. > >Thanks, >Nick
Re: [PATCH 4/5] mips: dts: remove label = "cpu" from DSA dt-binding
On Wed, Nov 30, 2022 at 05:10:39PM +0300, Arınç ÜNAL wrote:
> This is not used by the DSA dt-binding, so remove it from all devicetrees.
>
> Signed-off-by: Arınç ÜNAL
> ---
> arch/mips/boot/dts/qca/ar9331.dtsi| 1 -
> arch/mips/boot/dts/ralink/mt7621.dtsi | 1 -
> 2 files changed, 2 deletions(-)
>
> diff --git a/arch/mips/boot/dts/qca/ar9331.dtsi
> b/arch/mips/boot/dts/qca/ar9331.dtsi
> index c4102b280b47..768ac0f869b1 100644
> --- a/arch/mips/boot/dts/qca/ar9331.dtsi
> +++ b/arch/mips/boot/dts/qca/ar9331.dtsi
> @@ -176,7 +176,6 @@ ports {
>
> switch_port0: port@0 {
> reg = <0x0>;
> - label = "cpu";
> ethernet = <ð1>;
>
> phy-mode = "gmii";
> diff --git a/arch/mips/boot/dts/ralink/mt7621.dtsi
> b/arch/mips/boot/dts/ralink/mt7621.dtsi
> index f3f4c1f26e01..445817cbf376 100644
> --- a/arch/mips/boot/dts/ralink/mt7621.dtsi
> +++ b/arch/mips/boot/dts/ralink/mt7621.dtsi
> @@ -386,7 +386,6 @@ port@4 {
>
> port@6 {
> reg = <6>;
> - label = "cpu";
> ethernet = <&gmac0>;
> phy-mode = "trgmii";
>
> --
> 2.34.1
applied to mips-next.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]
[PATCH v8 3/3] ASoC: SOF: Fix deadlock when shutdown a frozen userspace
If we are shutting down due to kexec and the userspace is frozen, the
system will stall forever waiting for userspace to complete.
Do not wait for the clients to complete in that case.
This fixes:
[ 84.943749] Freezing user space processes ... (elapsed 0.111 seconds) done.
[ 246.784446] INFO: task kexec-lite:5123 blocked for more than 122 seconds.
[ 246.819035] Call Trace:
[ 246.821782]
[ 246.824186] __schedule+0x5f9/0x1263
[ 246.828231] schedule+0x87/0xc5
[ 246.831779] snd_card_disconnect_sync+0xb5/0x127
...
[ 246.889249] snd_sof_device_shutdown+0xb4/0x150
[ 246.899317] pci_device_shutdown+0x37/0x61
[ 246.903990] device_shutdown+0x14c/0x1d6
[ 246.908391] kernel_kexec+0x45/0xb9
And:
[ 246.893222] INFO: task kexec-lite:4891 blocked for more than 122 seconds.
[ 246.927709] Call Trace:
[ 246.930461]
[ 246.932819] __schedule+0x5f9/0x1263
[ 246.936855] ? fsnotify_grab_connector+0x5c/0x70
[ 246.942045] schedule+0x87/0xc5
[ 246.945567] schedule_timeout+0x49/0xf3
[ 246.949877] wait_for_completion+0x86/0xe8
[ 246.954463] snd_card_free+0x68/0x89
...
[ 247.001080] platform_device_unregister+0x12/0x35
Cc: sta...@vger.kernel.org
Fixes: 83bfc7e793b5 ("ASoC: SOF: core: unregister clients and machine drivers
in .shutdown")
Signed-off-by: Ricardo Ribalda
---
sound/soc/sof/core.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/sound/soc/sof/core.c b/sound/soc/sof/core.c
index 3e6141d03770..9587b6a85103 100644
--- a/sound/soc/sof/core.c
+++ b/sound/soc/sof/core.c
@@ -9,6 +9,8 @@
//
#include
+#include
+#include
#include
#include
#include
@@ -484,9 +486,10 @@ int snd_sof_device_shutdown(struct device *dev)
* make sure clients and machine driver(s) are unregistered to force
* all userspace devices to be closed prior to the DSP shutdown sequence
*/
- sof_unregister_clients(sdev);
-
- snd_sof_machine_unregister(sdev, pdata);
+ if (!(kexec_in_progress() && pm_freezing())) {
+ sof_unregister_clients(sdev);
+ snd_sof_machine_unregister(sdev, pdata);
+ }
if (sdev->fw_state == SOF_FW_BOOT_COMPLETE)
return snd_sof_shutdown(sdev);
--
2.39.0.rc0.267.gcb52ba06e7-goog-b4-0.11.0-dev-696ae
[PATCH v8 2/3] freezer: refactor pm_freezing into a function.
Add a way to let the drivers know if the processes are frozen.
This is needed by drivers that are waiting for processes to end on their
shutdown path.
Convert pm_freezing into a function and export it, so it can be used by
drivers that are either built-in or modules.
Cc: sta...@vger.kernel.org
Fixes: 83bfc7e793b5 ("ASoC: SOF: core: unregister clients and machine drivers
in .shutdown")
Signed-off-by: Ricardo Ribalda
sdad
---
include/linux/freezer.h | 3 ++-
kernel/freezer.c| 3 +--
kernel/power/process.c | 24
3 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/include/linux/freezer.h b/include/linux/freezer.h
index b303472255be..3413c869d68b 100644
--- a/include/linux/freezer.h
+++ b/include/linux/freezer.h
@@ -13,7 +13,7 @@
#ifdef CONFIG_FREEZER
DECLARE_STATIC_KEY_FALSE(freezer_active);
-extern bool pm_freezing; /* PM freezing in effect */
+bool pm_freezing(void);
extern bool pm_nosig_freezing; /* PM nosig freezing in effect */
/*
@@ -80,6 +80,7 @@ static inline int freeze_processes(void) { return -ENOSYS; }
static inline int freeze_kernel_threads(void) { return -ENOSYS; }
static inline void thaw_processes(void) {}
static inline void thaw_kernel_threads(void) {}
+static inline bool pm_freezing(void) { return false; }
static inline bool try_to_freeze(void) { return false; }
diff --git a/kernel/freezer.c b/kernel/freezer.c
index 4fad0e6fca64..2d3530ebdb7e 100644
--- a/kernel/freezer.c
+++ b/kernel/freezer.c
@@ -20,7 +20,6 @@ EXPORT_SYMBOL(freezer_active);
* indicate whether PM freezing is in effect, protected by
* system_transition_mutex
*/
-bool pm_freezing;
bool pm_nosig_freezing;
/* protects freezing and frozen transitions */
@@ -46,7 +45,7 @@ bool freezing_slow_path(struct task_struct *p)
if (pm_nosig_freezing || cgroup_freezing(p))
return true;
- if (pm_freezing && !(p->flags & PF_KTHREAD))
+ if (pm_freezing() && !(p->flags & PF_KTHREAD))
return true;
return false;
diff --git a/kernel/power/process.c b/kernel/power/process.c
index ddd9988327fe..8a4d0e2c8c20 100644
--- a/kernel/power/process.c
+++ b/kernel/power/process.c
@@ -108,6 +108,22 @@ static int try_to_freeze_tasks(bool user_only)
return todo ? -EBUSY : 0;
}
+/*
+ * Indicate whether PM freezing is in effect, protected by
+ * system_transition_mutex.
+ */
+static bool pm_freezing_internal;
+
+/**
+ * pm_freezing - indicate whether PM freezing is in effect.
+ *
+ */
+bool pm_freezing(void)
+{
+ return pm_freezing_internal;
+}
+EXPORT_SYMBOL(pm_freezing);
+
/**
* freeze_processes - Signal user space processes to enter the refrigerator.
* The current thread will not be frozen. The same process that calls
@@ -126,12 +142,12 @@ int freeze_processes(void)
/* Make sure this task doesn't get frozen */
current->flags |= PF_SUSPEND_TASK;
- if (!pm_freezing)
+ if (!pm_freezing())
static_branch_inc(&freezer_active);
pm_wakeup_clear(0);
pr_info("Freezing user space processes ... ");
- pm_freezing = true;
+ pm_freezing_internal = true;
error = try_to_freeze_tasks(true);
if (!error) {
__usermodehelper_set_disable_depth(UMH_DISABLED);
@@ -187,9 +203,9 @@ void thaw_processes(void)
struct task_struct *curr = current;
trace_suspend_resume(TPS("thaw_processes"), 0, true);
- if (pm_freezing)
+ if (pm_freezing())
static_branch_dec(&freezer_active);
- pm_freezing = false;
+ pm_freezing_internal = false;
pm_nosig_freezing = false;
oom_killer_enable();
--
2.39.0.rc0.267.gcb52ba06e7-goog-b4-0.11.0-dev-696ae
[PATCH v8 1/3] kexec: Refactor kexec_in_progress into a function
Drivers running .shutdown() might want to behave differently during
kexec.
Convert kexec_in_progress into a function and export it, so it can be
used by drivers that are either built-in or modules.
Cc: sta...@vger.kernel.org
Fixes: 83bfc7e793b5 ("ASoC: SOF: core: unregister clients and machine drivers
in .shutdown")
Signed-off-by: Ricardo Ribalda
---
arch/powerpc/platforms/pseries/vio.c | 2 +-
arch/x86/kernel/cpu/mshyperv.c | 6 +++---
arch/x86/xen/enlighten_hvm.c | 2 +-
drivers/firmware/efi/efi.c | 2 +-
drivers/pci/pci-driver.c | 2 +-
include/linux/kexec.h| 5 ++---
kernel/kexec_core.c | 12 ++--
7 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/vio.c
b/arch/powerpc/platforms/pseries/vio.c
index 00ecac2c205b..923f9a36b992 100644
--- a/arch/powerpc/platforms/pseries/vio.c
+++ b/arch/powerpc/platforms/pseries/vio.c
@@ -1289,7 +1289,7 @@ static void vio_bus_shutdown(struct device *dev)
viodrv = to_vio_driver(dev->driver);
if (viodrv->shutdown)
viodrv->shutdown(viodev);
- else if (kexec_in_progress)
+ else if (kexec_in_progress())
vio_bus_remove(dev);
}
}
diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
index 831613959a92..f91f35206489 100644
--- a/arch/x86/kernel/cpu/mshyperv.c
+++ b/arch/x86/kernel/cpu/mshyperv.c
@@ -122,21 +122,21 @@ void hv_remove_crash_handler(void)
#ifdef CONFIG_KEXEC_CORE
static void hv_machine_shutdown(void)
{
- if (kexec_in_progress && hv_kexec_handler)
+ if (kexec_in_progress() && hv_kexec_handler)
hv_kexec_handler();
/*
* Call hv_cpu_die() on all the CPUs, otherwise later the hypervisor
* corrupts the old VP Assist Pages and can crash the kexec kernel.
*/
- if (kexec_in_progress && hyperv_init_cpuhp > 0)
+ if (kexec_in_progress() && hyperv_init_cpuhp > 0)
cpuhp_remove_state(hyperv_init_cpuhp);
/* The function calls stop_other_cpus(). */
native_machine_shutdown();
/* Disable the hypercall page when there is only 1 active CPU. */
- if (kexec_in_progress)
+ if (kexec_in_progress())
hyperv_cleanup();
}
diff --git a/arch/x86/xen/enlighten_hvm.c b/arch/x86/xen/enlighten_hvm.c
index c1cd28e915a3..769163833ffc 100644
--- a/arch/x86/xen/enlighten_hvm.c
+++ b/arch/x86/xen/enlighten_hvm.c
@@ -145,7 +145,7 @@ DEFINE_IDTENTRY_SYSVEC(sysvec_xen_hvm_callback)
static void xen_hvm_shutdown(void)
{
native_machine_shutdown();
- if (kexec_in_progress)
+ if (kexec_in_progress())
xen_reboot(SHUTDOWN_soft_reset);
}
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index a46df5d1d094..608bc2146802 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -1040,7 +1040,7 @@ static int update_efi_random_seed(struct notifier_block
*nb,
struct linux_efi_random_seed *seed;
u32 size = 0;
- if (!kexec_in_progress)
+ if (!kexec_in_progress())
return NOTIFY_DONE;
seed = memremap(efi_rng_seed, sizeof(*seed), MEMREMAP_WB);
diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
index 107d77f3c846..23eeb7538b03 100644
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -519,7 +519,7 @@ static void pci_device_shutdown(struct device *dev)
* If it is not a kexec reboot, firmware will hit the PCI
* devices with big hammer and stop their DMA any way.
*/
- if (kexec_in_progress && (pci_dev->current_state <= PCI_D3hot))
+ if (kexec_in_progress() && pci_dev->current_state <= PCI_D3hot)
pci_clear_master(pci_dev);
}
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index 41a686996aaa..2ec0aec1a0de 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -423,8 +423,7 @@ extern int kexec_load_disabled;
#define KEXEC_FILE_FLAGS (KEXEC_FILE_UNLOAD | KEXEC_FILE_ON_CRASH | \
KEXEC_FILE_NO_INITRAMFS)
-/* flag to track if kexec reboot is in progress */
-extern bool kexec_in_progress;
+bool kexec_in_progress(void);
int crash_shrink_memory(unsigned long new_size);
ssize_t crash_get_memory_size(void);
@@ -507,7 +506,7 @@ static inline void __crash_kexec(struct pt_regs *regs) { }
static inline void crash_kexec(struct pt_regs *regs) { }
static inline int kexec_should_crash(struct task_struct *p) { return 0; }
static inline int kexec_crash_loaded(void) { return 0; }
-#define kexec_in_progress false
+static inline bool kexec_in_progress(void) { return false; }
#endif /* CONFIG_KEXEC_CORE */
#ifdef CONFIG_KEXEC_SIG
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index ca2743f9c634..4495d0fc28ae 100644
--- a/kernel/kexec_cor
[PATCH v8 0/3] ASoC: SOF: Fix deadlock when shutdown a frozen userspace
Since: 83bfc7e793b5 ("ASoC: SOF: core: unregister clients and machine drivers
in .shutdown")
we wait for all the workloads to be completed during shutdown. This was done to
avoid a stall once the device is started again.
Unfortunately this has the side effect of stalling kexec(), if the userspace
is frozen. Let's handle that case.
To: Joel Fernandes
To: Pierre-Louis Bossart
To: Liam Girdwood
To: Peter Ujfalusi
To: Bard Liao
To: Ranjani Sridharan
To: Kai Vehmanen
To: Daniel Baluta
To: Mark Brown
To: Jaroslav Kysela
To: Takashi Iwai
To: Eric Biederman
To: Chromeos Kdump
To: Steven Rostedt
To: Michael Ellerman
To: Nicholas Piggin
To: Christophe Leroy
To: "K. Y. Srinivasan"
To: Haiyang Zhang
To: Wei Liu
To: Dexuan Cui
To: Thomas Gleixner
To: Ingo Molnar
To: Borislav Petkov
To: Dave Hansen
To: x...@kernel.org
To: "H. Peter Anvin"
To: Juergen Gross
To: Boris Ostrovsky
To: Ard Biesheuvel
To: Bjorn Helgaas
To: "Rafael J. Wysocki"
To: Pavel Machek
To: Len Brown
Cc: sta...@vger.kernel.org
Cc: sound-open-firmw...@alsa-project.org
Cc: alsa-de...@alsa-project.org
Cc: linux-ker...@vger.kernel.org
Cc: ke...@lists.infradead.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-hyp...@vger.kernel.org
Cc: xen-de...@lists.xenproject.org
Cc: linux-...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux...@vger.kernel.org
Signed-off-by: Ricardo Ribalda
---
Changes in v8:
- Wrap pm_freezing and kexec_inprogress in functions.
- Do not run snd_sof_machine_unregister(sdev, pdata) during kexec (Thanks Kai).
- Link to v7:
https://lore.kernel.org/r/20221127-snd-freeze-v7-0-127c582f1...@chromium.org
Changes in v7:
- Fix commit message (Thanks Pierre-Louis).
- Link to v6:
https://lore.kernel.org/r/20221127-snd-freeze-v6-0-3e90553f6...@chromium.org
Changes in v6:
- Check if we are in kexec with the userspace frozen.
- Link to v5:
https://lore.kernel.org/r/20221127-snd-freeze-v5-0-4ededeb08...@chromium.org
Changes in v5:
- Edit subject prefix.
- Link to v4:
https://lore.kernel.org/r/20221127-snd-freeze-v4-0-51ca64b7f...@chromium.org
Changes in v4:
- Do not call snd_sof_machine_unregister from shutdown.
- Link to v3:
https://lore.kernel.org/r/20221127-snd-freeze-v3-0-a2eda731c...@chromium.org
Changes in v3:
- Wrap pm_freezing in a function.
- Link to v2:
https://lore.kernel.org/r/20221127-snd-freeze-v2-0-d8a425ea9...@chromium.org
Changes in v2:
- Only use pm_freezing if CONFIG_FREEZER .
- Link to v1:
https://lore.kernel.org/r/20221127-snd-freeze-v1-0-57461a366...@chromium.org
---
Ricardo Ribalda (3):
kexec: Refactor kexec_in_progress into a function
freezer: refactor pm_freezing into a function.
ASoC: SOF: Fix deadlock when shutdown a frozen userspace
arch/powerpc/platforms/pseries/vio.c | 2 +-
arch/x86/kernel/cpu/mshyperv.c | 6 +++---
arch/x86/xen/enlighten_hvm.c | 2 +-
drivers/firmware/efi/efi.c | 2 +-
drivers/pci/pci-driver.c | 2 +-
include/linux/freezer.h | 3 ++-
include/linux/kexec.h| 5 ++---
kernel/freezer.c | 3 +--
kernel/kexec_core.c | 12 ++--
kernel/power/process.c | 24
sound/soc/sof/core.c | 9 ++---
11 files changed, 48 insertions(+), 22 deletions(-)
---
base-commit: 4312098baf37ee17a8350725e6e0d0e8590252d4
change-id: 20221127-snd-freeze-1ee143228326
Best regards,
--
Ricardo Ribalda
Re: [PATCH v2 34/50] KVM: x86: Unify pr_fmt to use module name for all KVM modules
On 30/11/2022 23:09, Sean Christopherson wrote: Define pr_fmt using KBUILD_MODNAME for all KVM x86 code so that printks use consistent formatting across common x86, Intel, and AMD code. In addition to providing consistent print formatting, using KBUILD_MODNAME, e.g. kvm_amd and kvm_intel, allows referencing SVM and VMX (and SEV and SGX and ...) as technologies without generating weird messages, and without causing naming conflicts with other kernel code, e.g. "SEV: ", "tdx: ", "sgx: " etc.. are all used by the kernel for non-KVM subsystems. Opportunistically move away from printk() for prints that need to be modified anyways, e.g. to drop a manual "kvm: " prefix. Opportunistically convert a few SGX WARNs that are similarly modified to WARN_ONCE; in the very unlikely event that the WARNs fire, odds are good that they would fire repeatedly and spam the kernel log without providing unique information in each print. Note, defining pr_fmt yields undesirable results for code that uses KVM's printk wrappers, e.g. vcpu_unimpl(). But, that's a pre-existing problem as SVM/kvm_amd already defines a pr_fmt, and thankfully use of KVM's wrappers is relatively limited in KVM x86 code. Signed-off-by: Sean Christopherson --- [snip] diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c index b246decb53a9..3bf7d69373cf 100644 --- a/arch/x86/kvm/xen.c +++ b/arch/x86/kvm/xen.c @@ -5,6 +5,7 @@ * * KVM Xen emulation */ +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt #include "x86.h" #include "xen.h" Reviewed-by: Paul Durrant
Re: [PATCH 0/5] remove label = "cpu" from DSA dt-binding
Arınç ÜNAL writes: > On 30.11.2022 18:55, Andrew Lunn wrote: >> On Wed, Nov 30, 2022 at 05:10:35PM +0300, Arınç ÜNAL wrote: >>> Hello folks, >>> >>> With this patch series, we're completely getting rid of 'label = "cpu";' >>> which is not used by the DSA dt-binding at all. >>> >>> Information for taking the patches for maintainers: >>> Patch 1: netdev maintainers (based off netdev/net-next.git main) >>> Patch 2-3: SoC maintainers (based off soc/soc.git soc/dt) >>> Patch 4: MIPS maintainers (based off mips/linux.git mips-next) >>> Patch 5: PowerPC maintainers (based off powerpc/linux.git next-test) >> >> Hi Arınç >> >> So your plan is that each architecture maintainer merges one patch? > > Initially, I sent this series to s...@kernel.org to take it all but Rob > said it must be this way instead. > >> >> That is fine, but it is good to be explicit, otherwise patches will >> fall through the cracks because nobody picks them up. I generally use >> To: to indicate who i expect to merge a patch, and everybody else in >> the Cc: > > Thanks for this, I'll follow suit if I don't see any activity for a few > weeks. IMHO the best solution if the patches are truly independent is to send them independantly to each maintainer. That way there's no confusion about whether someone else will take the series. It's also simpler for maintainers to apply a single standalone patch vs pick a single patch from a larger series. cheers
Re: [PATCH 1/5] dt-bindings: net: qca,ar71xx: remove label = "cpu" from examples
On Wed, Nov 30, 2022 at 05:10:36PM +0300, Arınç ÜNAL wrote:
> This is not used by the DSA dt-binding, so remove it from the examples.
>
> Signed-off-by: Arınç ÜNAL
Reviewed-by: Oleksij Rempel
Thx!
> ---
> Documentation/devicetree/bindings/net/qca,ar71xx.yaml | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/net/qca,ar71xx.yaml
> b/Documentation/devicetree/bindings/net/qca,ar71xx.yaml
> index 1ebf9e8c8a1d..89f94b31b546 100644
> --- a/Documentation/devicetree/bindings/net/qca,ar71xx.yaml
> +++ b/Documentation/devicetree/bindings/net/qca,ar71xx.yaml
> @@ -123,7 +123,6 @@ examples:
>
> switch_port0: port@0 {
> reg = <0x0>;
> -label = "cpu";
> ethernet = <ð1>;
>
> phy-mode = "gmii";
> --
> 2.34.1
>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH 4/5] mips: dts: remove label = "cpu" from DSA dt-binding
On Wed, Nov 30, 2022 at 05:10:39PM +0300, Arınç ÜNAL wrote:
> This is not used by the DSA dt-binding, so remove it from all devicetrees.
>
> Signed-off-by: Arınç ÜNAL
> ---
> arch/mips/boot/dts/qca/ar9331.dtsi| 1 -
> arch/mips/boot/dts/ralink/mt7621.dtsi | 1 -
> 2 files changed, 2 deletions(-)
>
> diff --git a/arch/mips/boot/dts/qca/ar9331.dtsi
> b/arch/mips/boot/dts/qca/ar9331.dtsi
> index c4102b280b47..768ac0f869b1 100644
> --- a/arch/mips/boot/dts/qca/ar9331.dtsi
> +++ b/arch/mips/boot/dts/qca/ar9331.dtsi
> @@ -176,7 +176,6 @@ ports {
>
> switch_port0: port@0 {
> reg = <0x0>;
> - label = "cpu";
> ethernet = <ð1>;
>
> phy-mode = "gmii";
Reviewed-by: Oleksij Rempel
Thx!
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH 5/5] powerpc: dts: remove label = "cpu" from DSA dt-binding
On Thursday 01 December 2022 21:40:03 Michael Ellerman wrote:
> Arınç ÜNAL writes:
> > This is not used by the DSA dt-binding, so remove it from all devicetrees.
> >
> > Signed-off-by: Arınç ÜNAL
> > ---
> > arch/powerpc/boot/dts/turris1x.dts | 2 --
> > 1 file changed, 2 deletions(-)
>
> Adding Pali to Cc.
>
> These were only recently updated in commit:
>
> 8bf056f57f1d ("powerpc: dts: turris1x.dts: Fix labels in DSA cpu port
> nodes")
>
> Which said:
>
> DSA cpu port node has to be marked with "cpu" label.
>
> But if the binding doesn't use them then I'm confused why they needed to
> be updated.
>
> cheers
I was told by Marek (CCed) that DSA port connected to CPU should have
label "cpu" and not "cpu". Modern way for specifying CPU port is
by defining reference to network device, which there is already (&enet1
and &enet0). So that change just "fixed" incorrect naming cpu0 and cpu1.
So probably linux kernel does not need label = "cpu" in DTS anymore. But
this is not the reason to remove this property. Linux kernel does not
use lot of other nodes and properties too... Device tree should describe
hardware and not its usage in Linux. "label" property is valid in device
tree and it exactly describes what or where is this node connected. And
it may be used for other systems.
So I do not see a point in removing "label" properties from turris1x.dts
file, nor from any other dts file.
>
> > diff --git a/arch/powerpc/boot/dts/turris1x.dts
> > b/arch/powerpc/boot/dts/turris1x.dts
> > index 045af668e928..3841c8d96d00 100644
> > --- a/arch/powerpc/boot/dts/turris1x.dts
> > +++ b/arch/powerpc/boot/dts/turris1x.dts
> > @@ -147,7 +147,6 @@ ports {
> >
> > port@0 {
> > reg = <0>;
> > - label = "cpu";
> > ethernet = <&enet1>;
> > phy-mode = "rgmii-id";
> >
> > @@ -184,7 +183,6 @@ port@5 {
> >
> > port@6 {
> > reg = <6>;
> > - label = "cpu";
> > ethernet = <&enet0>;
> > phy-mode = "rgmii-id";
> >
> > --
> > 2.34.1
Re: [PATCH v3 3/3] block: sed-opal: keyring support for SED keys
On Thu, 2022-12-01 at 10:58 -0600, Greg Joyce wrote:
> On Thu, 2022-12-01 at 11:12 -0500, Ben Boeckel wrote:
> > On Thu, Dec 01, 2022 at 09:29:36 -0600, Greg Joyce wrote:
> > > On Wed, 2022-11-30 at 22:46 -0500, Ben Boeckel wrote:
> > > > Perhaps naming it `OPAL_MAX_KEY_LEN` would help clarify this?
> > >
> > > I'm not averse to changing it because it would be clearer. My
> > > concern
> > > is that it's been OPAL_KEY_MAX for 5+ years (the original SED
> > > Opal
> > > commit). Unless there is strong consensus to change it, I'm going
> > > to
> > > leave it as the original name.
> >
> > I don't care about the name (very much in the peanut gallery), just
> > it
> > not being a magic number :) .
> >
> > --Ben
>
> Now I get you! I think that you mean changing to this:
>
> if (ret > 0) {
> if (ret > sizeof(key->key_len)) {
> ret = -ENOSPC;
> goto error;
> }
> key->key_len = ret;
> key->key_type = OPAL_INCLUDED;
> }
Sorry, that's incorrect. I think that you just meant removing the 255.
Re: [PATCH v3 3/3] block: sed-opal: keyring support for SED keys
On Thu, 2022-12-01 at 11:12 -0500, Ben Boeckel wrote:
> On Thu, Dec 01, 2022 at 09:29:36 -0600, Greg Joyce wrote:
> > On Wed, 2022-11-30 at 22:46 -0500, Ben Boeckel wrote:
> > > Perhaps naming it `OPAL_MAX_KEY_LEN` would help clarify this?
> >
> > I'm not averse to changing it because it would be clearer. My
> > concern
> > is that it's been OPAL_KEY_MAX for 5+ years (the original SED Opal
> > commit). Unless there is strong consensus to change it, I'm going
> > to
> > leave it as the original name.
>
> I don't care about the name (very much in the peanut gallery), just
> it
> not being a magic number :) .
>
> --Ben
Now I get you! I think that you mean changing to this:
if (ret > 0) {
if (ret > sizeof(key->key_len)) {
ret = -ENOSPC;
goto error;
}
key->key_len = ret;
key->key_type = OPAL_INCLUDED;
}
Re: [PATCH v2 26/50] KVM: PPC: Move processor compatibility check to module init
On Thu, Dec 01, 2022, Michael Ellerman wrote:
> Sean Christopherson writes:
> > Move KVM PPC's compatibility checks to their respective module_init()
> > hooks, there's no need to wait until KVM's common compat check, nor is
> > there a need to perform the check on every CPU (provided by common KVM's
> > hook), as the compatibility checks operate on global data.
> >
> > arch/powerpc/include/asm/cputable.h: extern struct cpu_spec *cur_cpu_spec;
> > arch/powerpc/kvm/book3s.c: return 0
> > arch/powerpc/kvm/e500.c: strcmp(cur_cpu_spec->cpu_name, "e500v2")
> > arch/powerpc/kvm/e500mc.c: strcmp(cur_cpu_spec->cpu_name, "e500mc")
> > strcmp(cur_cpu_spec->cpu_name, "e5500")
> > strcmp(cur_cpu_spec->cpu_name, "e6500")
>
> I'm not sure that output is really useful in the change log unless you
> explain more about what it is.
Agreed, I got lazy. I'll write a proper description.
> > diff --git a/arch/powerpc/kvm/e500mc.c b/arch/powerpc/kvm/e500mc.c
> > index 57e0ad6a2ca3..795667f7ebf0 100644
> > --- a/arch/powerpc/kvm/e500mc.c
> > +++ b/arch/powerpc/kvm/e500mc.c
> > @@ -388,6 +388,10 @@ static int __init kvmppc_e500mc_init(void)
> > {
> > int r;
> >
> > + r = kvmppc_e500mc_check_processor_compat();
> > + if (r)
> > + return kvmppc_e500mc;
>
> This doesn't build:
>
> linux/arch/powerpc/kvm/e500mc.c: In function ‘kvmppc_e500mc_init’:
> linux/arch/powerpc/kvm/e500mc.c:391:13: error: implicit declaration of
> function ‘kvmppc_e500mc_check_processor_compat’; did you mean
> ‘kvmppc_core_check_processor_compat’? [-Werror=implicit-function-declaration]
> 391 | r = kvmppc_e500mc_check_processor_compat();
> | ^~~~
> | kvmppc_core_check_processor_compat
> linux/arch/powerpc/kvm/e500mc.c:393:24: error: ‘kvmppc_e500mc’ undeclared
> (first use in this function); did you mean ‘kvm_ops_e500mc’?
> 393 | return kvmppc_e500mc;
> |^
> |kvm_ops_e500mc
> linux/arch/powerpc/kvm/e500mc.c:393:24: note: each undeclared identifier is
> reported only once for each function it appears in
Huh, CONFIG_PPC_E500MC got unselected in the config I use to compile test this
flavor. I suspect I botched an oldconfig at some point.
Anyways, fixed that and the bugs.
Thanks much!
--
Subject: [PATCH] KVM: PPC: Move processor compatibility check to module init
Move KVM PPC's compatibility checks to their respective module_init()
hooks, there's no need to wait until KVM's common compat check, nor is
there a need to perform the check on every CPU (provided by common KVM's
hook). The compatibility checks are either a nop (Book3S), or simply
check the CPU name stored in the global CPU spec (e500 and e500mc).
Cc: Fabiano Rosas
Cc: Michael Ellerman
Signed-off-by: Sean Christopherson
---
arch/powerpc/include/asm/kvm_ppc.h | 1 -
arch/powerpc/kvm/book3s.c | 10 --
arch/powerpc/kvm/e500.c| 4 ++--
arch/powerpc/kvm/e500mc.c | 6 +-
arch/powerpc/kvm/powerpc.c | 2 +-
5 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/arch/powerpc/include/asm/kvm_ppc.h
b/arch/powerpc/include/asm/kvm_ppc.h
index bfacf12784dd..51a1824b0a16 100644
--- a/arch/powerpc/include/asm/kvm_ppc.h
+++ b/arch/powerpc/include/asm/kvm_ppc.h
@@ -118,7 +118,6 @@ extern int kvmppc_xlate(struct kvm_vcpu *vcpu, ulong eaddr,
extern int kvmppc_core_vcpu_create(struct kvm_vcpu *vcpu);
extern void kvmppc_core_vcpu_free(struct kvm_vcpu *vcpu);
extern int kvmppc_core_vcpu_setup(struct kvm_vcpu *vcpu);
-extern int kvmppc_core_check_processor_compat(void);
extern int kvmppc_core_vcpu_translate(struct kvm_vcpu *vcpu,
struct kvm_translation *tr);
diff --git a/arch/powerpc/kvm/book3s.c b/arch/powerpc/kvm/book3s.c
index 6d525285dbe8..87283a0e33d8 100644
--- a/arch/powerpc/kvm/book3s.c
+++ b/arch/powerpc/kvm/book3s.c
@@ -999,16 +999,6 @@ int kvmppc_h_logical_ci_store(struct kvm_vcpu *vcpu)
}
EXPORT_SYMBOL_GPL(kvmppc_h_logical_ci_store);
-int kvmppc_core_check_processor_compat(void)
-{
- /*
-* We always return 0 for book3s. We check
-* for compatibility while loading the HV
-* or PR module
-*/
- return 0;
-}
-
int kvmppc_book3s_hcall_implemented(struct kvm *kvm, unsigned long hcall)
{
return kvm->arch.kvm_ops->hcall_implemented(hcall);
diff --git a/arch/powerpc/kvm/e500.c b/arch/powerpc/kvm/e500.c
index c8b2b4478545..0ea61190ec04 100644
--- a/arch/powerpc/kvm/e500.c
+++ b/arch/powerpc/kvm/e500.c
@@ -314,7 +314,7 @@ static void kvmppc_core_vcpu_put_e500(struct kvm_vcpu *vcpu)
kvmppc_booke_vcpu_put(vcpu);
}
-int kvmppc_core_check_processor_compat(void)
+static int kvmppc_e500_check_processor_compat(void)
{
int r;
@@ -507,7 +507,7 @@ static int __init kvmppc_e500_
Re: [PATCH v3 3/3] block: sed-opal: keyring support for SED keys
On Thu, Dec 01, 2022 at 09:29:36 -0600, Greg Joyce wrote: > On Wed, 2022-11-30 at 22:46 -0500, Ben Boeckel wrote: > > Perhaps naming it `OPAL_MAX_KEY_LEN` would help clarify this? > > I'm not averse to changing it because it would be clearer. My concern > is that it's been OPAL_KEY_MAX for 5+ years (the original SED Opal > commit). Unless there is strong consensus to change it, I'm going to > leave it as the original name. I don't care about the name (very much in the peanut gallery), just it not being a magic number :) . --Ben
[PATCH] powerpc/ftrace: fix syscall tracing on PPC64_ELF_ABI_V1
In v5.7 the powerpc syscall entry/exit logic was rewritten in C, on
PPC64_ELF_ABI_V1 this resulted in the symbols in the syscall table
changing from their dot prefixed variant to the non-prefixed ones.
Since ftrace prefixes a dot to the syscall names when matching them to
build its syscall event list, this resulted in no syscall events being
available.
Remove the PPC64_ELF_ABI_V1 specific version of
arch_syscall_match_sym_name to have the same behavior across all powerpc
variants.
Fixes: 68b34588e202 ("powerpc/64/sycall: Implement syscall entry/exit logic in
C")
Cc: sta...@vger.kernel.org # v5.7+
Cc: Steven Rostedt
Cc: Masami Hiramatsu
Cc: Mark Rutland
Cc: Michael Ellerman
Cc: Nicholas Piggin
Cc: Christophe Leroy
Cc: Michal Suchanek
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Michael Jeanson
Reviewed-by: Mathieu Desnoyers
---
arch/powerpc/include/asm/ftrace.h | 12
1 file changed, 12 deletions(-)
diff --git a/arch/powerpc/include/asm/ftrace.h
b/arch/powerpc/include/asm/ftrace.h
index 3cee7115441b..e3d1f377bc5b 100644
--- a/arch/powerpc/include/asm/ftrace.h
+++ b/arch/powerpc/include/asm/ftrace.h
@@ -64,17 +64,6 @@ void ftrace_graph_func(unsigned long ip, unsigned long
parent_ip,
* those.
*/
#define ARCH_HAS_SYSCALL_MATCH_SYM_NAME
-#ifdef CONFIG_PPC64_ELF_ABI_V1
-static inline bool arch_syscall_match_sym_name(const char *sym, const char
*name)
-{
- /* We need to skip past the initial dot, and the __se_sys alias */
- return !strcmp(sym + 1, name) ||
- (!strncmp(sym, ".__se_sys", 9) && !strcmp(sym + 6, name)) ||
- (!strncmp(sym, ".ppc_", 5) && !strcmp(sym + 5, name + 4)) ||
- (!strncmp(sym, ".ppc32_", 7) && !strcmp(sym + 7, name + 4)) ||
- (!strncmp(sym, ".ppc64_", 7) && !strcmp(sym + 7, name + 4));
-}
-#else
static inline bool arch_syscall_match_sym_name(const char *sym, const char
*name)
{
return !strcmp(sym, name) ||
@@ -83,7 +72,6 @@ static inline bool arch_syscall_match_sym_name(const char
*sym, const char *name
(!strncmp(sym, "ppc32_", 6) && !strcmp(sym + 6, name + 4)) ||
(!strncmp(sym, "ppc64_", 6) && !strcmp(sym + 6, name + 4));
}
-#endif /* CONFIG_PPC64_ELF_ABI_V1 */
#endif /* CONFIG_FTRACE_SYSCALLS */
#if defined(CONFIG_PPC64) && defined(CONFIG_FUNCTION_TRACER)
--
2.34.1
Re: [PATCH v2 10/50] KVM: VMX: Reset eVMCS controls in VP assist page during hardware disabling
Sean Christopherson writes:
> Reset the eVMCS controls in the per-CPU VP assist page during hardware
> disabling instead of waiting until kvm-intel's module exit. The controls
> are activated if and only if KVM creates a VM, i.e. don't need to be
> reset if hardware is never enabled.
>
> Doing the reset during hardware disabling will naturally fix a potential
> NULL pointer deref bug once KVM disables CPU hotplug while enabling and
> disabling hardware (which is necessary to fix a variety of bugs). If the
> kernel is running as the root partition, the VP assist page is unmapped
> during CPU hot unplug, and so KVM's clearing of the eVMCS controls needs
> to occur with CPU hot(un)plug disabled, otherwise KVM could attempt to
> write to a CPU's VP assist page after it's unmapped.
>
> Reported-by: Vitaly Kuznetsov
> Signed-off-by: Sean Christopherson
> ---
> arch/x86/kvm/vmx/vmx.c | 50 +-
> 1 file changed, 30 insertions(+), 20 deletions(-)
>
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index cea8c07f5229..d85d175dca70 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -551,6 +551,33 @@ static int hv_enable_l2_tlb_flush(struct kvm_vcpu *vcpu)
> return 0;
> }
>
> +static void hv_reset_evmcs(void)
> +{
> + struct hv_vp_assist_page *vp_ap;
> +
> + if (!static_branch_unlikely(&enable_evmcs))
> + return;
> +
> + /*
> + * KVM should enable eVMCS if and only if all CPUs have a VP assist
> + * page, and should reject CPU onlining if eVMCS is enabled the CPU
> + * doesn't have a VP assist page allocated.
> + */
> + vp_ap = hv_get_vp_assist_page(smp_processor_id());
> + if (WARN_ON_ONCE(!vp_ap))
> + return;
> +
In case my understanding is correct, this may actually get triggered
for Hyper-V root partition: vmx_hardware_disable() gets called from
kvm_dying_cpu() which has its own CPUHP_AP_KVM_STARTING stage. VP page
unmapping happens in hv_cpu_die() which uses generic CPUHP_AP_ONLINE_DYN
(happens first on CPU oflining AFAIR). I believe we need to introduce a
new CPUHP_AP_HYPERV_STARTING stage and put it before
CPUHP_AP_KVM_STARTING so it happens after it upon offlining.
The issue is likely theoretical as Hyper-V root partition is a very
special case, I'm not sure whether KVM is used there and whether CPU
offlining is possible. In any case, WARN_ON_ONCE() is much better than
NULL pointer dereference we have now :-)
> + /*
> + * Reset everything to support using non-enlightened VMCS access later
> + * (e.g. when we reload the module with enlightened_vmcs=0)
> + */
> + vp_ap->nested_control.features.directhypercall = 0;
> + vp_ap->current_nested_vmcs = 0;
> + vp_ap->enlighten_vmentry = 0;
> +}
> +
> +#else /* IS_ENABLED(CONFIG_HYPERV) */
> +static void hv_reset_evmcs(void) {}
> #endif /* IS_ENABLED(CONFIG_HYPERV) */
>
> /*
> @@ -2496,6 +2523,8 @@ static void vmx_hardware_disable(void)
> if (cpu_vmxoff())
> kvm_spurious_fault();
>
> + hv_reset_evmcs();
> +
> intel_pt_handle_vmx(0);
> }
>
> @@ -8462,27 +8491,8 @@ static void vmx_exit(void)
> kvm_exit();
>
> #if IS_ENABLED(CONFIG_HYPERV)
> - if (static_branch_unlikely(&enable_evmcs)) {
> - int cpu;
> - struct hv_vp_assist_page *vp_ap;
> - /*
> - * Reset everything to support using non-enlightened VMCS
> - * access later (e.g. when we reload the module with
> - * enlightened_vmcs=0)
> - */
> - for_each_online_cpu(cpu) {
> - vp_ap = hv_get_vp_assist_page(cpu);
> -
> - if (!vp_ap)
> - continue;
> -
> - vp_ap->nested_control.features.directhypercall = 0;
> - vp_ap->current_nested_vmcs = 0;
> - vp_ap->enlighten_vmentry = 0;
> - }
> -
> + if (static_branch_unlikely(&enable_evmcs))
> static_branch_disable(&enable_evmcs);
> - }
> #endif
> vmx_cleanup_l1d_flush();
Reviewed-by: Vitaly Kuznetsov
--
Vitaly
Re: [PATCH v3 3/3] block: sed-opal: keyring support for SED keys
On Wed, 2022-11-30 at 22:46 -0500, Ben Boeckel wrote:
> On Wed, Nov 30, 2022 at 09:19:25 -0600, Greg Joyce wrote:
> > On Wed, 2022-11-30 at 08:00 +0100, Hannes Reinecke wrote:
> > > On 11/30/22 00:25, gjo...@linux.vnet.ibm.com wrote:
> > > > + case OPAL_KEYRING:
> > > > + /* the key is in the keyring */
> > > > + ret = read_sed_opal_key(OPAL_AUTH_KEY, key-
> > > > >key,
> > > > OPAL_KEY_MAX);
> > > > + if (ret > 0) {
> > > > + if (ret > 255) {
> > >
> > > Why is a key longer than 255 an error?
> > > If this is a requirement, why not move the check into
> > > read_sed_opal_key() such that one only has to check for
> > > ret < 0 on errors?
> >
> > The check is done here because the SED Opal spec stipulates 255 as
> > the
> > maximum key length. The key length (key->key_len) in the existing
> > data
> > structures is __u8, so a length greater than 255 can not be
> > conveyed.
> > For defensive purposes, I though it best to check here.
>
> Perhaps naming it `OPAL_MAX_KEY_LEN` would help clarify this?
>
> --Ben
I'm not averse to changing it because it would be clearer. My concern
is that it's been OPAL_KEY_MAX for 5+ years (the original SED Opal
commit). Unless there is strong consensus to change it, I'm going to
leave it as the original name.
-Greg
Re: [PATCH v2 12/50] KVM: VMX: Move Hyper-V eVMCS initialization to helper
Sean Christopherson writes:
> Move Hyper-V's eVMCS initialization to a dedicated helper to clean up
> vmx_init(), and add a comment to call out that the Hyper-V init code
> doesn't need to be unwound if vmx_init() ultimately fails.
>
> No functional change intended.
>
> Signed-off-by: Sean Christopherson
> ---
> arch/x86/kvm/vmx/vmx.c | 73 +-
> 1 file changed, 43 insertions(+), 30 deletions(-)
>
> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
> index c0de7160700b..b8bf95b9710d 100644
> --- a/arch/x86/kvm/vmx/vmx.c
> +++ b/arch/x86/kvm/vmx/vmx.c
> @@ -523,6 +523,8 @@ static inline void vmx_segment_cache_clear(struct
> vcpu_vmx *vmx)
> static unsigned long host_idt_base;
>
> #if IS_ENABLED(CONFIG_HYPERV)
> +static struct kvm_x86_ops vmx_x86_ops __initdata;
> +
> static bool __read_mostly enlightened_vmcs = true;
> module_param(enlightened_vmcs, bool, 0444);
>
> @@ -551,6 +553,43 @@ static int hv_enable_l2_tlb_flush(struct kvm_vcpu *vcpu)
> return 0;
> }
>
> +static __init void hv_init_evmcs(void)
> +{
> + int cpu;
> +
> + if (!enlightened_vmcs)
> + return;
> +
> + /*
> + * Enlightened VMCS usage should be recommended and the host needs
> + * to support eVMCS v1 or above.
> + */
> + if (ms_hyperv.hints & HV_X64_ENLIGHTENED_VMCS_RECOMMENDED &&
> + (ms_hyperv.nested_features & HV_X64_ENLIGHTENED_VMCS_VERSION) >=
> + KVM_EVMCS_VERSION) {
> +
> + /* Check that we have assist pages on all online CPUs */
> + for_each_online_cpu(cpu) {
> + if (!hv_get_vp_assist_page(cpu)) {
> + enlightened_vmcs = false;
> + break;
> + }
> + }
> +
> + if (enlightened_vmcs) {
> + pr_info("KVM: vmx: using Hyper-V Enlightened VMCS\n");
> + static_branch_enable(&enable_evmcs);
> + }
> +
> + if (ms_hyperv.nested_features & HV_X64_NESTED_DIRECT_FLUSH)
> + vmx_x86_ops.enable_l2_tlb_flush
> + = hv_enable_l2_tlb_flush;
> +
> + } else {
> + enlightened_vmcs = false;
> + }
> +}
> +
> static void hv_reset_evmcs(void)
> {
> struct hv_vp_assist_page *vp_ap;
> @@ -577,6 +616,7 @@ static void hv_reset_evmcs(void)
> }
>
> #else /* IS_ENABLED(CONFIG_HYPERV) */
> +static void hv_init_evmcs(void) {}
> static void hv_reset_evmcs(void) {}
> #endif /* IS_ENABLED(CONFIG_HYPERV) */
>
> @@ -8500,38 +8540,11 @@ static int __init vmx_init(void)
> {
> int r, cpu;
>
> -#if IS_ENABLED(CONFIG_HYPERV)
> /*
> - * Enlightened VMCS usage should be recommended and the host needs
> - * to support eVMCS v1 or above. We can also disable eVMCS support
> - * with module parameter.
> + * Note, hv_init_evmcs() touches only VMX knobs, i.e. there's nothing
> + * to unwind if a later step fails.
>*/
> - if (enlightened_vmcs &&
> - ms_hyperv.hints & HV_X64_ENLIGHTENED_VMCS_RECOMMENDED &&
> - (ms_hyperv.nested_features & HV_X64_ENLIGHTENED_VMCS_VERSION) >=
> - KVM_EVMCS_VERSION) {
> -
> - /* Check that we have assist pages on all online CPUs */
> - for_each_online_cpu(cpu) {
> - if (!hv_get_vp_assist_page(cpu)) {
> - enlightened_vmcs = false;
> - break;
> - }
> - }
> -
> - if (enlightened_vmcs) {
> - pr_info("KVM: vmx: using Hyper-V Enlightened VMCS\n");
> - static_branch_enable(&enable_evmcs);
> - }
> -
> - if (ms_hyperv.nested_features & HV_X64_NESTED_DIRECT_FLUSH)
> - vmx_x86_ops.enable_l2_tlb_flush
> - = hv_enable_l2_tlb_flush;
> -
> - } else {
> - enlightened_vmcs = false;
> - }
> -#endif
> + hv_init_evmcs();
>
> r = kvm_init(&vmx_init_ops, sizeof(struct vcpu_vmx),
>__alignof__(struct vcpu_vmx), THIS_MODULE);
Reviewed-by: Vitaly Kuznetsov
--
Vitaly
Re: [PATCH v8 3/3] ASoC: SOF: Fix deadlock when shutdown a frozen userspace
On Thu, 01 Dec 2022 14:22:12 +0100,
Oliver Neukum wrote:
>
> On 01.12.22 14:03, Ricardo Ribalda wrote:
>
> Hi,
>
> > This patchset does not modify this behaviour. It simply fixes the
> > stall for kexec().
> >
> > The patch that introduced the stall:
> > 83bfc7e793b5 ("ASoC: SOF: core: unregister clients and machine drivers
> > in .shutdown")
>
> That patch is problematic. I would go as far as saying that
> it needs to be reverted.
... or fixed.
> > was sent as a generalised version of:
> > https://github.com/thesofproject/linux/pull/3388
> >
> > AFAIK, we would need a similar patch for every single board which
> > I am not sure it is doable in a reasonable timeframe.
> >
> > On the meantime this seems like a decent compromises. Yes, a
> > miss-behaving userspace can still stall during suspend, but that was
> > not introduced in this patch.
>
> Well, I mean if you know what wrong then I'd say at least return to
> a sanely broken state.
>
> The whole approach is wrong. You need to be able to deal with user
> space talking to removed devices by returning an error and keeping
> the resources association with the open file allocated until
> user space calls close()
As I already mentioned in another thread, if the user-space action has
to be cut off, we just need to call snd_card_disconnect() instead
without sync. A quick hack would be like below (totally untested and
might be wrong, though).
In anyway, Ricardo, please stop spinning too frequently; v8 in a few
days is way too much, and now the recipient list became unmanageable.
Let's give people some time to review and consider a better solution
at first.
thanks,
Takashi
-- 8< --
--- a/sound/soc/sof/core.c
+++ b/sound/soc/sof/core.c
@@ -475,7 +475,7 @@ EXPORT_SYMBOL(snd_sof_device_remove);
int snd_sof_device_shutdown(struct device *dev)
{
struct snd_sof_dev *sdev = dev_get_drvdata(dev);
- struct snd_sof_pdata *pdata = sdev->pdata;
+ struct snd_soc_component *component;
if (IS_ENABLED(CONFIG_SND_SOC_SOF_PROBE_WORK_QUEUE))
cancel_work_sync(&sdev->probe_work);
@@ -484,9 +484,9 @@ int snd_sof_device_shutdown(struct device *dev)
* make sure clients and machine driver(s) are unregistered to force
* all userspace devices to be closed prior to the DSP shutdown sequence
*/
- sof_unregister_clients(sdev);
-
- snd_sof_machine_unregister(sdev, pdata);
+ component = snd_soc_lookup_component(sdev->dev, NULL);
+ if (component && component->card && component->card->snd_card)
+ snd_card_disconnect(component->card->snd_card);
if (sdev->fw_state == SOF_FW_BOOT_COMPLETE)
return snd_sof_shutdown(sdev);
Re: [PATCH 5/5] powerpc: dts: remove label = "cpu" from DSA dt-binding
Arınç ÜNAL writes:
> This is not used by the DSA dt-binding, so remove it from all devicetrees.
>
> Signed-off-by: Arınç ÜNAL
> ---
> arch/powerpc/boot/dts/turris1x.dts | 2 --
> 1 file changed, 2 deletions(-)
Adding Pali to Cc.
These were only recently updated in commit:
8bf056f57f1d ("powerpc: dts: turris1x.dts: Fix labels in DSA cpu port nodes")
Which said:
DSA cpu port node has to be marked with "cpu" label.
But if the binding doesn't use them then I'm confused why they needed to
be updated.
cheers
> diff --git a/arch/powerpc/boot/dts/turris1x.dts
> b/arch/powerpc/boot/dts/turris1x.dts
> index 045af668e928..3841c8d96d00 100644
> --- a/arch/powerpc/boot/dts/turris1x.dts
> +++ b/arch/powerpc/boot/dts/turris1x.dts
> @@ -147,7 +147,6 @@ ports {
>
> port@0 {
> reg = <0>;
> - label = "cpu";
> ethernet = <&enet1>;
> phy-mode = "rgmii-id";
>
> @@ -184,7 +183,6 @@ port@5 {
>
> port@6 {
> reg = <6>;
> - label = "cpu";
> ethernet = <&enet0>;
> phy-mode = "rgmii-id";
>
> --
> 2.34.1
Re: [PATCH 0/5] remove label = "cpu" from DSA dt-binding
I'm sending a more specific mail to make sure this series doesn't fall through the cracks like Andrew said. I'd like this merged this week before the merge window closes. Jakub, please take patch 1. Arnd, please take patch 2 and 3. Thomas, please take patch 4. Michael, please take patch 5. Arınç On 30.11.2022 17:10, Arınç ÜNAL wrote: Hello folks, With this patch series, we're completely getting rid of 'label = "cpu";' which is not used by the DSA dt-binding at all. Information for taking the patches for maintainers: Patch 1: netdev maintainers (based off netdev/net-next.git main) Patch 2-3: SoC maintainers (based off soc/soc.git soc/dt) Patch 4: MIPS maintainers (based off mips/linux.git mips-next) Patch 5: PowerPC maintainers (based off powerpc/linux.git next-test) I've been meaning to submit this for a few months. Find the relevant conversation here: https://lore.kernel.org/netdev/20220913155408.ga3802998-r...@kernel.org/ Here's how I did it, for the interested (or suggestions): Find the platforms which have got 'label = "cpu";' defined. grep -rnw . -e 'label = "cpu";' Remove the line where 'label = "cpu";' is included. sed -i /'label = "cpu";'/,+d arch/arm/boot/dts/* sed -i /'label = "cpu";'/,+d arch/arm64/boot/dts/freescale/* sed -i /'label = "cpu";'/,+d arch/arm64/boot/dts/marvell/* sed -i /'label = "cpu";'/,+d arch/arm64/boot/dts/mediatek/* sed -i /'label = "cpu";'/,+d arch/arm64/boot/dts/rockchip/* sed -i /'label = "cpu";'/,+d arch/mips/boot/dts/qca/* sed -i /'label = "cpu";'/,+d arch/mips/boot/dts/ralink/* sed -i /'label = "cpu";'/,+d arch/powerpc/boot/dts/turris1x.dts sed -i /'label = "cpu";'/,+d Documentation/devicetree/bindings/net/qca,ar71xx.yaml Restore the symlink files which typechange after running sed. Arınç ÜNAL (5): dt-bindings: net: qca,ar71xx: remove label = "cpu" from examples arm: dts: remove label = "cpu" from DSA dt-binding arm64: dts: remove label = "cpu" from DSA dt-binding mips: dts: remove label = "cpu" from DSA dt-binding powerpc: dts: remove label = "cpu" from DSA dt-binding
[PATCH v1 04/10] powerpc/bpf/32: Only set a stack frame when necessary
Until now a stack frame was set at all time due to the need
to keep tail call counter in the stack.
But since commit fa025537f584 ("powerpc/bpf/32: Fix Oops on tail call
tests"), the tail call counter is passed via register r4. It is
therefore not necessary anymore to have a stack frame for that.
Just like PPC64, implement bpf_has_stack_frame() and only sets the frame
when needed.
The difference with PPC64 is that PPC32 doesn't have a redzone, so
the stack is required as soon as non volatile registers are used or
when tail call count is set up.
Signed-off-by: Christophe Leroy
---
arch/powerpc/net/bpf_jit_comp32.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/net/bpf_jit_comp32.c
b/arch/powerpc/net/bpf_jit_comp32.c
index 4e6caee9c98a..7f54d37bede6 100644
--- a/arch/powerpc/net/bpf_jit_comp32.c
+++ b/arch/powerpc/net/bpf_jit_comp32.c
@@ -79,6 +79,20 @@ static int bpf_jit_stack_offsetof(struct codegen_context
*ctx, int reg)
#define SEEN_NVREG_FULL_MASK 0x0003 /* Non volatile registers r14-r31 */
#define SEEN_NVREG_TEMP_MASK 0x1e01 /* BPF_REG_5, BPF_REG_AX, TMP_REG */
+static inline bool bpf_has_stack_frame(struct codegen_context *ctx)
+{
+ /*
+* We only need a stack frame if:
+* - we call other functions (kernel helpers), or
+* - we use non volatile registers, or
+* - we use tail call counter
+* - the bpf program uses its stack area
+* The latter condition is deduced from the usage of BPF_REG_FP
+*/
+ return ctx->seen & (SEEN_FUNC | SEEN_TAILCALL | SEEN_NVREG_FULL_MASK) ||
+ bpf_is_seen_register(ctx, bpf_to_ppc(BPF_REG_FP));
+}
+
void bpf_jit_realloc_regs(struct codegen_context *ctx)
{
unsigned int nvreg_mask;
@@ -121,7 +135,8 @@ void bpf_jit_build_prologue(u32 *image, struct
codegen_context *ctx)
#define BPF_TAILCALL_PROLOGUE_SIZE 4
- EMIT(PPC_RAW_STWU(_R1, _R1, -BPF_PPC_STACKFRAME(ctx)));
+ if (bpf_has_stack_frame(ctx))
+ EMIT(PPC_RAW_STWU(_R1, _R1, -BPF_PPC_STACKFRAME(ctx)));
if (ctx->seen & SEEN_TAILCALL)
EMIT(PPC_RAW_STW(_R4, _R1, bpf_jit_stack_offsetof(ctx,
BPF_PPC_TC)));
@@ -174,7 +189,8 @@ static void bpf_jit_emit_common_epilogue(u32 *image, struct
codegen_context *ctx
EMIT(PPC_RAW_LWZ(_R0, _R1, BPF_PPC_STACKFRAME(ctx) +
PPC_LR_STKOFF));
/* Tear down our stack frame */
- EMIT(PPC_RAW_ADDI(_R1, _R1, BPF_PPC_STACKFRAME(ctx)));
+ if (bpf_has_stack_frame(ctx))
+ EMIT(PPC_RAW_ADDI(_R1, _R1, BPF_PPC_STACKFRAME(ctx)));
if (ctx->seen & SEEN_FUNC)
EMIT(PPC_RAW_MTLR(_R0));
--
2.38.1
[PATCH v1 10/10] powerpc/bpf/32: perform three operands ALU operations
When an ALU instruction is preceded by a MOV instruction
that just moves a source register into the destination register of
the ALU, replace that MOV+ALU instructions by an ALU operation
taking the source of the MOV as second source instead of using its
destination.
Before the change, code could look like the following, with
superfluous separate register move (mr) instructions.
70: 7f c6 f3 78 mr r6,r30
74: 7f a5 eb 78 mr r5,r29
78: 30 c6 ff f4 addic r6,r6,-12
7c: 7c a5 01 d4 addme r5,r5
With this commit, addition instructions take r30 and r29 directly.
70: 30 de ff f4 addic r6,r30,-12
74: 7c bd 01 d4 addme r5,r29
Signed-off-by: Christophe Leroy
---
arch/powerpc/net/bpf_jit_comp32.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/powerpc/net/bpf_jit_comp32.c
b/arch/powerpc/net/bpf_jit_comp32.c
index c45db3d280b2..4b8d3634dc04 100644
--- a/arch/powerpc/net/bpf_jit_comp32.c
+++ b/arch/powerpc/net/bpf_jit_comp32.c
@@ -290,6 +290,7 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image,
struct codegen_context *
for (i = 0; i < flen; i++) {
u32 code = insn[i].code;
+ u32 prevcode = i ? insn[i - 1].code : 0;
u32 dst_reg = bpf_to_ppc(insn[i].dst_reg);
u32 dst_reg_h = dst_reg - 1;
u32 src_reg = bpf_to_ppc(insn[i].src_reg);
@@ -308,6 +309,15 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image,
struct codegen_context *
u32 tmp_idx;
int j;
+ if (i && (BPF_CLASS(code) == BPF_ALU64 || BPF_CLASS(code) ==
BPF_ALU) &&
+ (BPF_CLASS(prevcode) == BPF_ALU64 || BPF_CLASS(prevcode) ==
BPF_ALU) &&
+ BPF_OP(prevcode) == BPF_MOV && BPF_SRC(prevcode) == BPF_X &&
+ insn[i - 1].dst_reg == insn[i].dst_reg && insn[i - 1].imm
!= 1) {
+ src2_reg = bpf_to_ppc(insn[i - 1].src_reg);
+ src2_reg_h = src2_reg - 1;
+ ctx->idx = addrs[i - 1] / 4;
+ }
+
/*
* addrs[] maps a BPF bytecode address into a real offset from
* the start of the body code.
--
2.38.1
[PATCH v1 06/10] powerpc/bpf: Perform complete extra passes to update addresses
BPF core calls the jit compiler again for an extra pass in order
to properly set subprog addresses.
Unlike other architectures, powerpc only updates the addresses
during that extra pass. It means that holes must have been left
in the code in order to enable the maximum possible instruction
size.
In order avoid waste of space, and waste of CPU time on powerpc
processors on which the NOP instruction is not 0-cycle, perform
two real additional passes.
Signed-off-by: Christophe Leroy
---
arch/powerpc/net/bpf_jit_comp.c | 85 -
1 file changed, 85 deletions(-)
diff --git a/arch/powerpc/net/bpf_jit_comp.c b/arch/powerpc/net/bpf_jit_comp.c
index 43e634126514..8833bf23f5aa 100644
--- a/arch/powerpc/net/bpf_jit_comp.c
+++ b/arch/powerpc/net/bpf_jit_comp.c
@@ -23,74 +23,6 @@ static void bpf_jit_fill_ill_insns(void *area, unsigned int
size)
memset32(area, BREAKPOINT_INSTRUCTION, size / 4);
}
-/* Fix updated addresses (for subprog calls, ldimm64, et al) during extra pass
*/
-static int bpf_jit_fixup_addresses(struct bpf_prog *fp, u32 *image,
- struct codegen_context *ctx, u32 *addrs)
-{
- const struct bpf_insn *insn = fp->insnsi;
- bool func_addr_fixed;
- u64 func_addr;
- u32 tmp_idx;
- int i, j, ret;
-
- for (i = 0; i < fp->len; i++) {
- /*
-* During the extra pass, only the branch target addresses for
-* the subprog calls need to be fixed. All other instructions
-* can left untouched.
-*
-* The JITed image length does not change because we already
-* ensure that the JITed instruction sequence for these calls
-* are of fixed length by padding them with NOPs.
-*/
- if (insn[i].code == (BPF_JMP | BPF_CALL) &&
- insn[i].src_reg == BPF_PSEUDO_CALL) {
- ret = bpf_jit_get_func_addr(fp, &insn[i], true,
- &func_addr,
- &func_addr_fixed);
- if (ret < 0)
- return ret;
-
- /*
-* Save ctx->idx as this would currently point to the
-* end of the JITed image and set it to the offset of
-* the instruction sequence corresponding to the
-* subprog call temporarily.
-*/
- tmp_idx = ctx->idx;
- ctx->idx = addrs[i] / 4;
- ret = bpf_jit_emit_func_call_rel(image, ctx, func_addr);
- if (ret)
- return ret;
-
- /*
-* Restore ctx->idx here. This is safe as the length
-* of the JITed sequence remains unchanged.
-*/
- ctx->idx = tmp_idx;
- } else if (insn[i].code == (BPF_LD | BPF_IMM | BPF_DW)) {
- tmp_idx = ctx->idx;
- ctx->idx = addrs[i] / 4;
-#ifdef CONFIG_PPC32
- PPC_LI32(bpf_to_ppc(insn[i].dst_reg) - 1, (u32)insn[i +
1].imm);
- PPC_LI32(bpf_to_ppc(insn[i].dst_reg), (u32)insn[i].imm);
- for (j = ctx->idx - addrs[i] / 4; j < 4; j++)
- EMIT(PPC_RAW_NOP());
-#else
- func_addr = ((u64)(u32)insn[i].imm) |
(((u64)(u32)insn[i + 1].imm) << 32);
- PPC_LI64(bpf_to_ppc(insn[i].dst_reg), func_addr);
- /* overwrite rest with nops */
- for (j = ctx->idx - addrs[i] / 4; j < 5; j++)
- EMIT(PPC_RAW_NOP());
-#endif
- ctx->idx = tmp_idx;
- i++;
- }
- }
-
- return 0;
-}
-
int bpf_jit_emit_exit_insn(u32 *image, struct codegen_context *ctx, int
tmp_reg, long exit_addr)
{
if (!exit_addr || is_offset_in_branch_range(exit_addr - (ctx->idx *
4))) {
@@ -234,22 +166,6 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *fp)
skip_init_ctx:
code_base = (u32 *)(image + FUNCTION_DESCR_SIZE);
- if (extra_pass) {
- /*
-* Do not touch the prologue and epilogue as they will remain
-* unchanged. Only fix the branch target address for subprog
-* calls in the body, and ldimm64 instructions.
-*
-* This does not change the offsets and lengths of the subprog
-* call instruction sequences and hence, the size of the JITed
-* image as well.
-*/
- bpf_jit_fixup_addresses(fp, code_base, &cgctx, addrs);
-
- /* There is no nee
[PATCH v1 08/10] powerpc/bpf/32: Optimise some particular const operations
Simplify multiplications and divisions with constants when the
constant is 1 or -1.
When the constant is a power of 2, replace them by bit shits.
Signed-off-by: Christophe Leroy
---
arch/powerpc/net/bpf_jit_comp32.c | 23 ---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/net/bpf_jit_comp32.c
b/arch/powerpc/net/bpf_jit_comp32.c
index 6c45d953d4e8..e6e156c0c5d6 100644
--- a/arch/powerpc/net/bpf_jit_comp32.c
+++ b/arch/powerpc/net/bpf_jit_comp32.c
@@ -391,7 +391,13 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image,
struct codegen_context *
EMIT(PPC_RAW_MULW(dst_reg, dst_reg, src_reg));
break;
case BPF_ALU | BPF_MUL | BPF_K: /* (u32) dst *= (u32) imm */
- if (imm >= -32768 && imm < 32768) {
+ if (imm == 1)
+ break;
+ if (imm == -1) {
+ EMIT(PPC_RAW_SUBFIC(dst_reg, dst_reg, 0));
+ } else if (is_power_of_2((u32)imm)) {
+ EMIT(PPC_RAW_SLWI(dst_reg, dst_reg,
ilog2(imm)));
+ } else if (imm >= -32768 && imm < 32768) {
EMIT(PPC_RAW_MULI(dst_reg, dst_reg, imm));
} else {
PPC_LI32(_R0, imm);
@@ -411,6 +417,13 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image,
struct codegen_context *
EMIT(PPC_RAW_SUBFZE(dst_reg_h, dst_reg_h));
break;
}
+ if (imm > 0 && is_power_of_2(imm)) {
+ imm = ilog2(imm);
+ EMIT(PPC_RAW_RLWINM(dst_reg_h, dst_reg_h, imm,
0, 31 - imm));
+ EMIT(PPC_RAW_RLWIMI(dst_reg_h, dst_reg, imm, 32
- imm, 31));
+ EMIT(PPC_RAW_SLWI(dst_reg, dst_reg, imm));
+ break;
+ }
bpf_set_seen_register(ctx, tmp_reg);
PPC_LI32(tmp_reg, imm);
EMIT(PPC_RAW_MULW(dst_reg_h, dst_reg_h, tmp_reg));
@@ -438,8 +451,12 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image,
struct codegen_context *
if (imm == 1)
break;
- PPC_LI32(_R0, imm);
- EMIT(PPC_RAW_DIVWU(dst_reg, dst_reg, _R0));
+ if (is_power_of_2((u32)imm)) {
+ EMIT(PPC_RAW_SRWI(dst_reg, dst_reg,
ilog2(imm)));
+ } else {
+ PPC_LI32(_R0, imm);
+ EMIT(PPC_RAW_DIVWU(dst_reg, dst_reg, _R0));
+ }
break;
case BPF_ALU | BPF_MOD | BPF_K: /* (u32) dst %= (u32) imm */
if (!imm)
--
2.38.1
[PATCH v1 09/10] powerpc/bpf/32: introduce a second source register for ALU operations
At the time being, all ALU operation are performed with same L-source
and destination, requiring the L-source to be moved into destination via
a separate register move, like:
70: 7f c6 f3 78 mr r6,r30
74: 7f a5 eb 78 mr r5,r29
78: 30 c6 ff f4 addic r6,r6,-12
7c: 7c a5 01 d4 addme r5,r5
Introduce a second source register to all ALU operations. For the time
being that second source register is made equal to the destination
register.
That change will allow, via following patch, to optimise the generated
code as:
70: 30 de ff f4 addic r6,r30,-12
74: 7c bd 01 d4 addme r5,r29
Signed-off-by: Christophe Leroy
---
arch/powerpc/net/bpf_jit_comp32.c | 350 --
1 file changed, 183 insertions(+), 167 deletions(-)
diff --git a/arch/powerpc/net/bpf_jit_comp32.c
b/arch/powerpc/net/bpf_jit_comp32.c
index e6e156c0c5d6..c45db3d280b2 100644
--- a/arch/powerpc/net/bpf_jit_comp32.c
+++ b/arch/powerpc/net/bpf_jit_comp32.c
@@ -294,6 +294,8 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image,
struct codegen_context *
u32 dst_reg_h = dst_reg - 1;
u32 src_reg = bpf_to_ppc(insn[i].src_reg);
u32 src_reg_h = src_reg - 1;
+ u32 src2_reg = dst_reg;
+ u32 src2_reg_h = dst_reg_h;
u32 ax_reg = bpf_to_ppc(BPF_REG_AX);
u32 tmp_reg = bpf_to_ppc(TMP_REG);
u32 size = BPF_SIZE(code);
@@ -338,108 +340,111 @@ int bpf_jit_build_body(struct bpf_prog *fp, u32 *image,
struct codegen_context *
* Arithmetic operations: ADD/SUB/MUL/DIV/MOD/NEG
*/
case BPF_ALU | BPF_ADD | BPF_X: /* (u32) dst += (u32) src */
- EMIT(PPC_RAW_ADD(dst_reg, dst_reg, src_reg));
+ EMIT(PPC_RAW_ADD(dst_reg, src2_reg, src_reg));
break;
case BPF_ALU64 | BPF_ADD | BPF_X: /* dst += src */
- EMIT(PPC_RAW_ADDC(dst_reg, dst_reg, src_reg));
- EMIT(PPC_RAW_ADDE(dst_reg_h, dst_reg_h, src_reg_h));
+ EMIT(PPC_RAW_ADDC(dst_reg, src2_reg, src_reg));
+ EMIT(PPC_RAW_ADDE(dst_reg_h, src2_reg_h, src_reg_h));
break;
case BPF_ALU | BPF_SUB | BPF_X: /* (u32) dst -= (u32) src */
- EMIT(PPC_RAW_SUB(dst_reg, dst_reg, src_reg));
+ EMIT(PPC_RAW_SUB(dst_reg, src2_reg, src_reg));
break;
case BPF_ALU64 | BPF_SUB | BPF_X: /* dst -= src */
- EMIT(PPC_RAW_SUBFC(dst_reg, src_reg, dst_reg));
- EMIT(PPC_RAW_SUBFE(dst_reg_h, src_reg_h, dst_reg_h));
+ EMIT(PPC_RAW_SUBFC(dst_reg, src_reg, src2_reg));
+ EMIT(PPC_RAW_SUBFE(dst_reg_h, src_reg_h, src2_reg_h));
break;
case BPF_ALU | BPF_SUB | BPF_K: /* (u32) dst -= (u32) imm */
imm = -imm;
fallthrough;
case BPF_ALU | BPF_ADD | BPF_K: /* (u32) dst += (u32) imm */
- if (IMM_HA(imm) & 0x)
- EMIT(PPC_RAW_ADDIS(dst_reg, dst_reg,
IMM_HA(imm)));
+ if (!imm) {
+ EMIT(PPC_RAW_MR(dst_reg, src2_reg));
+ } else if (IMM_HA(imm) & 0x) {
+ EMIT(PPC_RAW_ADDIS(dst_reg, src2_reg,
IMM_HA(imm)));
+ src2_reg = dst_reg;
+ }
if (IMM_L(imm))
- EMIT(PPC_RAW_ADDI(dst_reg, dst_reg,
IMM_L(imm)));
+ EMIT(PPC_RAW_ADDI(dst_reg, src2_reg,
IMM_L(imm)));
break;
case BPF_ALU64 | BPF_SUB | BPF_K: /* dst -= imm */
imm = -imm;
fallthrough;
case BPF_ALU64 | BPF_ADD | BPF_K: /* dst += imm */
- if (!imm)
+ if (!imm) {
+ EMIT(PPC_RAW_MR(dst_reg, src2_reg));
+ EMIT(PPC_RAW_MR(dst_reg_h, src2_reg_h));
break;
-
+ }
if (imm >= -32768 && imm < 32768) {
- EMIT(PPC_RAW_ADDIC(dst_reg, dst_reg, imm));
+ EMIT(PPC_RAW_ADDIC(dst_reg, src2_reg, imm));
} else {
PPC_LI32(_R0, imm);
- EMIT(PPC_RAW_ADDC(dst_reg, dst_reg, _R0));
+ EMIT(PPC_RAW_ADDC(dst_reg, src2_reg, _R0));
}
if (imm >= 0 || (BPF_OP(code) == BPF_SUB && imm ==
0x8000))
- EMIT(P
