* Re: [PATCH v2 2/2] KVM: PPC: Book3S PR: Disallow AIL != 0
From: Fabiano Rosas @ 2022-01-31 17:30 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20220129072511.105523-3-npiggin@gmail.com>
Nicholas Piggin <npiggin@gmail.com> writes:
> KVM PR does not implement address translation modes on interrupt, so it
> must not allow H_SET_MODE to succeed. The behaviour change caused by
> this mode is architected and not advisory (interrupts *must* behave
> differently).
>
> QEMU does not deal with differences in AIL support in the host. The
> solution to that is a spapr capability and corresponding KVM CAP, but
> this patch does not break things more than before (the host behaviour
> already differs, this change just disallows some modes that are not
> implemented properly).
>
> By happy coincidence, this allows PR Linux guests that are using the SCV
> facility to boot and run, because Linux disables the use of SCV if AIL
> can not be set to 3. This does not fix the underlying problem of missing
> SCV support (an OS could implement real-mode SCV vectors and try to
> enable the facility). The true fix for that is for KVM PR to emulate scv
> interrupts from the facility unavailable interrupt.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Fabiano Rosas <farosas@linux.ibm.com>
> ---
> arch/powerpc/kvm/book3s_pr_papr.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/powerpc/kvm/book3s_pr_papr.c b/arch/powerpc/kvm/book3s_pr_papr.c
> index 1f10e7dfcdd0..dc4f51ac84bc 100644
> --- a/arch/powerpc/kvm/book3s_pr_papr.c
> +++ b/arch/powerpc/kvm/book3s_pr_papr.c
> @@ -281,6 +281,22 @@ static int kvmppc_h_pr_logical_ci_store(struct kvm_vcpu *vcpu)
> return EMULATE_DONE;
> }
>
> +static int kvmppc_h_pr_set_mode(struct kvm_vcpu *vcpu)
> +{
> + unsigned long mflags = kvmppc_get_gpr(vcpu, 4);
> + unsigned long resource = kvmppc_get_gpr(vcpu, 5);
> +
> + if (resource == H_SET_MODE_RESOURCE_ADDR_TRANS_MODE) {
> + /* KVM PR does not provide AIL!=0 to guests */
> + if (mflags == 0)
> + kvmppc_set_gpr(vcpu, 3, H_SUCCESS);
> + else
> + kvmppc_set_gpr(vcpu, 3, H_UNSUPPORTED_FLAG_START - 63);
> + return EMULATE_DONE;
> + }
> + return EMULATE_FAIL;
> +}
> +
> #ifdef CONFIG_SPAPR_TCE_IOMMU
> static int kvmppc_h_pr_put_tce(struct kvm_vcpu *vcpu)
> {
> @@ -384,6 +400,8 @@ int kvmppc_h_pr(struct kvm_vcpu *vcpu, unsigned long cmd)
> return kvmppc_h_pr_logical_ci_load(vcpu);
> case H_LOGICAL_CI_STORE:
> return kvmppc_h_pr_logical_ci_store(vcpu);
> + case H_SET_MODE:
> + return kvmppc_h_pr_set_mode(vcpu);
> case H_XIRR:
> case H_CPPR:
> case H_EOI:
> @@ -421,6 +439,7 @@ int kvmppc_hcall_impl_pr(unsigned long cmd)
> case H_CEDE:
> case H_LOGICAL_CI_LOAD:
> case H_LOGICAL_CI_STORE:
> + case H_SET_MODE:
> #ifdef CONFIG_KVM_XICS
> case H_XIRR:
> case H_CPPR:
> @@ -447,6 +466,7 @@ static unsigned int default_hcall_list[] = {
> H_BULK_REMOVE,
> H_PUT_TCE,
> H_CEDE,
> + H_SET_MODE,
> #ifdef CONFIG_KVM_XICS
> H_XIRR,
> H_CPPR,
^ permalink raw reply
* Re: [PATCH v2 1/2] KVM: PPC: Book3S PR: Disable SCV when AIL could be disabled
From: Fabiano Rosas @ 2022-01-31 17:34 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20220129072511.105523-2-npiggin@gmail.com>
Nicholas Piggin <npiggin@gmail.com> writes:
> PR KVM does not support running with AIL enabled, and SCV does is not
> supported with AIL disabled. Fix this by ensuring the SCV facility is
> disabled with FSCR while a CPU could be running with AIL=0.
>
> The PowerNV host supports disabling AIL on a per-CPU basis, so SCV just
> needs to be disabled when a vCPU is being run.
>
> The pSeries machine can only switch AIL on a system-wide basis, so it
> must disable SCV support at boot if the configuration can potentially
> run a PR KVM guest.
>
> Also ensure a the FSCR[SCV] bit can not be enabled when emulating
> mtFSCR for the guest.
>
> SCV is not emulated for the PR guest at the moment, this just fixes the
> host crashes.
>
> Alternatives considered and rejected:
> - SCV support can not be disabled by PR KVM after boot, because it is
> advertised to userspace with HWCAP.
> - AIL can not be disabled on a per-CPU basis. At least when running on
> pseries it is a per-LPAR setting.
> - Support for real-mode SCV vectors will not be added because they are
> at 0x17000 so making such a large fixed head space causes immediate
> value limits to be exceeded, requiring a lot rework and more code.
> - Disabling SCV for any PR KVM possible kernel will cause a slowdown
> when not using PR KVM.
> - A boot time option to disable SCV to use PR KVM is user-hostile.
> - System call instruction emulation for SCV facility unavailable
> instructions is too complex and old emulation code was subtly broken
> and removed.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/powerpc/kernel/exceptions-64s.S | 4 ++++
> arch/powerpc/kernel/setup_64.c | 28 ++++++++++++++++++++++++++++
> arch/powerpc/kvm/Kconfig | 9 +++++++++
> arch/powerpc/kvm/book3s_pr.c | 20 ++++++++++++++------
> 4 files changed, 55 insertions(+), 6 deletions(-)
>
> diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
> index 55caeee37c08..b66dd6f775a4 100644
> --- a/arch/powerpc/kernel/exceptions-64s.S
> +++ b/arch/powerpc/kernel/exceptions-64s.S
> @@ -809,6 +809,10 @@ __start_interrupts:
> * - MSR_EE|MSR_RI is clear (no reentrant exceptions)
> * - Standard kernel environment is set up (stack, paca, etc)
> *
> + * KVM:
> + * These interrupts do not elevate HV 0->1, so HV is not involved. PR KVM
> + * ensures that FSCR[SCV] is disabled whenever it has to force AIL off.
> + *
> * Call convention:
> *
> * syscall register convention is in Documentation/powerpc/syscall64-abi.rst
> diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
> index be8577ac9397..7f7da641e551 100644
> --- a/arch/powerpc/kernel/setup_64.c
> +++ b/arch/powerpc/kernel/setup_64.c
> @@ -197,6 +197,34 @@ static void __init configure_exceptions(void)
>
> /* Under a PAPR hypervisor, we need hypercalls */
> if (firmware_has_feature(FW_FEATURE_SET_MODE)) {
> + /*
> + * - PR KVM does not support AIL mode interrupts in the host
> + * while a PR guest is running.
> + *
> + * - SCV system call interrupt vectors are only implemented for
> + * AIL mode interrupts.
> + *
> + * - On pseries, AIL mode can only be enabled and disabled
> + * system-wide so when a PR VM is created on a pseries host,
> + * all CPUs of the host are set to AIL=0 mode.
> + *
> + * - Therefore host CPUs must not execute scv while a PR VM
> + * exists.
> + *
> + * - SCV support can not be disabled dynamically because the
> + * feature is advertised to host userspace. Disabling the
> + * facility and emulating it would be possible but is not
> + * implemented.
> + *
> + * - So SCV support is blanket diabled if PR KVM could possibly
disabled
Reviewed-by: Fabiano Rosas <farosas@linux.ibm.com>
^ permalink raw reply
* Re: [patch V3 28/35] PCI/MSI: Simplify pci_irq_get_affinity()
From: Thomas Gleixner @ 2022-01-31 21:16 UTC (permalink / raw)
To: Guenter Roeck
Cc: Nishanth Menon, Mark Rutland, Stuart Yoder, linux-pci,
Will Deacon, Peter Ujfalusi, Ashok Raj, Jassi Brar, Sinan Kaya,
Vinod Koul, Bjorn Helgaas, Megha Dey, Jason Gunthorpe, xen-devel,
Kevin Tian, Arnd Bergmann, linuxppc-dev, Alex Williamson,
Cedric Le Goater, Santosh Shilimkar, Bjorn Helgaas,
linux-arm-kernel, Juergen Gross, Tero Kristo, Greg Kroah-Hartman,
LKML, iommu, Marc Zygnier, dmaengine, Robin Murphy
In-Reply-To: <c78df469-1a9f-5778-24d1-8f08a6bf5bcc@roeck-us.net>
Guenter,
On Mon, Jan 31 2022 at 07:21, Guenter Roeck wrote:
> Sure. Please see http://server.roeck-us.net/qemu/x86/.
> The logs are generated with with v5.16.4.
thanks for providing the data. It definitely helped me to leave the
state of not seeing the wood for the trees. Fix below.
Thanks,
tglx
---
Subject: PCI/MSI: Remove bogus warning in pci_irq_get_affinity()
From: Thomas Gleixner <tglx@linutronix.de>
Date: Mon, 31 Jan 2022 22:02:46 +0100
The recent overhaul of pci_irq_get_affinity() introduced a regression when
pci_irq_get_affinity() is called for an MSI-X interrupt which was not
allocated with affinity descriptor information.
The original code just returned a NULL pointer in that case, but the rework
added a WARN_ON() under the assumption that the corresponding WARN_ON() in
the MSI case can be applied to MSI-X as well.
In fact the MSI warning in the original code does not make sense either
because it's legitimate to invoke pci_irq_get_affinity() for a MSI
interrupt which was not allocated with affinity descriptor information.
Remove it and just return NULL as the original code did.
Fixes: f48235900182 ("PCI/MSI: Simplify pci_irq_get_affinity()")
Reported-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
drivers/pci/msi/msi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/pci/msi/msi.c
+++ b/drivers/pci/msi/msi.c
@@ -1111,7 +1111,8 @@ const struct cpumask *pci_irq_get_affini
if (!desc)
return cpu_possible_mask;
- if (WARN_ON_ONCE(!desc->affinity))
+ /* MSI[X] interrupts can be allocated without affinity descriptor */
+ if (!desc->affinity)
return NULL;
/*
^ permalink raw reply
* Re: consolidate the compat fcntl definitions v2
From: Arnd Bergmann @ 2022-01-31 22:19 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-arch, linux-s390, Parisc List, Arnd Bergmann,
the arch/x86 maintainers, open list:BROADCOM NVRAM DRIVER,
Linux Kernel Mailing List, Guo Ren, sparclinux, linuxppc-dev,
Linux ARM
In-Reply-To: <20220131064933.3780271-1-hch@lst.de>
On Mon, Jan 31, 2022 at 7:49 AM Christoph Hellwig <hch@lst.de> wrote:
>
> Hi all,
>
> currenty the compat fcnt definitions are duplicate for all compat
> architectures, and the native fcntl64 definitions aren't even usable
> from userspace due to a bogus CONFIG_64BIT ifdef. This series tries
> to sort out all that.
>
> Changes since v1:
> - only make the F*64 defines uapi visible for 32-bit architectures
Looks all good to me,
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
I think it would be best to merge this through the risc-v tree along
with the coming compat support
that depends on it. Alternatively, I can put it into my asm-generic
tree for 5.18.
Arnd
^ permalink raw reply
* Re: [patch V3 28/35] PCI/MSI: Simplify pci_irq_get_affinity()
From: Guenter Roeck @ 2022-01-31 22:29 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Nishanth Menon, Mark Rutland, Stuart Yoder, linux-pci,
Will Deacon, Peter Ujfalusi, Ashok Raj, Jassi Brar, Sinan Kaya,
Vinod Koul, Bjorn Helgaas, Megha Dey, Jason Gunthorpe, xen-devel,
Kevin Tian, Arnd Bergmann, linuxppc-dev, Alex Williamson,
Cedric Le Goater, Santosh Shilimkar, Bjorn Helgaas,
linux-arm-kernel, Juergen Gross, Tero Kristo, Greg Kroah-Hartman,
LKML, iommu, Marc Zygnier, dmaengine, Robin Murphy
On Mon, Jan 31, 2022 at 10:16:41PM +0100, Thomas Gleixner wrote:
> Guenter,
>
> On Mon, Jan 31 2022 at 07:21, Guenter Roeck wrote:
> > Sure. Please see http://server.roeck-us.net/qemu/x86/.
> > The logs are generated with with v5.16.4.
>
> thanks for providing the data. It definitely helped me to leave the
> state of not seeing the wood for the trees. Fix below.
>
> Thanks,
>
> tglx
> ---
> Subject: PCI/MSI: Remove bogus warning in pci_irq_get_affinity()
> From: Thomas Gleixner <tglx@linutronix.de>
> Date: Mon, 31 Jan 2022 22:02:46 +0100
>
> The recent overhaul of pci_irq_get_affinity() introduced a regression when
> pci_irq_get_affinity() is called for an MSI-X interrupt which was not
> allocated with affinity descriptor information.
>
> The original code just returned a NULL pointer in that case, but the rework
> added a WARN_ON() under the assumption that the corresponding WARN_ON() in
> the MSI case can be applied to MSI-X as well.
>
> In fact the MSI warning in the original code does not make sense either
> because it's legitimate to invoke pci_irq_get_affinity() for a MSI
> interrupt which was not allocated with affinity descriptor information.
>
> Remove it and just return NULL as the original code did.
>
> Fixes: f48235900182 ("PCI/MSI: Simplify pci_irq_get_affinity()")
> Reported-by: Guenter Roeck <linux@roeck-us.net>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Guenter
> ---
> drivers/pci/msi/msi.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> --- a/drivers/pci/msi/msi.c
> +++ b/drivers/pci/msi/msi.c
> @@ -1111,7 +1111,8 @@ const struct cpumask *pci_irq_get_affini
> if (!desc)
> return cpu_possible_mask;
>
> - if (WARN_ON_ONCE(!desc->affinity))
> + /* MSI[X] interrupts can be allocated without affinity descriptor */
> + if (!desc->affinity)
> return NULL;
>
> /*
^ permalink raw reply
* [Bug 215389] pagealloc: memory corruption at building glibc-2.33 and running its' testsuite
From: bugzilla-daemon @ 2022-01-31 23:33 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-215389-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=215389
--- Comment #11 from Erhard F. (erhard_f@mailbox.org) ---
(In reply to Christophe Leroy from comment #10)
> I'm wondering whether you could be running out of vmalloc space. I initially
> thought you were using KASAN, but it seems not according to your .config.
Correct, I was not using KASAN. I use it only for testing -rc kernels or when I
am particularly wary. This memory corruption I noticed during regular usage.
Seems running the kernel with slub_debug=FZP page_poison=1 is a good thing. ;)
> Could you try reducing CONFIG_LOWMEM_SIZE to 0x28000000 for instance and see
> if the memory corruption still happens ?
Thanks, that did the trick! With CONFIG_LOWMEM_SIZE=0x28000000 the memory
corruption is gone on VMAP_STACK enabled kernels. Tested it additionally on
current 5.16.4 where this works too.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* Re: [PATCH kernel] powerpc/64: Add UADDR64 relocation support
From: Alexey Kardashevskiy @ 2022-02-01 0:25 UTC (permalink / raw)
To: Christophe Leroy, linuxppc-dev@lists.ozlabs.org
Cc: Alan Modra, Paul Mackerras, Nicholas Piggin
In-Reply-To: <07a92a00-cd74-ae19-0e84-25e3afb17cae@csgroup.eu>
On 1/31/22 17:38, Christophe Leroy wrote:
>
>
> Le 31/01/2022 à 05:14, Alexey Kardashevskiy a écrit :
>> When ld detects unaligned relocations, it emits R_PPC64_UADDR64
>> relocations instead of R_PPC64_RELATIVE. Currently R_PPC64_UADDR64 are
>> detected by arch/powerpc/tools/relocs_check.sh and expected not to work.
>> Below is a simple chunk to trigger this behaviour:
>
> According to relocs_check.sh, this is expected to happen only with
> binutils < 2.19. Today minimum binutils version is 2.23
>
> Have you observed this problem with newer version of binutils ?
Oh yeah. 2.36.1. And the toolchain folks explained internally that this
is correct behavior and this was a ticking bomb which exploded now and
the kernel has to deal with it.
>>
>> \#pragma GCC push_options
>> \#pragma GCC optimize ("O0")
>
> AFAIU Linux Kernel is always built with O2
Correct. Even O1 hides this.
> Have you observed the problem with O2 ?
Yes, I see it once I enable CONFIG_PRINTK_INDEX (this is how it was
spotted with my particular config, there is still a fair chance that
this config option does not cause UADDR64 always) but I did not debug
with it enabled as pretty much every single __func__ passed to printk
caused unaligned relocation (tens of thousands). Note that this
particular case can be fixed by removing __packed from "struct pi_entry"
(== re-arm the bomb). Thanks,
>
>
>> struct entry {
>> const char *file;
>> int line;
>> } __attribute__((packed));
>> static const struct entry e1 = { .file = __FILE__, .line = __LINE__ };
>> static const struct entry e2 = { .file = __FILE__, .line = __LINE__ };
>> ...
>> prom_printf("e1=%s %lx %lx\n", e1.file, (unsigned long) e1.file, mfmsr());
>> prom_printf("e2=%s %lx\n", e2.file, (unsigned long) e2.file);
>> \#pragma GCC pop_options
>>
>>
>> This adds support for UADDR64 for 64bit. This reuses __dynamic_symtab
>> from the 32bit which supports more relocation types already.
>>
>> This adds a workaround for the number of relocations as the DT_RELACOUNT
>> ELF Dynamic Array Tag does not include relocations other than
>> R_PPC64_RELATIVE. This instead iterates over the entire .rela.dyn section.
>>
>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>> ---
>>
>> Tested via qemu gdb stub (the kernel is loaded at 0x400000).
>>
>> Disasm:
>>
>> c000000001a804d0 <e1>:
>> c000000001a804d0: b0 04 a8 01 .long 0x1a804b0
>> c000000001a804d0: R_PPC64_RELATIVE *ABS*-0x3ffffffffe57fb50
>> c000000001a804d4: 00 00 00 c0 lfs f0,0(0)
>> c000000001a804d8: fa 08 00 00 .long 0x8fa
>>
>> c000000001a804dc <e2>:
>> ...
>> c000000001a804dc: R_PPC64_UADDR64 .rodata+0x4b0
>>
>> Before relocation:
>>
>>>>> p *(unsigned long *) 0x1e804d0
>> $1 = 0xc000000001a804b0
>>>>> p *(unsigned long *) 0x1e804dc
>> $2 = 0x0
>>
>> After:
>>>>> p *(unsigned long *) 0x1e804d0
>> $1 = 0x1e804b0
>>>>> p *(unsigned long *) 0x1e804dc
>> $2 = 0x1e804b0
>> ---
>> arch/powerpc/kernel/reloc_64.S | 47 +++++++++++++++++++++++++-----
>> arch/powerpc/kernel/vmlinux.lds.S | 3 +-
>> arch/powerpc/tools/relocs_check.sh | 6 ----
>> 3 files changed, 41 insertions(+), 15 deletions(-)
>>
>> diff --git a/arch/powerpc/kernel/reloc_64.S b/arch/powerpc/kernel/reloc_64.S
>> index 02d4719bf43a..a91175723d9d 100644
>> --- a/arch/powerpc/kernel/reloc_64.S
>> +++ b/arch/powerpc/kernel/reloc_64.S
>> @@ -10,6 +10,7 @@
>> RELA = 7
>> RELACOUNT = 0x6ffffff9
>> R_PPC64_RELATIVE = 22
>> +R_PPC64_UADDR64 = 43
>>
>> /*
>> * r3 = desired final address of kernel
>> @@ -25,6 +26,8 @@ _GLOBAL(relocate)
>> add r9,r9,r12 /* r9 has runtime addr of .rela.dyn section */
>> ld r10,(p_st - 0b)(r12)
>> add r10,r10,r12 /* r10 has runtime addr of _stext */
>> + ld r13,(p_sym - 0b)(r12)
>> + add r13,r13,r12 /* r13 has runtime addr of .dynsym */
>>
>> /*
>> * Scan the dynamic section for the RELA and RELACOUNT entries.
>> @@ -46,8 +49,8 @@ _GLOBAL(relocate)
>> b 1b
>> 4: cmpdi r7,0 /* check we have both RELA and RELACOUNT */
>> cmpdi cr1,r8,0
>> - beq 6f
>> - beq cr1,6f
>> + beq 9f
>> + beq cr1,9f
>>
>> /*
>> * Work out linktime address of _stext and hence the
>> @@ -60,25 +63,55 @@ _GLOBAL(relocate)
>> subf r10,r7,r10
>> subf r3,r10,r3 /* final_offset */
>>
>> + /*
>> + * FIXME
>> + * Here r8 is a number of relocations in .rela.dyn.
>> + * When ld issues UADDR64 relocations, they end up at the end
>> + * of the .rela.dyn section. However RELACOUNT does not include
>> + * them so the loop below is going to finish after the last
>> + * R_PPC64_RELATIVE as they normally go first.
>> + * Work out the size of .rela.dyn at compile time.
>> + */
>> + ld r8,(p_rela_end - 0b)(r12)
>> + ld r18,(p_rela - 0b)(r12)
>> + sub r8,r8,r18
>> + li r18,24 /* 24 == sizeof(elf64_rela) */
>> + divd r8,r8,r18
>> +
>> /*
>> * Run through the list of relocations and process the
>> - * R_PPC64_RELATIVE ones.
>> + * R_PPC64_RELATIVE and R_PPC64_UADDR64 ones.
>> */
>> mtctr r8
>> -5: ld r0,8(9) /* ELF64_R_TYPE(reloc->r_info) */
>> +5: lwa r0,8(r9) /* ELF64_R_TYPE(reloc->r_info) */
>> cmpdi r0,R_PPC64_RELATIVE
>> bne 6f
>> ld r6,0(r9) /* reloc->r_offset */
>> ld r0,16(r9) /* reloc->r_addend */
>> - add r0,r0,r3
>> + b 7f
>> +
>> +6: cmpdi r0,R_PPC64_UADDR64
>> + bne 8f
>> + ld r6,0(r9)
>> + ld r0,16(r9)
>> + lwa r14,12(r9) /* ELF64_R_SYM(reloc->r_info) */
>> + mulli r14,r14,24 /* 24 == sizeof(elf64_sym) */
>> + add r14,r14,r13 /* elf64_sym[ELF64_R_SYM] */
>> + ld r14,8(r14)
>> + add r0,r0,r14
>> +
>> +7: add r0,r0,r3
>> stdx r0,r7,r6
>> - addi r9,r9,24
>> +
>> +8: addi r9,r9,24
>> bdnz 5b
>>
>> -6: blr
>> +9: blr
>>
>> .balign 8
>> p_dyn: .8byte __dynamic_start - 0b
>> p_rela: .8byte __rela_dyn_start - 0b
>> +p_rela_end: .8byte __rela_dyn_end - 0b
>> +p_sym: .8byte __dynamic_symtab - 0b
>> p_st: .8byte _stext - 0b
>>
>> diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
>> index 2bcca818136a..e9d9bda3ffaf 100644
>> --- a/arch/powerpc/kernel/vmlinux.lds.S
>> +++ b/arch/powerpc/kernel/vmlinux.lds.S
>> @@ -281,9 +281,7 @@ SECTIONS
>> . = ALIGN(8);
>> .dynsym : AT(ADDR(.dynsym) - LOAD_OFFSET)
>> {
>> -#ifdef CONFIG_PPC32
>> __dynamic_symtab = .;
>> -#endif
>> *(.dynsym)
>> }
>> .dynstr : AT(ADDR(.dynstr) - LOAD_OFFSET) { *(.dynstr) }
>> @@ -299,6 +297,7 @@ SECTIONS
>> {
>> __rela_dyn_start = .;
>> *(.rela*)
>> + __rela_dyn_end = .;
>> }
>> #endif
>> /* .exit.data is discarded at runtime, not link time,
>> diff --git a/arch/powerpc/tools/relocs_check.sh b/arch/powerpc/tools/relocs_check.sh
>> index 014e00e74d2b..956b9e236a60 100755
>> --- a/arch/powerpc/tools/relocs_check.sh
>> +++ b/arch/powerpc/tools/relocs_check.sh
>> @@ -54,9 +54,3 @@ fi
>> num_bad=$(echo "$bad_relocs" | wc -l)
>> echo "WARNING: $num_bad bad relocations"
>> echo "$bad_relocs"
>> -
>> -# If we see this type of relocation it's an idication that
>> -# we /may/ be using an old version of binutils.
>> -if echo "$bad_relocs" | grep -q -F -w R_PPC64_UADDR64; then
>> - echo "WARNING: You need at least binutils >= 2.19 to build a CONFIG_RELOCATABLE kernel"
>> -fi
^ permalink raw reply
* Re: consolidate the compat fcntl definitions v2
From: Guo Ren @ 2022-02-01 1:01 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arch, linux-s390, Parisc List, the arch/x86 maintainers,
open list:BROADCOM NVRAM DRIVER, Linux Kernel Mailing List,
sparclinux, linuxppc-dev, Christoph Hellwig, Linux ARM
In-Reply-To: <CAK8P3a1YzdC1ev0FP-Pe0YyjsY+H3dNWErPGtB=zfcs3kVmkyw@mail.gmail.com>
On Tue, Feb 1, 2022 at 6:19 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Mon, Jan 31, 2022 at 7:49 AM Christoph Hellwig <hch@lst.de> wrote:
> >
> > Hi all,
> >
> > currenty the compat fcnt definitions are duplicate for all compat
> > architectures, and the native fcntl64 definitions aren't even usable
> > from userspace due to a bogus CONFIG_64BIT ifdef. This series tries
> > to sort out all that.
> >
> > Changes since v1:
> > - only make the F*64 defines uapi visible for 32-bit architectures
>
> Looks all good to me,
>
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
>
> I think it would be best to merge this through the risc-v tree along
> with the coming compat support
> that depends on it.
Okay, I would include it in my next version series.
> Alternatively, I can put it into my asm-generic
> tree for 5.18.
>
> Arnd
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
^ permalink raw reply
* Re: [PATCH 1/5] uapi: remove the unused HAVE_ARCH_STRUCT_FLOCK64 define
From: Guo Ren @ 2022-02-01 1:16 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-arch, linux-s390, Arnd Bergmann, Parisc List,
the arch/x86 maintainers, open list:BROADCOM NVRAM DRIVER,
Linux Kernel Mailing List, sparclinux, linuxppc-dev, Linux ARM
In-Reply-To: <20220131064933.3780271-2-hch@lst.de>
This patch should be:
diff --git a/include/uapi/asm-generic/fcntl.h b/include/uapi/asm-generic/fcntl.h
index ecd0f5bdfc1d..220ae6d32e7b 100644
--- a/include/uapi/asm-generic/fcntl.h
+++ b/include/uapi/asm-generic/fcntl.h
@@ -193,32 +193,28 @@ struct f_owner_ex {
#define F_LINUX_SPECIFIC_BASE 1024
#ifndef HAVE_ARCH_STRUCT_FLOCK
-#ifndef __ARCH_FLOCK_PAD
-#define __ARCH_FLOCK_PAD
-#endif
-
struct flock {
short l_type;
short l_whence;
__kernel_off_t l_start;
__kernel_off_t l_len;
__kernel_pid_t l_pid;
+#ifdef __ARCH_FLOCK_PAD
__ARCH_FLOCK_PAD
-};
#endif
-
-#ifndef HAVE_ARCH_STRUCT_FLOCK64
-#ifndef __ARCH_FLOCK64_PAD
-#define __ARCH_FLOCK64_PAD
+}
#endif
+#ifndef HAVE_ARCH_STRUCT_FLOCK64
struct flock64 {
short l_type;
short l_whence;
__kernel_loff_t l_start;
__kernel_loff_t l_len;
__kernel_pid_t l_pid;
+#ifdef __ARCH_FLOCK64_PAD
__ARCH_FLOCK64_PAD
+#endif
};
Right?
Seems you've based on an old tree, right?
On Mon, Jan 31, 2022 at 2:49 PM Christoph Hellwig <hch@lst.de> wrote:
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> include/uapi/asm-generic/fcntl.h | 2 --
> tools/include/uapi/asm-generic/fcntl.h | 2 --
> 2 files changed, 4 deletions(-)
>
> diff --git a/include/uapi/asm-generic/fcntl.h b/include/uapi/asm-generic/fcntl.h
> index ecd0f5bdfc1d6..caa482e3b01af 100644
> --- a/include/uapi/asm-generic/fcntl.h
> +++ b/include/uapi/asm-generic/fcntl.h
> @@ -207,7 +207,6 @@ struct flock {
> };
> #endif
>
> -#ifndef HAVE_ARCH_STRUCT_FLOCK64
> #ifndef __ARCH_FLOCK64_PAD
> #define __ARCH_FLOCK64_PAD
> #endif
> @@ -220,6 +219,5 @@ struct flock64 {
> __kernel_pid_t l_pid;
> __ARCH_FLOCK64_PAD
> };
> -#endif
>
> #endif /* _ASM_GENERIC_FCNTL_H */
> diff --git a/tools/include/uapi/asm-generic/fcntl.h b/tools/include/uapi/asm-generic/fcntl.h
> index ac190958c9814..4a49d33ca4d55 100644
> --- a/tools/include/uapi/asm-generic/fcntl.h
> +++ b/tools/include/uapi/asm-generic/fcntl.h
> @@ -202,7 +202,6 @@ struct flock {
> };
> #endif
>
> -#ifndef HAVE_ARCH_STRUCT_FLOCK64
> #ifndef __ARCH_FLOCK64_PAD
> #define __ARCH_FLOCK64_PAD
> #endif
> @@ -215,6 +214,5 @@ struct flock64 {
> __kernel_pid_t l_pid;
> __ARCH_FLOCK64_PAD
> };
> -#endif
>
> #endif /* _ASM_GENERIC_FCNTL_H */
> --
> 2.30.2
>
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
^ permalink raw reply related
* Re: [PATCH 2/2] KVM: selftests: Add support for ppc64le
From: Alexey Kardashevskiy @ 2022-02-01 2:02 UTC (permalink / raw)
To: Fabiano Rosas, kvm
Cc: linuxppc-dev, npiggin, paulus, linux-kselftest, pbonzini, shuah
In-Reply-To: <20220120170109.948681-3-farosas@linux.ibm.com>
On 1/21/22 04:01, Fabiano Rosas wrote:
> This adds the infrastructure for writing tests for the powerpc
> platform (Only Radix MMU for now).
>
> This patch also enables two tests:
>
> - a dummy sample test that creates a guest with one vcpu, issues
> hypercalls and reads/writes test values from memory.
>
> - the kvm_page_table test, although at this point I'm not using it to
> test KVM, but mostly as a way to stress test this code.
>
> $ make -C tools/testing/selftests TARGETS=kvm
> $ make -C tools/testing/selftests TARGETS=kvm run_tests
>
> Signed-off-by: Fabiano Rosas <farosas@linux.ibm.com>
> ---
> MAINTAINERS | 3 +
> tools/testing/selftests/kvm/.gitignore | 1 +
> tools/testing/selftests/kvm/Makefile | 14 +-
> .../selftests/kvm/include/kvm_util_base.h | 7 +
> .../selftests/kvm/include/ppc64le/processor.h | 43 +++
> tools/testing/selftests/kvm/lib/kvm_util.c | 5 +
> .../testing/selftests/kvm/lib/powerpc/hcall.S | 6 +
> .../selftests/kvm/lib/powerpc/processor.c | 343 ++++++++++++++++++
> .../testing/selftests/kvm/lib/powerpc/ucall.c | 67 ++++
> .../selftests/kvm/powerpc/sample_test.c | 144 ++++++++
> 10 files changed, 630 insertions(+), 3 deletions(-)
> create mode 100644 tools/testing/selftests/kvm/include/ppc64le/processor.h
> create mode 100644 tools/testing/selftests/kvm/lib/powerpc/hcall.S
> create mode 100644 tools/testing/selftests/kvm/lib/powerpc/processor.c
> create mode 100644 tools/testing/selftests/kvm/lib/powerpc/ucall.c
> create mode 100644 tools/testing/selftests/kvm/powerpc/sample_test.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a76e7558b151..15c89d33d584 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -10537,6 +10537,9 @@ F: arch/powerpc/include/asm/kvm*
> F: arch/powerpc/include/uapi/asm/kvm*
> F: arch/powerpc/kernel/kvm*
> F: arch/powerpc/kvm/
> +F: tools/testing/selftests/kvm/include/ppc64le/
> +F: tools/testing/selftests/kvm/lib/powerpc/
> +F: tools/testing/selftests/kvm/powerpc/
>
> KERNEL VIRTUAL MACHINE FOR RISC-V (KVM/riscv)
> M: Anup Patel <anup@brainfault.org>
> diff --git a/tools/testing/selftests/kvm/.gitignore b/tools/testing/selftests/kvm/.gitignore
> index 8c129961accf..45ab993e2845 100644
> --- a/tools/testing/selftests/kvm/.gitignore
> +++ b/tools/testing/selftests/kvm/.gitignore
> @@ -46,6 +46,7 @@
> /x86_64/xen_vmcall_test
> /x86_64/xss_msr_test
> /x86_64/vmx_pmu_msrs_test
> +/powerpc/sample_test
> /access_tracking_perf_test
> /demand_paging_test
> /dirty_log_test
> diff --git a/tools/testing/selftests/kvm/Makefile b/tools/testing/selftests/kvm/Makefile
> index 556da71c33b8..5ae27109e9b9 100644
> --- a/tools/testing/selftests/kvm/Makefile
> +++ b/tools/testing/selftests/kvm/Makefile
> @@ -17,9 +17,9 @@ KSFT_KHDR_INSTALL := 1
> # LINUX_TOOL_ARCH_INCLUDE is set using ARCH variable.
> #
> # x86_64 targets are named to include x86_64 as a suffix and directories
> -# for includes are in x86_64 sub-directory. s390x and aarch64 follow the
> -# same convention. "uname -m" doesn't result in the correct mapping for
> -# s390x and aarch64.
> +# for includes are in x86_64 sub-directory. s390x, aarch64 and ppc64le
> +# follow the same convention. "uname -m" doesn't result in the correct
> +# mapping for s390x, aarch64 and ppc64le.
> #
> # No change necessary for x86_64
> UNAME_M := $(shell uname -m)
> @@ -36,12 +36,17 @@ endif
> ifeq ($(ARCH),riscv)
> UNAME_M := riscv
> endif
> +# Set UNAME_M for ppc64le compile/install to work
> +ifeq ($(ARCH),powerpc)
> + UNAME_M := ppc64le
> +endif
>
> LIBKVM = lib/assert.c lib/elf.c lib/io.c lib/kvm_util.c lib/rbtree.c lib/sparsebit.c lib/test_util.c lib/guest_modes.c lib/perf_test_util.c
> LIBKVM_x86_64 = lib/x86_64/apic.c lib/x86_64/processor.c lib/x86_64/vmx.c lib/x86_64/svm.c lib/x86_64/ucall.c lib/x86_64/handlers.S
> LIBKVM_aarch64 = lib/aarch64/processor.c lib/aarch64/ucall.c lib/aarch64/handlers.S lib/aarch64/spinlock.c lib/aarch64/gic.c lib/aarch64/gic_v3.c lib/aarch64/vgic.c
> LIBKVM_s390x = lib/s390x/processor.c lib/s390x/ucall.c lib/s390x/diag318_test_handler.c
> LIBKVM_riscv = lib/riscv/processor.c lib/riscv/ucall.c
> +LIBKVM_ppc64le = lib/powerpc/processor.c lib/powerpc/ucall.c lib/powerpc/hcall.S
>
> TEST_GEN_PROGS_x86_64 = x86_64/cr4_cpuid_sync_test
> TEST_GEN_PROGS_x86_64 += x86_64/get_msr_index_features
> @@ -133,6 +138,9 @@ TEST_GEN_PROGS_riscv += kvm_page_table_test
> TEST_GEN_PROGS_riscv += set_memory_region_test
> TEST_GEN_PROGS_riscv += kvm_binary_stats_test
>
> +TEST_GEN_PROGS_ppc64le += powerpc/sample_test
> +TEST_GEN_PROGS_ppc64le += kvm_page_table_test
> +
> TEST_GEN_PROGS += $(TEST_GEN_PROGS_$(UNAME_M))
> LIBKVM += $(LIBKVM_$(UNAME_M))
>
> diff --git a/tools/testing/selftests/kvm/include/kvm_util_base.h b/tools/testing/selftests/kvm/include/kvm_util_base.h
> index 66775de26952..a930d663fe67 100644
> --- a/tools/testing/selftests/kvm/include/kvm_util_base.h
> +++ b/tools/testing/selftests/kvm/include/kvm_util_base.h
> @@ -54,6 +54,7 @@ enum vm_guest_mode {
> VM_MODE_P36V48_16K,
> VM_MODE_P36V48_64K,
> VM_MODE_P36V47_16K,
> + VM_MODE_P51V52_64K,
> NUM_VM_MODES,
> };
>
> @@ -87,6 +88,12 @@ extern enum vm_guest_mode vm_mode_default;
> #define MIN_PAGE_SHIFT 12U
> #define ptes_per_page(page_size) ((page_size) / 8)
>
> +#elif defined(__powerpc__)
> +
> +#define VM_MODE_DEFAULT VM_MODE_P51V52_64K
> +#define MIN_PAGE_SHIFT 16U
> +#define ptes_per_page(page_size) ((page_size) / 8)
> +
> #endif
>
> #define MIN_PAGE_SIZE (1U << MIN_PAGE_SHIFT)
> diff --git a/tools/testing/selftests/kvm/include/ppc64le/processor.h b/tools/testing/selftests/kvm/include/ppc64le/processor.h
> new file mode 100644
> index 000000000000..fbc1332b2b80
> --- /dev/null
> +++ b/tools/testing/selftests/kvm/include/ppc64le/processor.h
> @@ -0,0 +1,43 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * powerpc processor specific defines
> + */
> +#ifndef SELFTEST_KVM_PROCESSOR_H
> +#define SELFTEST_KVM_PROCESSOR_H
> +
> +#define PPC_BIT(x) (1ULL << (63 - x))
Put the "x" in braces.
> +
> +#define MSR_SF PPC_BIT(0)
> +#define MSR_IR PPC_BIT(58)
> +#define MSR_DR PPC_BIT(59)
> +#define MSR_LE PPC_BIT(63)
> +
> +#define LPCR_UPRT PPC_BIT(41)
> +#define LPCR_EVIRT PPC_BIT(42)
> +#define LPCR_HR PPC_BIT(43)
> +#define LPCR_GTSE PPC_BIT(53)
> +
> +#define PATB_GR PPC_BIT(0)
> +
> +#define PTE_VALID PPC_BIT(0)
> +#define PTE_LEAF PPC_BIT(1)
> +#define PTE_R PPC_BIT(55)
> +#define PTE_C PPC_BIT(56)
> +#define PTE_RC (PTE_R | PTE_C)
> +#define PTE_READ 0x4
> +#define PTE_WRITE 0x2
> +#define PTE_EXEC 0x1
> +#define PTE_RWX (PTE_READ|PTE_WRITE|PTE_EXEC)
> +
> +extern uint64_t hcall(uint64_t nr, ...);
> +
> +static inline uint32_t mfpvr(void)
> +{
> + uint32_t pvr;
> +
> + asm ("mfpvr %0"
> + : "=r"(pvr));
> + return pvr;
> +}
> +
> +#endif
> diff --git a/tools/testing/selftests/kvm/lib/kvm_util.c b/tools/testing/selftests/kvm/lib/kvm_util.c
> index c22a17aac6b0..cc5247c2cfeb 100644
> --- a/tools/testing/selftests/kvm/lib/kvm_util.c
> +++ b/tools/testing/selftests/kvm/lib/kvm_util.c
> @@ -205,6 +205,7 @@ const char *vm_guest_mode_string(uint32_t i)
> [VM_MODE_P36V48_16K] = "PA-bits:36, VA-bits:48, 16K pages",
> [VM_MODE_P36V48_64K] = "PA-bits:36, VA-bits:48, 64K pages",
> [VM_MODE_P36V47_16K] = "PA-bits:36, VA-bits:47, 16K pages",
> + [VM_MODE_P51V52_64K] = "PA-bits:51, VA-bits:52, 64K pages",
> };
> _Static_assert(sizeof(strings)/sizeof(char *) == NUM_VM_MODES,
> "Missing new mode strings?");
> @@ -230,6 +231,7 @@ const struct vm_guest_mode_params vm_guest_mode_params[] = {
> [VM_MODE_P36V48_16K] = { 36, 48, 0x4000, 14 },
> [VM_MODE_P36V48_64K] = { 36, 48, 0x10000, 16 },
> [VM_MODE_P36V47_16K] = { 36, 47, 0x4000, 14 },
> + [VM_MODE_P51V52_64K] = { 51, 52, 0x10000, 16 },
> };
> _Static_assert(sizeof(vm_guest_mode_params)/sizeof(struct vm_guest_mode_params) == NUM_VM_MODES,
> "Missing new mode params?");
> @@ -331,6 +333,9 @@ struct kvm_vm *vm_create(enum vm_guest_mode mode, uint64_t phy_pages, int perm)
> case VM_MODE_P44V64_4K:
> vm->pgtable_levels = 5;
> break;
> + case VM_MODE_P51V52_64K:
> + vm->pgtable_levels = 4;
> + break;
> default:
> TEST_FAIL("Unknown guest mode, mode: 0x%x", mode);
> }
> diff --git a/tools/testing/selftests/kvm/lib/powerpc/hcall.S b/tools/testing/selftests/kvm/lib/powerpc/hcall.S
> new file mode 100644
> index 000000000000..a78b88f3b207
> --- /dev/null
> +++ b/tools/testing/selftests/kvm/lib/powerpc/hcall.S
> @@ -0,0 +1,6 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +.globl hcall;
> +
> +hcall:
> + sc 1
> + blr
> diff --git a/tools/testing/selftests/kvm/lib/powerpc/processor.c b/tools/testing/selftests/kvm/lib/powerpc/processor.c
> new file mode 100644
> index 000000000000..2ffd5423a968
> --- /dev/null
> +++ b/tools/testing/selftests/kvm/lib/powerpc/processor.c
> @@ -0,0 +1,343 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * KVM selftest powerpc library code
> + *
> + * Copyright (C) 2021, IBM Corp.
2022?
Otherwise looks good and works well and we have another test for
instruction emilation on top of this which highlighted a bug so this is
useful stuff.
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> + */
> +
> +#define _GNU_SOURCE
> +//#define DEBUG
> +
> +#include "kvm_util.h"
> +#include "../kvm_util_internal.h"
> +#include "processor.h"
> +
> +/*
> + * 2^(12+PRTS) = Process table size
> + *
> + * But the hardware doesn't seem to care, so 0 for now.
> + */
> +#define PRTS 0
> +#define RTS ((0x5UL << 5) | (0x2UL << 61)) /* 2^(RTS+31) = 2^52 */
> +#define RPDS 0xd
> +#define RPDB_MASK 0x0fffffffffffff00UL
> +#define RPN_MASK 0x01fffffffffff000UL
> +
> +#define MIN_FRAME_SZ 32
> +
> +static const int radix_64k_index_sizes[4] = { 5, 9, 9, 13 };
> +
> +static inline uint64_t mk_pte(uint64_t pte_val)
> +{
> + return cpu_to_be64(PTE_VALID | pte_val);
> +}
> +
> +static inline uint64_t get_pte(uint64_t pte)
> +{
> + return be64_to_cpu(pte);
> +}
> +
> +static inline uint64_t pte_rpn(uint64_t entry)
> +{
> + return get_pte(entry) & RPN_MASK;
> +}
> +
> +static inline uint64_t next_pde(uint64_t entry)
> +{
> + return get_pte(entry) & RPDB_MASK;
> +}
> +
> +static inline uint64_t ptrs_per_pgd(int level)
> +{
> + return 1UL << radix_64k_index_sizes[level];
> +}
> +
> +static inline uint64_t level_size(int level)
> +{
> + return sizeof(vm_paddr_t) << (radix_64k_index_sizes[level] + 3);
> +}
> +
> +static vm_paddr_t alloc_pgd(struct kvm_vm *vm, int level)
> +{
> + static vm_paddr_t base;
> + vm_paddr_t addr;
> + uint64_t size = level_size(level);
> +
> + if (!base || (base + size) >> vm->page_shift != base >> vm->page_shift)
> + addr = vm_alloc_page_table(vm);
> + else
> + addr = base;
> + base = addr + size;
> +
> + return addr;
> +}
> +
> +static vm_paddr_t pgtable_walk(struct kvm_vm *vm, vm_vaddr_t gva, uint64_t gpa,
> + bool alloc)
> +{
> + uint64_t index_bits, shift, base, index;
> + uint64_t *ptep, ptep_gpa;
> + int level;
> +
> + if (!vm->pgd_created)
> + goto unmapped_gva;
> +
> + pr_debug("%s %#lx ", (alloc ? "mapping" : "lookup "), gva);
> +
> + base = vm->pgd;
> + shift = vm->va_bits;
> +
> + for (level = 3; level >= 0; --level) {
> +
> + index_bits = radix_64k_index_sizes[level];
> + shift -= index_bits;
> +
> + index = (gva >> shift) & ((1UL << index_bits) - 1);
> + ptep_gpa = base + index * sizeof(*ptep);
> + ptep = addr_gpa2hva(vm, ptep_gpa);
> +
> + if (!*ptep) {
> + if (!alloc)
> + goto unmapped_gva;
> + if (level)
> + *ptep = mk_pte(alloc_pgd(vm, level - 1) |
> + radix_64k_index_sizes[level - 1]);
> + }
> +
> + if (get_pte(*ptep) & PTE_LEAF)
> + break;
> +
> + base = next_pde(*ptep);
> + }
> +
> + if (alloc)
> + *ptep = mk_pte(PTE_LEAF | gpa | PTE_RC | PTE_RWX);
> + else
> + gpa = pte_rpn(*ptep);
> +
> + pr_debug("-> %#lx pte: %#lx (@%#lx)\n", gpa, get_pte(*ptep), ptep_gpa);
> +
> + return gpa | (gva & (vm->page_size - 1));
> +
> +unmapped_gva:
> + TEST_FAIL("No mapping for vm virtual address, gva: %#lx", gva);
> + exit(1);
> +}
> +
> +void virt_pg_map(struct kvm_vm *vm, uint64_t vaddr, uint64_t paddr)
> +{
> + TEST_ASSERT((vaddr % vm->page_size) == 0,
> + "Virtual address not on page boundary,\n"
> + " vaddr: 0x%lx vm->page_size: 0x%x", vaddr, vm->page_size);
> +
> + TEST_ASSERT(sparsebit_is_set(vm->vpages_valid,
> + (vaddr >> vm->page_shift)),
> + "Invalid virtual address, vaddr: 0x%lx", vaddr);
> +
> + TEST_ASSERT((paddr % vm->page_size) == 0,
> + "Physical address not on page boundary,\n"
> + " paddr: 0x%lx vm->page_size: 0x%x", paddr, vm->page_size);
> +
> + TEST_ASSERT((paddr >> vm->page_shift) <= vm->max_gfn,
> + "Physical address beyond maximum supported,\n"
> + " paddr: 0x%lx vm->max_gfn: 0x%lx vm->page_size: 0x%x",
> + paddr, vm->max_gfn, vm->page_size);
> +
> + TEST_ASSERT(vm->pgd_created, "Page table not created\n");
> +
> + pgtable_walk(vm, vaddr, paddr, true);
> +}
> +
> +vm_paddr_t addr_gva2gpa(struct kvm_vm *vm, vm_vaddr_t gva)
> +{
> + return pgtable_walk(vm, gva, 0, false);
> +}
> +
> +void virt_pgd_alloc(struct kvm_vm *vm)
> +{
> + struct kvm_ppc_mmuv3_cfg cfg = { 0 };
> + vm_paddr_t proc_tb;
> + uint64_t *proc_tb_hva;
> +
> + if (!kvm_check_cap(KVM_CAP_PPC_MMU_RADIX)) {
> + print_skip("Tests only support Radix MMU");
> + exit(KSFT_SKIP);
> + }
> +
> + if (!kvm_check_cap(KVM_CAP_PPC_PAPR)) {
> + print_skip("Tests only support Book3s");
> + exit(KSFT_SKIP);
> + }
> +
> + if (vm->pgd_created)
> + return;
> +
> + /*
> + * Allocate the process table in guest memory and set the
> + * first doubleword of the pid 0 entry.
> + */
> + proc_tb = vm_alloc_page_table(vm);
> + vm->pgd = vm_alloc_page_table(vm);
> +
> + proc_tb_hva = addr_gpa2hva(vm, proc_tb);
> + *proc_tb_hva = cpu_to_be64(RTS | vm->pgd | RPDS);
> +
> + pr_debug("process table gpa: %#lx\n", proc_tb);
> + pr_debug("process table hva: %p\n", proc_tb_hva);
> + pr_debug("process table entry 0 dw0: %#lx\n", *proc_tb_hva);
> +
> + /* Register the process table with the HV */
> + cfg.process_table = PATB_GR | proc_tb | PRTS;
> + cfg.flags = KVM_PPC_MMUV3_RADIX | KVM_PPC_MMUV3_GTSE;
> +
> + pr_debug("MMU config proc table: %#llx\n", cfg.process_table);
> +
> + vm_ioctl(vm, KVM_PPC_CONFIGURE_V3_MMU, &cfg);
> + vm->pgd_created = true;
> +}
> +
> +void vm_vcpu_add_default(struct kvm_vm *vm, uint32_t vcpuid, void *guest_code)
> +{
> + struct kvm_enable_cap cap = { 0 };
> + struct kvm_regs regs;
> + struct kvm_sregs sregs;
> + vm_vaddr_t stack_vaddr;
> + size_t stack_sz;
> +
> + vm_vcpu_add(vm, vcpuid);
> +
> + cap.cap = KVM_CAP_PPC_PAPR;
> + vcpu_enable_cap(vm, vcpuid, &cap);
> +
> + stack_sz = DEFAULT_STACK_PGS * vm->page_size;
> + stack_vaddr = vm_vaddr_alloc(vm, stack_sz,
> + DEFAULT_GUEST_STACK_VADDR_MIN);
> +
> + regs.msr = MSR_SF | MSR_LE;
> + regs.msr |= MSR_IR | MSR_DR;
> + regs.pc = (unsigned long) guest_code;
> + regs.pid = 0;
> + regs.gpr[1] = stack_vaddr + stack_sz - MIN_FRAME_SZ;
> +
> + pr_debug("stack - low: %#lx high: %#lx size: %#lx SP: %#llx\n",
> + stack_vaddr, stack_vaddr + stack_sz, stack_sz, regs.gpr[1]);
> +
> + vcpu_regs_set(vm, vcpuid, ®s);
> +
> + sregs.pvr = mfpvr();
> + vcpu_sregs_set(vm, vcpuid, &sregs);
> +
> + if (kvm_check_cap(KVM_CAP_ONE_REG)) {
> + uint64_t lpcr = LPCR_UPRT | LPCR_HR | LPCR_GTSE;
> + struct kvm_one_reg reg = {
> + .id = KVM_REG_PPC_LPCR_64,
> + .addr = (uintptr_t) &lpcr,
> + };
> +
> + vcpu_ioctl(vm, vcpuid, KVM_SET_ONE_REG, ®);
> + }
> +}
> +
> +void vcpu_args_set(struct kvm_vm *vm, uint32_t vcpuid, unsigned int num, ...)
> +{
> + va_list ap;
> + struct kvm_regs regs;
> + int i;
> +
> + TEST_ASSERT(num >= 1 && num <= 8, "Unsupported number of args,\n"
> + " num: %u\n", num);
> +
> + va_start(ap, num);
> + vcpu_regs_get(vm, vcpuid, ®s);
> +
> + for (i = 0; i < num; i++)
> + regs.gpr[i + 3] = va_arg(ap, uint64_t);
> +
> + vcpu_regs_set(vm, vcpuid, ®s);
> + va_end(ap);
> +}
> +
> +static void pte_dump(FILE *stream, struct kvm_vm *vm, uint8_t indent,
> + uint64_t addr, int level)
> +{
> + static const char * const type[] = { "pte", "pmd", "pud", "pgd" };
> + uint64_t pde, *hva;
> +
> + if (level < 0)
> + return;
> +
> + fprintf(stream, "%*s (%#lx):\n", indent, type[level], addr);
> +
> + for (pde = addr; pde < addr + (ptrs_per_pgd(level) * sizeof(vm_paddr_t));
> + pde += sizeof(vm_paddr_t)) {
> +
> + hva = addr_gpa2hva(vm, pde);
> + if (!*hva)
> + continue;
> + fprintf(stream, "%*s %#lx: %#lx\n", indent + 1, "", pde,
> + get_pte(*hva));
> + pte_dump(stream, vm, indent + 2, next_pde(*hva), level - 1);
> + }
> +}
> +
> +void virt_dump(FILE *stream, struct kvm_vm *vm, uint8_t indent)
> +{
> + if (!vm->pgd_created)
> + return;
> +
> + pte_dump(stream, vm, indent, vm->pgd, 3);
> +}
> +
> +void vcpu_dump(FILE *stream, struct kvm_vm *vm, uint32_t vcpuid, uint8_t indent)
> +{
> + struct kvm_regs regs;
> +
> + fprintf(stream, "%*scpuid: %u\n", indent, "", vcpuid);
> +
> + vcpu_regs_get(vm, vcpuid, ®s);
> + fprintf(stream, "%*sregs:\n", indent + 2, "");
> +
> + fprintf(stream, "%*spc: %#llx\n", indent + 4, "", regs.pc);
> + fprintf(stream, "%*smsr: %#llx\n", indent + 4, "", regs.msr);
> + fprintf(stream, "%*ssrr0: %#llx\n", indent + 4, "", regs.srr0);
> + fprintf(stream, "%*ssrr1: %#llx\n", indent + 4, "", regs.srr1);
> +
> + fprintf(stream, "\n%*sr1: %#llx\n", indent + 4, "", regs.gpr[1]);
> + fprintf(stream, "%*sr2: %#llx\n", indent + 4, "", regs.gpr[2]);
> + fprintf(stream, "%*sr3: %#llx\n", indent + 4, "", regs.gpr[3]);
> + fprintf(stream, "%*sr4: %#llx\n", indent + 4, "", regs.gpr[4]);
> +
> + if (kvm_check_cap(KVM_CAP_ONE_REG)) {
> + uint64_t lpcr;
> + struct kvm_one_reg reg = {
> + .id = KVM_REG_PPC_LPCR_64,
> + .addr = (uintptr_t) &lpcr,
> + };
> +
> + vcpu_ioctl(vm, vcpuid, KVM_GET_ONE_REG, ®);
> + fprintf(stream, "%*slpcr: %#lx\n", indent + 4, "", lpcr);
> + }
> + fprintf(stream, "%*slr: %#llx\n", indent + 4, "", regs.lr);
> +}
> +
> +void assert_on_unhandled_exception(struct kvm_vm *vm, uint32_t vcpuid)
> +{
> + struct kvm_run *run;
> +
> + run = vcpu_state(vm, vcpuid);
> + if (run) {
> + switch (run->exit_reason) {
> + case KVM_EXIT_PAPR_HCALL:
> + case KVM_EXIT_MMIO:
> + return;
> + default:
> + printf("reason: %s\n",
> + exit_reason_str(run->exit_reason));
> + break;
> + }
> + }
> +#ifdef DEBUG
> + vm_dump(stderr, vm, 2);
> +#endif
> + TEST_ASSERT(false, "Unhandled exception");
> +}
> diff --git a/tools/testing/selftests/kvm/lib/powerpc/ucall.c b/tools/testing/selftests/kvm/lib/powerpc/ucall.c
> new file mode 100644
> index 000000000000..fc76ef796f02
> --- /dev/null
> +++ b/tools/testing/selftests/kvm/lib/powerpc/ucall.c
> @@ -0,0 +1,67 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include "kvm_util.h"
> +#include "processor.h"
> +
> +/*
> + * Using this hypercall for now because it is already defined. It is
> + * used by SLOF to ask QEMU to copy memory regions, so it is close
> + * enough for our purposes.
> + */
> +#define KVMPPC_H_LOGICAL_MEMOP 0xf001
> +
> +
> +void ucall_init(struct kvm_vm *vm, void *arg)
> +{
> +}
> +
> +void ucall_uninit(struct kvm_vm *vm)
> +{
> +}
> +
> +static inline int __ucall(uint64_t args)
> +{
> + return hcall(KVMPPC_H_LOGICAL_MEMOP, args);
> +}
> +
> +/*
> + * This function runs inside the guest, so avoid optimizations that
> + * could add an indirect call via PLT and disable vector instructions
> + * like the kernel does.
> + */
> +__attribute__((optimize(0), target("no-altivec,no-vsx")))
> +void ucall(uint64_t cmd, int nargs, ...)
> +{
> + struct ucall uc = {
> + .cmd = cmd,
> + };
> + va_list va;
> + int i;
> +
> + nargs = nargs <= UCALL_MAX_ARGS ? nargs : UCALL_MAX_ARGS;
> +
> + va_start(va, nargs);
> + for (i = 0; i < nargs; ++i)
> + uc.args[i] = va_arg(va, uint64_t);
> + va_end(va);
> +
> + __ucall((uint64_t)&uc);
> +}
> +
> +uint64_t get_ucall(struct kvm_vm *vm, uint32_t vcpu_id, struct ucall *uc)
> +{
> + struct kvm_run *run = vcpu_state(vm, vcpu_id);
> + struct ucall ucall = {};
> +
> + if (uc)
> + memset(uc, 0, sizeof(*uc));
> +
> + if (run->exit_reason == KVM_EXIT_PAPR_HCALL &&
> + run->papr_hcall.nr == KVMPPC_H_LOGICAL_MEMOP) {
> + memcpy(&ucall, addr_gva2hva(vm, run->papr_hcall.args[0]),
> + sizeof(ucall));
> + if (uc)
> + memcpy(uc, &ucall, sizeof(ucall));
> + }
> +
> + return ucall.cmd;
> +}
> diff --git a/tools/testing/selftests/kvm/powerpc/sample_test.c b/tools/testing/selftests/kvm/powerpc/sample_test.c
> new file mode 100644
> index 000000000000..16f0df920d98
> --- /dev/null
> +++ b/tools/testing/selftests/kvm/powerpc/sample_test.c
> @@ -0,0 +1,144 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +#define _GNU_SOURCE /* for program_invocation_short_name */
> +#include <pthread.h>
> +#include <stdio.h>
> +#include <signal.h>
> +
> +#define DEBUG
> +#include "kvm_util.h"
> +#include "test_util.h"
> +#include "processor.h"
> +
> +#define H_PUT_TERM_CHAR 0x58
> +#define TEST_VAL 0x8badf00d
> +#define PASS_VAL 0xdeadbeef
> +#define FAIL_VAL 0x2badd00d
> +
> +
> +struct kvm_vm *vm;
> +
> +/*
> + * Call the hypervisor to write a character to the console. KVM does
> + * not handle this hypercall so it goes out to userspace. Which in
> + * this case is the vcpu_worker() below.
> + */
> +static inline void put_char(char c)
> +{
> + hcall(H_PUT_TERM_CHAR, 0, 1, cpu_to_be64(c));
> +}
> +
> +static void guest_code(uint64_t *ptr, uint64_t val)
> +{
> + /*
> + * Test making a hypercall and give a visual indication that
> + * the guest code is running.
> + */
> + put_char('.');
> +
> + /* Make sure we can receive values */
> + GUEST_ASSERT(ptr);
> + GUEST_ASSERT(val == TEST_VAL);
> +
> + put_char('.');
> +
> + /* Read/write to memory */
> + if (*ptr == val)
> + *ptr = PASS_VAL;
> + else
> + *ptr = FAIL_VAL;
> +
> + put_char('.');
> +
> + /* Signal we're done */
> + GUEST_DONE();
> +}
> +
> +static bool guest_done(struct kvm_vm *vm)
> +{
> + struct ucall uc;
> + bool done;
> +
> + switch (get_ucall(vm, 0, &uc)) {
> + case UCALL_ABORT:
> + TEST_FAIL("%s at %s:%ld", (const char *)uc.args[0],
> + __FILE__, uc.args[1]);
> + /* not reached */
> + case UCALL_DONE:
> + done = true;
> + break;
> + default:
> + done = false;
> + break;
> + }
> +
> + return done;
> +}
> +
> +static void *vcpu_worker(void *data)
> +{
> + struct kvm_vm *vm = data;
> + struct kvm_run *run;
> + uint64_t *hva;
> + static uint64_t test_buf = TEST_VAL;
> +
> + /* Pass arguments to the guest code */
> + vcpu_args_set(vm, 0, 2, &test_buf, TEST_VAL);
> +
> + run = vcpu_state(vm, 0);
> + while (1) {
> + vcpu_run(vm, 0);
> +
> + if (guest_done(vm))
> + break;
> +
> + switch (run->exit_reason) {
> + case KVM_EXIT_PAPR_HCALL:
> + if (run->papr_hcall.nr == H_PUT_TERM_CHAR) {
> + char c = be64_to_cpu(run->papr_hcall.args[2]);
> +
> + pr_debug("%c", c);
> + }
> + break;
> + default:
> + printf("exit reason: %s\n", exit_reason_str(run->exit_reason));
> + break;
> + }
> + }
> +
> + hva = addr_gva2hva(vm, (vm_vaddr_t)&test_buf);
> + TEST_ASSERT(*hva != FAIL_VAL,
> + "Guest failed to read test value at gva %p", &test_buf);
> + TEST_ASSERT(*hva == PASS_VAL,
> + "Guest failed to write test value to gva %p", &test_buf);
> +
> + pr_debug("PASS\n");
> +
> + return NULL;
> +}
> +
> +void dump_vm(int sig)
> +{
> + vm_dump(stderr, vm, 2);
> + exit(1);
> +}
> +
> +int main(int argc, char *argv[])
> +{
> + pthread_t vcpu_thread;
> +
> + signal(SIGINT, dump_vm);
> +
> + /*
> + * Do not buffer stdout so we can implement put_char without
> + * flushing.
> + */
> + setbuf(stdout, NULL);
> +
> + vm = vm_create_default(0, 0, guest_code);
> + pthread_create(&vcpu_thread, NULL, vcpu_worker, vm);
> +
> + pthread_join(vcpu_thread, NULL);
> + kvm_vm_free(vm);
> +
> + return 0;
> +}
^ permalink raw reply
* Re: [PATCH 4/5] uapi: always define F_GETLK64/F_SETLK64/F_SETLKW64 in fcntl.h
From: Guo Ren @ 2022-02-01 3:02 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-arch, linux-s390, Arnd Bergmann, Parisc List,
the arch/x86 maintainers, open list:BROADCOM NVRAM DRIVER,
Linux Kernel Mailing List, sparclinux, linuxppc-dev, Linux ARM
In-Reply-To: <20220131064933.3780271-5-hch@lst.de>
On Mon, Jan 31, 2022 at 2:49 PM Christoph Hellwig <hch@lst.de> wrote:
>
> The F_GETLK64/F_SETLK64/F_SETLKW64 fcntl opcodes are only implemented
> for the 32-bit syscall APIs, but are also needed for compat handling
> on 64-bit kernels.
>
> Consolidate them in unistd.h instead of definining the internal compat
> definitions in compat.h, which is rather errror prone (e.g. parisc
> gets the values wrong currently).
>
> Note that before this change they were never visible to userspace due
> to the fact that CONFIG_64BIT is only set for kernel builds.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> arch/arm64/include/asm/compat.h | 4 ----
> arch/mips/include/asm/compat.h | 4 ----
> arch/mips/include/uapi/asm/fcntl.h | 4 ++--
> arch/powerpc/include/asm/compat.h | 4 ----
> arch/s390/include/asm/compat.h | 4 ----
> arch/sparc/include/asm/compat.h | 4 ----
> arch/x86/include/asm/compat.h | 4 ----
> include/uapi/asm-generic/fcntl.h | 4 ++--
> tools/include/uapi/asm-generic/fcntl.h | 2 --
> 9 files changed, 4 insertions(+), 30 deletions(-)
>
> diff --git a/arch/arm64/include/asm/compat.h b/arch/arm64/include/asm/compat.h
> index eaa6ca062d89b..2763287654081 100644
> --- a/arch/arm64/include/asm/compat.h
> +++ b/arch/arm64/include/asm/compat.h
> @@ -73,10 +73,6 @@ struct compat_flock {
> compat_pid_t l_pid;
> };
>
> -#define F_GETLK64 12 /* using 'struct flock64' */
> -#define F_SETLK64 13
> -#define F_SETLKW64 14
> -
> struct compat_flock64 {
> short l_type;
> short l_whence;
> diff --git a/arch/mips/include/asm/compat.h b/arch/mips/include/asm/compat.h
> index bbb3bc5a42fd8..6a350c1f70d7e 100644
> --- a/arch/mips/include/asm/compat.h
> +++ b/arch/mips/include/asm/compat.h
> @@ -65,10 +65,6 @@ struct compat_flock {
> s32 pad[4];
> };
>
> -#define F_GETLK64 33
> -#define F_SETLK64 34
> -#define F_SETLKW64 35
Oops we can't remove above, right?
> -
> struct compat_flock64 {
> short l_type;
> short l_whence;
> diff --git a/arch/mips/include/uapi/asm/fcntl.h b/arch/mips/include/uapi/asm/fcntl.h
> index 9e44ac810db94..0369a38e3d4f2 100644
> --- a/arch/mips/include/uapi/asm/fcntl.h
> +++ b/arch/mips/include/uapi/asm/fcntl.h
> @@ -44,11 +44,11 @@
> #define F_SETOWN 24 /* for sockets. */
> #define F_GETOWN 23 /* for sockets. */
>
> -#ifndef __mips64
> +#if __BITS_PER_LONG == 32 || defined(__KERNEL__)
> #define F_GETLK64 33 /* using 'struct flock64' */
> #define F_SETLK64 34
> #define F_SETLKW64 35
> -#endif
> +#endif /* __BITS_PER_LONG == 32 || defined(__KERNEL__) */
>
> #if _MIPS_SIM != _MIPS_SIM_ABI64
> #define __ARCH_FLOCK_EXTRA_SYSID long l_sysid;
> diff --git a/arch/powerpc/include/asm/compat.h b/arch/powerpc/include/asm/compat.h
> index 7afc96fb6524b..83d8f70779cbc 100644
> --- a/arch/powerpc/include/asm/compat.h
> +++ b/arch/powerpc/include/asm/compat.h
> @@ -52,10 +52,6 @@ struct compat_flock {
> compat_pid_t l_pid;
> };
>
> -#define F_GETLK64 12 /* using 'struct flock64' */
> -#define F_SETLK64 13
> -#define F_SETLKW64 14
> -
> struct compat_flock64 {
> short l_type;
> short l_whence;
> diff --git a/arch/s390/include/asm/compat.h b/arch/s390/include/asm/compat.h
> index cdc7ae72529d8..0f14b3188b1bb 100644
> --- a/arch/s390/include/asm/compat.h
> +++ b/arch/s390/include/asm/compat.h
> @@ -110,10 +110,6 @@ struct compat_flock {
> compat_pid_t l_pid;
> };
>
> -#define F_GETLK64 12
> -#define F_SETLK64 13
> -#define F_SETLKW64 14
> -
> struct compat_flock64 {
> short l_type;
> short l_whence;
> diff --git a/arch/sparc/include/asm/compat.h b/arch/sparc/include/asm/compat.h
> index bd949fcf9d63b..108078751bb5a 100644
> --- a/arch/sparc/include/asm/compat.h
> +++ b/arch/sparc/include/asm/compat.h
> @@ -84,10 +84,6 @@ struct compat_flock {
> short __unused;
> };
>
> -#define F_GETLK64 12
> -#define F_SETLK64 13
> -#define F_SETLKW64 14
> -
> struct compat_flock64 {
> short l_type;
> short l_whence;
> diff --git a/arch/x86/include/asm/compat.h b/arch/x86/include/asm/compat.h
> index 7516e4199b3c6..8d19a212f4f26 100644
> --- a/arch/x86/include/asm/compat.h
> +++ b/arch/x86/include/asm/compat.h
> @@ -58,10 +58,6 @@ struct compat_flock {
> compat_pid_t l_pid;
> };
>
> -#define F_GETLK64 12 /* using 'struct flock64' */
> -#define F_SETLK64 13
> -#define F_SETLKW64 14
> -
> /*
> * IA32 uses 4 byte alignment for 64 bit quantities,
> * so we need to pack this structure.
> diff --git a/include/uapi/asm-generic/fcntl.h b/include/uapi/asm-generic/fcntl.h
> index 98f4ff165b776..8c05d3d89ff18 100644
> --- a/include/uapi/asm-generic/fcntl.h
> +++ b/include/uapi/asm-generic/fcntl.h
> @@ -116,13 +116,13 @@
> #define F_GETSIG 11 /* for sockets. */
> #endif
>
> -#ifndef CONFIG_64BIT
> +#if __BITS_PER_LONG == 32 || defined(__KERNEL__)
> #ifndef F_GETLK64
> #define F_GETLK64 12 /* using 'struct flock64' */
> #define F_SETLK64 13
> #define F_SETLKW64 14
> #endif
> -#endif
> +#endif /* __BITS_PER_LONG == 32 || defined(__KERNEL__) */
>
> #ifndef F_SETOWN_EX
> #define F_SETOWN_EX 15
> diff --git a/tools/include/uapi/asm-generic/fcntl.h b/tools/include/uapi/asm-generic/fcntl.h
> index bf961a71802e0..6e16722026f39 100644
> --- a/tools/include/uapi/asm-generic/fcntl.h
> +++ b/tools/include/uapi/asm-generic/fcntl.h
> @@ -115,13 +115,11 @@
> #define F_GETSIG 11 /* for sockets. */
> #endif
>
> -#ifndef CONFIG_64BIT
> #ifndef F_GETLK64
> #define F_GETLK64 12 /* using 'struct flock64' */
> #define F_SETLK64 13
> #define F_SETLKW64 14
> #endif
> -#endif
>
> #ifndef F_SETOWN_EX
> #define F_SETOWN_EX 15
> --
> 2.30.2
>
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
^ permalink raw reply
* Re: [PATCH 4/5] uapi: always define F_GETLK64/F_SETLK64/F_SETLKW64 in fcntl.h
From: Guo Ren @ 2022-02-01 3:07 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-arch, linux-s390, Arnd Bergmann, Parisc List,
the arch/x86 maintainers, open list:BROADCOM NVRAM DRIVER,
Linux Kernel Mailing List, sparclinux, linuxppc-dev, Linux ARM
In-Reply-To: <CAJF2gTRj3DN4YJCM2VXqpyJNY7G-PCG4APcLkMk0CKzg-+SsdA@mail.gmail.com>
On Tue, Feb 1, 2022 at 11:02 AM Guo Ren <guoren@kernel.org> wrote:
>
> On Mon, Jan 31, 2022 at 2:49 PM Christoph Hellwig <hch@lst.de> wrote:
> >
> > The F_GETLK64/F_SETLK64/F_SETLKW64 fcntl opcodes are only implemented
> > for the 32-bit syscall APIs, but are also needed for compat handling
> > on 64-bit kernels.
> >
> > Consolidate them in unistd.h instead of definining the internal compat
> > definitions in compat.h, which is rather errror prone (e.g. parisc
> > gets the values wrong currently).
> >
> > Note that before this change they were never visible to userspace due
> > to the fact that CONFIG_64BIT is only set for kernel builds.
> >
> > Signed-off-by: Christoph Hellwig <hch@lst.de>
> > ---
> > arch/arm64/include/asm/compat.h | 4 ----
> > arch/mips/include/asm/compat.h | 4 ----
> > arch/mips/include/uapi/asm/fcntl.h | 4 ++--
> > arch/powerpc/include/asm/compat.h | 4 ----
> > arch/s390/include/asm/compat.h | 4 ----
> > arch/sparc/include/asm/compat.h | 4 ----
> > arch/x86/include/asm/compat.h | 4 ----
> > include/uapi/asm-generic/fcntl.h | 4 ++--
> > tools/include/uapi/asm-generic/fcntl.h | 2 --
> > 9 files changed, 4 insertions(+), 30 deletions(-)
> >
> > diff --git a/arch/arm64/include/asm/compat.h b/arch/arm64/include/asm/compat.h
> > index eaa6ca062d89b..2763287654081 100644
> > --- a/arch/arm64/include/asm/compat.h
> > +++ b/arch/arm64/include/asm/compat.h
> > @@ -73,10 +73,6 @@ struct compat_flock {
> > compat_pid_t l_pid;
> > };
> >
> > -#define F_GETLK64 12 /* using 'struct flock64' */
> > -#define F_SETLK64 13
> > -#define F_SETLKW64 14
> > -
> > struct compat_flock64 {
> > short l_type;
> > short l_whence;
> > diff --git a/arch/mips/include/asm/compat.h b/arch/mips/include/asm/compat.h
> > index bbb3bc5a42fd8..6a350c1f70d7e 100644
> > --- a/arch/mips/include/asm/compat.h
> > +++ b/arch/mips/include/asm/compat.h
> > @@ -65,10 +65,6 @@ struct compat_flock {
> > s32 pad[4];
> > };
> >
> > -#define F_GETLK64 33
> > -#define F_SETLK64 34
> > -#define F_SETLKW64 35
> Oops we can't remove above, right?
No problem, I missing, it's okay.
All come from arch/mips/include/uapi/asm/fcntl.h
>
> > -
> > struct compat_flock64 {
> > short l_type;
> > short l_whence;
> > diff --git a/arch/mips/include/uapi/asm/fcntl.h b/arch/mips/include/uapi/asm/fcntl.h
> > index 9e44ac810db94..0369a38e3d4f2 100644
> > --- a/arch/mips/include/uapi/asm/fcntl.h
> > +++ b/arch/mips/include/uapi/asm/fcntl.h
> > @@ -44,11 +44,11 @@
> > #define F_SETOWN 24 /* for sockets. */
> > #define F_GETOWN 23 /* for sockets. */
> >
> > -#ifndef __mips64
> > +#if __BITS_PER_LONG == 32 || defined(__KERNEL__)
> > #define F_GETLK64 33 /* using 'struct flock64' */
> > #define F_SETLK64 34
> > #define F_SETLKW64 35
> > -#endif
> > +#endif /* __BITS_PER_LONG == 32 || defined(__KERNEL__) */
> >
> > #if _MIPS_SIM != _MIPS_SIM_ABI64
> > #define __ARCH_FLOCK_EXTRA_SYSID long l_sysid;
> > diff --git a/arch/powerpc/include/asm/compat.h b/arch/powerpc/include/asm/compat.h
> > index 7afc96fb6524b..83d8f70779cbc 100644
> > --- a/arch/powerpc/include/asm/compat.h
> > +++ b/arch/powerpc/include/asm/compat.h
> > @@ -52,10 +52,6 @@ struct compat_flock {
> > compat_pid_t l_pid;
> > };
> >
> > -#define F_GETLK64 12 /* using 'struct flock64' */
> > -#define F_SETLK64 13
> > -#define F_SETLKW64 14
> > -
> > struct compat_flock64 {
> > short l_type;
> > short l_whence;
> > diff --git a/arch/s390/include/asm/compat.h b/arch/s390/include/asm/compat.h
> > index cdc7ae72529d8..0f14b3188b1bb 100644
> > --- a/arch/s390/include/asm/compat.h
> > +++ b/arch/s390/include/asm/compat.h
> > @@ -110,10 +110,6 @@ struct compat_flock {
> > compat_pid_t l_pid;
> > };
> >
> > -#define F_GETLK64 12
> > -#define F_SETLK64 13
> > -#define F_SETLKW64 14
> > -
> > struct compat_flock64 {
> > short l_type;
> > short l_whence;
> > diff --git a/arch/sparc/include/asm/compat.h b/arch/sparc/include/asm/compat.h
> > index bd949fcf9d63b..108078751bb5a 100644
> > --- a/arch/sparc/include/asm/compat.h
> > +++ b/arch/sparc/include/asm/compat.h
> > @@ -84,10 +84,6 @@ struct compat_flock {
> > short __unused;
> > };
> >
> > -#define F_GETLK64 12
> > -#define F_SETLK64 13
> > -#define F_SETLKW64 14
> > -
> > struct compat_flock64 {
> > short l_type;
> > short l_whence;
> > diff --git a/arch/x86/include/asm/compat.h b/arch/x86/include/asm/compat.h
> > index 7516e4199b3c6..8d19a212f4f26 100644
> > --- a/arch/x86/include/asm/compat.h
> > +++ b/arch/x86/include/asm/compat.h
> > @@ -58,10 +58,6 @@ struct compat_flock {
> > compat_pid_t l_pid;
> > };
> >
> > -#define F_GETLK64 12 /* using 'struct flock64' */
> > -#define F_SETLK64 13
> > -#define F_SETLKW64 14
> > -
> > /*
> > * IA32 uses 4 byte alignment for 64 bit quantities,
> > * so we need to pack this structure.
> > diff --git a/include/uapi/asm-generic/fcntl.h b/include/uapi/asm-generic/fcntl.h
> > index 98f4ff165b776..8c05d3d89ff18 100644
> > --- a/include/uapi/asm-generic/fcntl.h
> > +++ b/include/uapi/asm-generic/fcntl.h
> > @@ -116,13 +116,13 @@
> > #define F_GETSIG 11 /* for sockets. */
> > #endif
> >
> > -#ifndef CONFIG_64BIT
> > +#if __BITS_PER_LONG == 32 || defined(__KERNEL__)
> > #ifndef F_GETLK64
> > #define F_GETLK64 12 /* using 'struct flock64' */
> > #define F_SETLK64 13
> > #define F_SETLKW64 14
> > #endif
> > -#endif
> > +#endif /* __BITS_PER_LONG == 32 || defined(__KERNEL__) */
> >
> > #ifndef F_SETOWN_EX
> > #define F_SETOWN_EX 15
> > diff --git a/tools/include/uapi/asm-generic/fcntl.h b/tools/include/uapi/asm-generic/fcntl.h
> > index bf961a71802e0..6e16722026f39 100644
> > --- a/tools/include/uapi/asm-generic/fcntl.h
> > +++ b/tools/include/uapi/asm-generic/fcntl.h
> > @@ -115,13 +115,11 @@
> > #define F_GETSIG 11 /* for sockets. */
> > #endif
> >
> > -#ifndef CONFIG_64BIT
> > #ifndef F_GETLK64
> > #define F_GETLK64 12 /* using 'struct flock64' */
> > #define F_SETLK64 13
> > #define F_SETLKW64 14
> > #endif
> > -#endif
> >
> > #ifndef F_SETOWN_EX
> > #define F_SETOWN_EX 15
> > --
> > 2.30.2
> >
>
>
> --
> Best Regards
> Guo Ren
>
> ML: https://lore.kernel.org/linux-csky/
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
^ permalink raw reply
* Re: [PATCH 2/3] powerpc/pseries/vas: Add VAS migration handler
From: Haren Myneni @ 2022-02-01 4:59 UTC (permalink / raw)
To: Nathan Lynch, mpe, linuxppc-dev, npiggin
In-Reply-To: <87o83rzws1.fsf@linux.ibm.com>
On Mon, 2022-01-31 at 10:37 -0600, Nathan Lynch wrote:
> Hi Haren,
>
> Mostly this seems OK to me. Some questions:
Thanks Nathan for your suggestions.
>
> Haren Myneni <haren@linux.ibm.com> writes:
> > Since the VAS windows belong to the VAS hardware resource, the
> > hypervisor expects the partition to close them on source partition
> > and reopen them after the partition migrated on the destination
> > machine.
>
> Not clear to me what "expects" really means here. Would it be
> accurate
> to say "requires" instead? If the OS fails to close the windows
> before
> suspend, what happens?
I will change it to 'requires' - These VAS windows have to be closed
before migration so that these windows / credits will be available to
other LPARs on the source machine.
We should see failures only with HCALL to close windows. Since the
migration can not be stopped, continue to close all windows (print
error messages and ignore HCALL failures). These windows belong to VAS
engine on source system, so can not be used them on the destination
machine.
>
>
> > This handler is called before pseries_suspend() to close these
> > windows and again invoked after migration. All active windows
> > for both default and QoS types will be closed and mark them
> > in-active and reopened after migration with this handler.
> > During the migration, the user space receives paste instruction
> > failure if it issues copy/paste on these in-active windows.
>
> OK, I assume that's tolerable to existing users, is that correct?
> I.e.
> users should already be prepared to incur arbitrary paste instruction
> failures.
Yes, the user space or the nxz library has to fall back to SW solution
(if the library supports) or manage with existing windows like closing
the not frequently used ones. We expect the library to make the
necessary modifications.
>
> > Signed-off-by: Haren Myneni <haren@linux.ibm.com>
> > ---
> > arch/powerpc/platforms/pseries/mobility.c | 5 ++
> > arch/powerpc/platforms/pseries/vas.c | 86
> > +++++++++++++++++++++++
> > arch/powerpc/platforms/pseries/vas.h | 6 ++
> > 3 files changed, 97 insertions(+)
> >
> > diff --git a/arch/powerpc/platforms/pseries/mobility.c
> > b/arch/powerpc/platforms/pseries/mobility.c
> > index 85033f392c78..70004243e25e 100644
> > --- a/arch/powerpc/platforms/pseries/mobility.c
> > +++ b/arch/powerpc/platforms/pseries/mobility.c
> > @@ -26,6 +26,7 @@
> > #include <asm/machdep.h>
> > #include <asm/rtas.h>
> > #include "pseries.h"
> > +#include "vas.h" /* vas_migration_handler() */
> > #include "../../kernel/cacheinfo.h"
> >
> > static struct kobject *mobility_kobj;
> > @@ -669,12 +670,16 @@ static int pseries_migrate_partition(u64
> > handle)
> > if (ret)
> > return ret;
> >
> > + vas_migration_handler(VAS_SUSPEND);
> > +
>
> vas_migration_handler() can return an error value. Is that OK to
> ignore
> before going into the suspend?
The migration continues even with these failures. So ignoring the
failures from vas_migration_handler.
Suspend operation:
- we should expect failure with close HCALL or if the total credits
does not match with the hypervisor (should not happen)
- continue to close all windows even with HCALL failures with few
windows since these HW resources are specific to machine.
- Display error messages for HCALL failures (for debugging)
Resume operation:
- May see failures from HCALL to open/modify window HCALLs, but should
not expect unless a bug in hypervisor or HW.
- Stop opening windows if sees failure from HCALLs and print error
messages
- It does not stop migration, but the nxz library can see continue
failures for many in-active windows.
>
> > ret = pseries_suspend(handle);
> > if (ret == 0)
> > post_mobility_fixup();
> > else
> > pseries_cancel_migration(handle, ret);
> >
> > + vas_migration_handler(VAS_RESUME);
> > +
>
> No concerns here though. Nothing to be done about errors encountered
> in
> the resume path.
Correct as mentioned above ignoring error from VAS migration hanlder.
Thanks
Haren
>
> > return ret;
> > }
> >
> > diff --git a/arch/powerpc/platforms/pseries/vas.c
> > b/arch/powerpc/platforms/pseries/vas.c
> > index e4797fc73553..b53e3fe02971 100644
> > --- a/arch/powerpc/platforms/pseries/vas.c
> > +++ b/arch/powerpc/platforms/pseries/vas.c
> > @@ -873,6 +873,92 @@ static struct notifier_block pseries_vas_nb =
> > {
> > .notifier_call = pseries_vas_notifier,
> > };
> >
> > +/*
> > + * For LPM, all windows have to be closed on the source partition
> > + * before migration and reopen them on the destination partition
> > + * after migration. So closing windows during suspend and
> > + * reopen them during resume.
> > + */
> > +int vas_migration_handler(int action)
> > +{
> > + struct hv_vas_cop_feat_caps *hv_caps;
> > + struct vas_cop_feat_caps *caps;
> > + int lpar_creds, new_creds = 0;
> > + struct vas_caps *vcaps;
> > + int i, rc = 0;
> > +
> > + hv_caps = kmalloc(sizeof(*hv_caps), GFP_KERNEL);
> > + if (!hv_caps)
> > + return -ENOMEM;
> > +
> > + mutex_lock(&vas_pseries_mutex);
> > +
> > + for (i = 0; i < VAS_MAX_FEAT_TYPE; i++) {
> > + vcaps = &vascaps[i];
> > + caps = &vcaps->caps;
> > + lpar_creds = atomic_read(&caps->target_creds);
> > +
> > + rc = h_query_vas_capabilities(H_QUERY_VAS_CAPABILITIES,
> > + vcaps->feat,
> > + (u64)virt_to_phys(hv_caps
> > ));
> > + if (!rc) {
> > + new_creds = be16_to_cpu(hv_caps-
> > >target_lpar_creds);
> > + /*
> > + * Should not happen. But incase print
> > messages, close
> > + * all windows in the list during suspend and
> > reopen
> > + * windows based on new lpar_creds on the
> > destination
> > + * system.
> > + */
> > + if (lpar_creds != new_creds) {
> > + pr_err("state(%d): lpar creds: %d HV
> > lpar creds: %d\n",
> > + action, lpar_creds, new_creds);
> > + pr_err("Used creds: %d, Active creds:
> > %d\n",
> > + atomic_read(&caps->used_creds),
> > + vcaps->num_wins - vcaps-
> > >close_wins);
> > + }
> > + } else {
> > + pr_err("state(%d): Get VAS capabilities failed
> > with %d\n",
> > + action, rc);
> > + /*
> > + * We can not stop migration with the current
> > lpm
> > + * implementation. So continue closing all
> > windows in
> > + * the list (during suspend) and return without
> > + * opening windows (during resume) if VAS
> > capabilities
> > + * HCALL failed.
> > + */
> > + if (action == VAS_RESUME)
> > + goto out;
> > + }
> > +
> > + switch (action) {
> > + case VAS_SUSPEND:
> > + rc = reconfig_close_windows(vcaps, vcaps-
> > >num_wins,
> > + true);
> > + break;
> > + case VAS_RESUME:
> > + atomic_set(&caps->target_creds, new_creds);
> > + rc = reconfig_open_windows(vcaps, new_creds,
> > true);
> > + break;
> > + default:
> > + /* should not happen */
> > + pr_err("Invalid migration action %d\n",
> > action);
> > + rc = -EINVAL;
> > + goto out;
> > + }
> > +
> > + /*
> > + * Ignore errors during suspend and return for resume.
> > + */
> > + if (rc && (action == VAS_RESUME))
> > + goto out;
> > + }
> > +
> > +out:
> > + mutex_unlock(&vas_pseries_mutex);
> > + kfree(hv_caps);
> > + return rc;
> > +}
>
> The control flow with respect to releasing the allocation and the
> mutex
> looks correct to me. I also verified that H_QUERY_VAS_CAPABILITIES
> does
> not return a busy/retry status, so this code appears to handle all
> the
> architected statuses for that call.
^ permalink raw reply
* Re: microwatt booting linux-5.7 under verilator
From: Nicholas Piggin @ 2022-02-01 6:27 UTC (permalink / raw)
To: Libre-Soc General Development, linuxppc-dev,
Luke Kenneth Casson Leighton, lkcl, openpower-hdl-cores
In-Reply-To: <994E627C-0194-4634-8DBC-0845493E6744@gmail.com>
Excerpts from lkcl's message of January 31, 2022 2:19 pm:
>
>
> On January 31, 2022 3:31:41 AM UTC, Nicholas Piggin <npiggin@gmail.com> wrote:
>>Hi Luke,
>>
>>Interesting to read about the project, thanks for the post.
>
> no problem. it's been i think 18 years since i last did linux kernel work.
>
>>> i also had to fix a couple of things in the linux kernel source
>>> https://git.kernel.org/pub/scm/linux/kernel/git/joel/microwatt.git
>>
>>I think these have mostly (all?) been upstreamed now.
>
> i believe so, although last i checked (6 months?) there was some of dts still to do. instructions online all tend to refer to joel or benh's tree(s)
>
>>> this led me to add support for CONFIG_KERNEL_UNCOMPRESSED
>>> and cut that time entirely, hence why you can see this in the console
>>log:
>>>
>>> 0x5b0e10 bytes of uncompressed data copied
>>
>>Interesting, it looks like your HAVE_KERNEL_UNCOMPRESSED support
>>patch is pretty trivial.
>
> yeah i was really surprised, it was all there
>
>> We should be able to upstream it pretty
>>easily I think?
>
> don't see why not.
Okay then we should.
>
> the next interesting thing which would save another hour when emulating HDL at this astoundingly-slow speed of sub-1000 instructions per second would be in-place execution: no memcpy, just jump.
>
> i seem to recall this (inplace execution) being a standard option back in 2003 when i was doing xda-developers wince smartphone reverse-emgineering, although with it being 19 years ago i could be wrong
Not sure of the details on that. Is it memcpy()ing out of ROM or RAM to
RAM? Is this in the arch boot code? (I don't know very well).
>
> other areas are the memset before VM is set up, followed by memset *again* on.individual pages once created. those are an hour each
Seems like we could should avoid the duplication and maybe be able to
add an option to skip zeroing (I thought there was one, maybe thinking
of something else).
>
> another hour is spent on early device tree flat walking.
Are you using optimize for size? That can result in much slower code in
some places. In skiboot we compile some of the string.h library code
with -O2 for example.
Thanks,
Nick
>
> one very big one (90+ mins) is the sysfs binary tree walk. i'm sure even just saving the last node in a 1-entry cache would improve time there, or, better, a 4-entry cache (one per level)
>
> although it sounds weird talking in a timeframe that is literally 100,000 times slower than what anyone else is used to, if improved it results in dramatic reduction in boot times for embedded IoT e.g BMC systems.
>
>>> however in the interim, the attached patch suffices by manually
>>> altering the clock in microwatt.dts to match that of the SYSCON
>>> parameter.
>>
>>There is a dt_fixup_clock() that's used by a few platforms. Can we
>>read that parameter say in linux/arch/powerpc/boot/microwatt.c
>>platform_init() and fix it up there?
>>
>>How do you even read the SYSCON parameter for frequency?
>
> SYSCON is just a term for a memory-mapped wishbone ROM which contains a crude easily-decoded binary form of devicetree.
>
> when you read 0xc0001000 (say) its contents tell you the clock speed.
>
> at 0xc0001008 is the number of UARTs.
> 0xc0001010 contains the UART0 speed or well you can see the real contents syscon.vhdl
>
> it is _real_ basic but contains everything that
> a cold-start BIOS needs to know, such as "do i even have DRAM, do i have an SPI Flash i can read a second
> stage bootloader from" etc etc
>
> https://github.com/antonblanchard/microwatt/blob/master/syscon.vhdl
>
> Paul said it was always planned to do reading of these params, the entries in devicetree are a temporary hack.
>
> l.
>
^ permalink raw reply
* Re: [PATCH] powerpc: platforms: 52xx: Fix a resource leak in an error handling path
From: Dan Carpenter @ 2022-02-01 6:44 UTC (permalink / raw)
To: Christophe JAILLET
Cc: kernel-janitors, linux-kernel, Paul Mackerras, John Bonesio,
Anatolij Gustschin, linuxppc-dev
In-Reply-To: <dec1496d46ccd5311d0f6e9f9ca4238be11bf6a6.1643440531.git.christophe.jaillet@wanadoo.fr>
On Sat, Jan 29, 2022 at 08:16:04AM +0100, Christophe JAILLET wrote:
> The error handling path of mpc52xx_lpbfifo_probe() and a request_irq() is
> not balanced by a corresponding free_irq().
>
> Add the missing call, as already done in the remove function.
>
> Fixes: 3c9059d79f5e ("powerpc/5200: add LocalPlus bus FIFO device driver")
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
> ---
> Another strange thing is that the remove function has:
> /* Release the bestcomm transmit task */
> free_irq(bcom_get_task_irq(lpbfifo.bcom_tx_task), &lpbfifo);
> but I've not been able to find a corresponding request_irq().
>
> Is it dead code? Is there something missing in the probe?
> (...Is it working?...)
I think you're right that the tx_task IRQ is never allocated.
I'm pretty sure that if you free a zero IRQ then it's a no-op. It won't
find the 0 in the radix tree so irq_to_desc() returns NULL and free_irq()
returns early.
regards,
dan carpenter
^ permalink raw reply
* Re: powerpc: Set crashkernel offset to mid of RMA region
From: kernel test robot @ 2022-02-01 6:50 UTC (permalink / raw)
To: Sourabh Jain, linuxppc-dev, mpe
Cc: mahesh, kbuild-all, hbathini, Abdul haleem
In-Reply-To: <20220128100445.251233-1-sourabhjain@linux.ibm.com>
Hi Sourabh,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on v5.17-rc2 next-20220131]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Sourabh-Jain/powerpc-Set-crashkernel-offset-to-mid-of-RMA-region/20220128-180605
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-randconfig-m031-20220130 (https://download.01.org/0day-ci/archive/20220201/202202011412.n27Qr2sT-lkp@intel.com/config)
compiler: powerpc-linux-gcc (GCC) 11.2.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# https://github.com/0day-ci/linux/commit/60c8e71e56c0e5e321c312f14aad9a2ceb241c63
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Sourabh-Jain/powerpc-Set-crashkernel-offset-to-mid-of-RMA-region/20220128-180605
git checkout 60c8e71e56c0e5e321c312f14aad9a2ceb241c63
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross O=build_dir ARCH=powerpc SHELL=/bin/bash
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>):
powerpc-linux-ld: warning: orphan section `.init.plt' from `drivers/net/ethernet/ti/davinci_cpdma.o' being placed in section `.init.plt'
powerpc-linux-ld: warning: orphan section `.ftrace.tramp' from `drivers/net/ethernet/ti/davinci_cpdma.o' being placed in section `.ftrace.tramp'
powerpc-linux-ld: arch/powerpc/kernel/rtas.o: in function `early_init_dt_scan_rtas':
>> rtas.c:(.init.text+0x2d2): undefined reference to `powerpc_firmware_features'
>> powerpc-linux-ld: rtas.c:(.init.text+0x2d6): undefined reference to `powerpc_firmware_features'
powerpc-linux-ld: rtas.c:(.init.text+0x2de): undefined reference to `powerpc_firmware_features'
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: consolidate the compat fcntl definitions v2
From: Christoph Hellwig @ 2022-02-01 7:40 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arch, linux-s390, Parisc List, the arch/x86 maintainers,
open list:BROADCOM NVRAM DRIVER, Linux Kernel Mailing List,
Guo Ren, sparclinux, linuxppc-dev, Christoph Hellwig, Linux ARM
In-Reply-To: <CAK8P3a1YzdC1ev0FP-Pe0YyjsY+H3dNWErPGtB=zfcs3kVmkyw@mail.gmail.com>
On Mon, Jan 31, 2022 at 11:19:32PM +0100, Arnd Bergmann wrote:
> I think it would be best to merge this through the risc-v tree along
> with the coming compat support
> that depends on it.
Sounds perfect to me!
^ permalink raw reply
* Re: [PATCH 1/5] uapi: remove the unused HAVE_ARCH_STRUCT_FLOCK64 define
From: Christoph Hellwig @ 2022-02-01 7:42 UTC (permalink / raw)
To: Guo Ren
Cc: linux-arch, linux-s390, Parisc List, Arnd Bergmann,
the arch/x86 maintainers, open list:BROADCOM NVRAM DRIVER,
Linux Kernel Mailing List, sparclinux, linuxppc-dev,
Christoph Hellwig, Linux ARM
In-Reply-To: <CAJF2gTTjj8DXByP44DsC47xB2W_88j5Qp7TyEnRQCfUvHQUixA@mail.gmail.com>
On Tue, Feb 01, 2022 at 09:16:27AM +0800, Guo Ren wrote:
> Right?
>
> Seems you've based on an old tree, right?
This was a fairly recent Linus tree. I don't have the tree at hand
right now due to travel, but what changed there recently?
^ permalink raw reply
* Re: [PATCH V4 16/17] riscv: compat: Add COMPAT Kbuild skeletal support
From: Christoph Hellwig @ 2022-02-01 7:44 UTC (permalink / raw)
To: Guo Ren
Cc: Guo Ren, open list:BROADCOM NVRAM DRIVER, sparclinux, linux-riscv,
Christoph Hellwig, linux-arch, linux-s390, Anup Patel,
the arch/x86 maintainers, linux-csky, Christoph Hellwig,
Arnd Bergmann, Linux ARM, Parisc List, Drew Fustini,
Greg Kroah-Hartman, Wang Junqiang, Linux Kernel Mailing List,
Palmer Dabbelt, liush, linuxppc-dev, Wei Fu
In-Reply-To: <CAJF2gTRXDotO1L1FMojQs6msrqvCzA782Pux8rg3AfZgA=y0ew@mail.gmail.com>
On Mon, Jan 31, 2022 at 09:50:58PM +0800, Guo Ren wrote:
> On Mon, Jan 31, 2022 at 8:26 PM Christoph Hellwig <hch@infradead.org> wrote:
> >
> > Given that most rv64 implementations can't run in rv32 mode, what is the
> > failure mode if someone tries it with the compat mode enabled?
> A static linked simple hello_world could still run on a non-compat
> support hardware. But most rv32 apps would meet different userspace
> segment faults.
>
> Current code would let the machine try the rv32 apps without detecting
> whether hw support or not.
Hmm, we probably want some kind of check for not even offer running
rv32 binaries. I guess trying to write UXL some time during early
boot and catching the resulting exception would be the way to go?
>
>
> --
> Best Regards
> Guo Ren
>
> ML: https://lore.kernel.org/linux-csky/
---end quoted text---
^ permalink raw reply
* Re: [PATCH V4 16/17] riscv: compat: Add COMPAT Kbuild skeletal support
From: Guo Ren @ 2022-02-01 9:13 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-arch, linux-s390, Guo Ren, Parisc List, Arnd Bergmann,
Greg Kroah-Hartman, Drew Fustini, Anup Patel, Wang Junqiang,
the arch/x86 maintainers, Linux Kernel Mailing List, linux-csky,
open list:BROADCOM NVRAM DRIVER, Christoph Hellwig,
Palmer Dabbelt, liush, sparclinux, linux-riscv, linuxppc-dev,
Linux ARM, Wei Fu
In-Reply-To: <20220201074457.GC29119@lst.de>
On Tue, Feb 1, 2022 at 3:45 PM Christoph Hellwig <hch@lst.de> wrote:
>
> On Mon, Jan 31, 2022 at 09:50:58PM +0800, Guo Ren wrote:
> > On Mon, Jan 31, 2022 at 8:26 PM Christoph Hellwig <hch@infradead.org> wrote:
> > >
> > > Given that most rv64 implementations can't run in rv32 mode, what is the
> > > failure mode if someone tries it with the compat mode enabled?
> > A static linked simple hello_world could still run on a non-compat
> > support hardware. But most rv32 apps would meet different userspace
> > segment faults.
> >
> > Current code would let the machine try the rv32 apps without detecting
> > whether hw support or not.
>
> Hmm, we probably want some kind of check for not even offer running
> rv32 binaries. I guess trying to write UXL some time during early
> boot and catching the resulting exception would be the way to go?
Emm... I think it's unnecessary. Free rv32 app running won't cause
system problem, just as a wrong elf running. They are U-mode
privileged.
>
> >
> >
> > --
> > Best Regards
> > Guo Ren
> >
> > ML: https://lore.kernel.org/linux-csky/
> ---end quoted text---
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
^ permalink raw reply
* Re: Build regressions/improvements in v5.17-rc2
From: Geert Uytterhoeven @ 2022-02-01 9:15 UTC (permalink / raw)
To: linux-kernel; +Cc: linuxppc-dev
In-Reply-To: <20220131093835.3146981-1-geert@linux-m68k.org>
On Mon, 31 Jan 2022, Geert Uytterhoeven wrote:
> JFYI, when comparing v5.17-rc2[1] to v5.17-rc1[3], the summaries are:
> - build errors: +1/-3
+ error: arch/powerpc/kvm/book3s_64_entry.o: relocation truncated to fit: R_PPC64_REL14 (stub) against symbol `system_reset_common' defined in .text section in arch/powerpc/kernel/head_64.o: => (.text+0x3ec)
powerpc-gcc5/powerpc-allyesconfig
> [1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/26291c54e111ff6ba87a164d85d4a4e134b7315c/ (all 99 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/e783362eb54cd99b2cac8b3a9aeac942e6f6ac07/ (all 99 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH V4 16/17] riscv: compat: Add COMPAT Kbuild skeletal support
From: Arnd Bergmann @ 2022-02-01 9:36 UTC (permalink / raw)
To: Guo Ren
Cc: Guo Ren, open list:BROADCOM NVRAM DRIVER, sparclinux, linux-riscv,
Christoph Hellwig, linux-arch, linux-s390, Anup Patel,
the arch/x86 maintainers, linux-csky, Christoph Hellwig,
Arnd Bergmann, Linux ARM, Parisc List, Drew Fustini, liush,
Wang Junqiang, Linux Kernel Mailing List, Palmer Dabbelt,
Greg Kroah-Hartman, linuxppc-dev, Wei Fu
In-Reply-To: <CAJF2gTTc=zwD__zXwYbO8vmup5evWJtzyiAF9Pm-UVHLJRc5hQ@mail.gmail.com>
On Tue, Feb 1, 2022 at 10:13 AM Guo Ren <guoren@kernel.org> wrote:
> On Tue, Feb 1, 2022 at 3:45 PM Christoph Hellwig <hch@lst.de> wrote:
> > On Mon, Jan 31, 2022 at 09:50:58PM +0800, Guo Ren wrote:
> > > On Mon, Jan 31, 2022 at 8:26 PM Christoph Hellwig <hch@infradead.org> wrote:
> > > >
> > > > Given that most rv64 implementations can't run in rv32 mode, what is the
> > > > failure mode if someone tries it with the compat mode enabled?
> > > A static linked simple hello_world could still run on a non-compat
> > > support hardware. But most rv32 apps would meet different userspace
> > > segment faults.
> > >
> > > Current code would let the machine try the rv32 apps without detecting
> > > whether hw support or not.
> >
> > Hmm, we probably want some kind of check for not even offer running
> > rv32 binaries. I guess trying to write UXL some time during early
> > boot and catching the resulting exception would be the way to go?
>
> Emm... I think it's unnecessary. Free rv32 app running won't cause
> system problem, just as a wrong elf running. They are U-mode
> privileged.
While it's not a security issue, I think it would be helpful to get a
user-readable error message and a machine-readable /proc/cpuinfo
flag to see if a particular system can run rv32 binaries rather than
relying on SIGILL to kill a process.
Arnd
^ permalink raw reply
* Re: [PATCH RFC v1] drivers/base/node: consolidate node device subsystem initialization in node_dev_init()
From: Anatoly Pugachev @ 2022-02-01 10:02 UTC (permalink / raw)
To: David Hildenbrand
Cc: Michal Hocko, linux-ia64, Rafael J. Wysocki, Dave Hansen,
linux-mips, linux-mm, Rich Felker, Paul Mackerras,
Sparc kernel list, linux-riscv, Will Deacon, linux-s390,
Yoshinori Sato, linux-sh, x86, Ingo Molnar, Catalin Marinas,
Albert Ou, Vasily Gorbik, Heiko Carstens, Borislav Petkov,
Paul Walmsley, Thomas Gleixner, linux-arm-kernel, Oscar Salvador,
Thomas Bogendoerfer, Greg Kroah-Hartman, Linux Kernel list,
Palmer Dabbelt, Andrew Morton, linuxppc-dev, David S. Miller
In-Reply-To: <20220128151540.164759-1-david@redhat.com>
On Mon, Jan 31, 2022 at 2:11 PM David Hildenbrand <david@redhat.com> wrote:
>
> ... and call node_dev_init() after memory_dev_init() from driver_init(),
> so before any of the existing arch/subsys calls. All online nodes should
> be known at that point.
>
> This is in line with memory_dev_init(), which initializes the memory
> device subsystem and creates all memory block devices.
>
> Similar to memory_dev_init(), panic() if anything goes wrong, we don't
> want to continue with such basic initialization errors.
>
> The important part is that node_dev_init() gets called after
> memory_dev_init() and after cpu_dev_init(), but before any of the
> relevant archs call register_cpu() to register the new cpu device under
> the node device. The latter should be the case for the current users
> of topology_init().
>
> RFC because I tested only on x86-64 and s390x, I think I cross-compiled all
> applicable architectures except riscv and sparc.
Compiled and boot tested on sparc.
Tested-by: Anatoly Pugachev <matorola@gmail.com> (sparc64)
^ permalink raw reply
* Re: [PATCH RFC v1] drivers/base/node: consolidate node device subsystem initialization in node_dev_init()
From: David Hildenbrand @ 2022-02-01 10:17 UTC (permalink / raw)
To: Oscar Salvador
Cc: Michal Hocko, linux-ia64, Rafael J. Wysocki, Dave Hansen,
linux-mips, linux-mm, Rich Felker, Paul Mackerras, sparclinux,
linux-riscv, Will Deacon, linux-s390, Yoshinori Sato, linux-sh,
x86, Ingo Molnar, Catalin Marinas, Albert Ou, Vasily Gorbik,
Heiko Carstens, Borislav Petkov, Paul Walmsley, Thomas Gleixner,
linux-arm-kernel, Thomas Bogendoerfer, Greg Kroah-Hartman,
linux-kernel, Palmer Dabbelt, Andrew Morton, linuxppc-dev,
David S. Miller
In-Reply-To: <20220131094041.GA15392@linux>
On 31.01.22 10:40, Oscar Salvador wrote:
> On Mon, Jan 31, 2022 at 08:48:54AM +0100, David Hildenbrand wrote:
>> Hi Oscar,
>
> Hi David :-),
>
>> Right, and the idea is that the online state of nodes (+ node/zone
>> ranges) already has to be known at that point in time, because
>> otherwise, we'd be in bigger trouble.
>
> Yeah, I wanted to check where exactly did we mark the nodes online,
> and for the few architectures I checked it happens in setup_arch(),
> which is called very early in start_kernel(), while driver_init()
> gets called through arch_call_rest_init(), which happens at the end
> of the function.
>
> I am not sure whether we want to remark that somehow in the changelog,
> so it is crystal clear that by the time the node_dev_init() gets called,
> we already set the nodes online.
>
> Anyway, just saying, but is fine as is.
I'll adjust the first paragraph to:
... and call node_dev_init() after memory_dev_init() from driver_init(),
so before any of the existing arch/subsys calls. All online nodes should
be known at that point: early during boot, arch code determines node and
zone ranges and sets the relevant nodes online; usually this happens in
setup_arch().
Thanks!
--
Thanks,
David / dhildenb
^ permalink raw reply
* Re: [PATCH V4 16/17] riscv: compat: Add COMPAT Kbuild skeletal support
From: Guo Ren @ 2022-02-01 10:26 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arch, linux-s390, Guo Ren, Parisc List, Greg Kroah-Hartman,
Drew Fustini, Anup Patel, Wang Junqiang, the arch/x86 maintainers,
Linux Kernel Mailing List, linux-csky,
open list:BROADCOM NVRAM DRIVER, Christoph Hellwig,
Palmer Dabbelt, liush, sparclinux, linux-riscv, linuxppc-dev,
Christoph Hellwig, Linux ARM, Wei Fu
In-Reply-To: <CAK8P3a2C7nDGQvopYzi1fe_LWyosp8t9dcBsduYK5k_s_OrCaA@mail.gmail.com>
Hi Arnd & Christoph,
The UXL field controls the value of XLEN for U-mode, termed UXLEN,
which may differ from the
value of XLEN for S-mode, termed SXLEN. The encoding of UXL is the
same as that of the MXL
field of misa, shown in Table 3.1.
Here is the patch. (We needn't exception helper, because we are in
S-mode and UXL wouldn't affect.)
arch/riscv/include/asm/elf.h | 5 ++++-
arch/riscv/include/asm/processor.h | 1 +
arch/riscv/kernel/process.c | 22 ++++++++++++++++++++++
arch/riscv/kernel/setup.c | 5 +++++
4 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/include/asm/elf.h b/arch/riscv/include/asm/elf.h
index 37f1cbdaa242..6baa49c4fba1 100644
--- a/arch/riscv/include/asm/elf.h
+++ b/arch/riscv/include/asm/elf.h
@@ -35,7 +35,10 @@
*/
#define elf_check_arch(x) ((x)->e_machine == EM_RISCV)
-#define compat_elf_check_arch(x) ((x)->e_machine == EM_RISCV)
+#ifdef CONFIG_COMPAT
+#define compat_elf_check_arch compat_elf_check_arch
+extern bool compat_elf_check_arch(Elf32_Ehdr *hdr);
+#endif
#define CORE_DUMP_USE_REGSET
#define ELF_EXEC_PAGESIZE (PAGE_SIZE)
diff --git a/arch/riscv/include/asm/processor.h
b/arch/riscv/include/asm/processor.h
index 9544c138d9ce..8b288ac0d704 100644
--- a/arch/riscv/include/asm/processor.h
+++ b/arch/riscv/include/asm/processor.h
@@ -64,6 +64,7 @@ extern void start_thread(struct pt_regs *regs,
#ifdef CONFIG_COMPAT
extern void compat_start_thread(struct pt_regs *regs,
unsigned long pc, unsigned long sp);
+extern void compat_mode_detect(void);
#define DEFAULT_MAP_WINDOW_64 TASK_SIZE_64
#else
diff --git a/arch/riscv/kernel/process.c b/arch/riscv/kernel/process.c
index 9ebf9a95e5ea..496d09c5d384 100644
--- a/arch/riscv/kernel/process.c
+++ b/arch/riscv/kernel/process.c
@@ -101,6 +101,28 @@ void start_thread(struct pt_regs *regs, unsigned long pc,
}
#ifdef CONFIG_COMPAT
+static bool compat_mode_support __read_mostly = false;
+
+bool compat_elf_check_arch(Elf32_Ehdr *hdr)
+{
+ if (compat_mode_support && (hdr->e_machine == EM_RISCV))
+ return true;
+
+ return false;
+}
+
+void compat_mode_detect(void)
+{
+ unsigned long tmp = csr_read(CSR_STATUS);
+ csr_write(CSR_STATUS, (tmp & ~SR_UXL) | SR_UXL_32);
+
+ if ((csr_read(CSR_STATUS) & SR_UXL) != SR_UXL_32) {
+ csr_write(CSR_STATUS, tmp);
+ return;
+ }
+
+ csr_write(CSR_STATUS, tmp);
+ compat_mode_support = true;
+
+ pr_info("riscv: compat: 32bit U-mode applications support\n");
+}
+
void compat_start_thread(struct pt_regs *regs, unsigned long pc,
unsigned long sp)
{
diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index b42bfdc67482..be131219d549 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -12,6 +12,7 @@
#include <linux/mm.h>
#include <linux/memblock.h>
#include <linux/sched.h>
+#include <linux/compat.h>
#include <linux/console.h>
#include <linux/screen_info.h>
#include <linux/of_fdt.h>
@@ -294,6 +295,10 @@ void __init setup_arch(char **cmdline_p)
setup_smp();
#endif
+#ifdef CONFIG_COMPAT
+ compat_mode_detect();
+#endif
+
riscv_fill_hwcap();
}
On Tue, Feb 1, 2022 at 5:36 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, Feb 1, 2022 at 10:13 AM Guo Ren <guoren@kernel.org> wrote:
> > On Tue, Feb 1, 2022 at 3:45 PM Christoph Hellwig <hch@lst.de> wrote:
> > > On Mon, Jan 31, 2022 at 09:50:58PM +0800, Guo Ren wrote:
> > > > On Mon, Jan 31, 2022 at 8:26 PM Christoph Hellwig <hch@infradead.org> wrote:
> > > > >
> > > > > Given that most rv64 implementations can't run in rv32 mode, what is the
> > > > > failure mode if someone tries it with the compat mode enabled?
> > > > A static linked simple hello_world could still run on a non-compat
> > > > support hardware. But most rv32 apps would meet different userspace
> > > > segment faults.
> > > >
> > > > Current code would let the machine try the rv32 apps without detecting
> > > > whether hw support or not.
> > >
> > > Hmm, we probably want some kind of check for not even offer running
> > > rv32 binaries. I guess trying to write UXL some time during early
> > > boot and catching the resulting exception would be the way to go?
> >
> > Emm... I think it's unnecessary. Free rv32 app running won't cause
> > system problem, just as a wrong elf running. They are U-mode
> > privileged.
>
> While it's not a security issue, I think it would be helpful to get a
> user-readable error message and a machine-readable /proc/cpuinfo
> flag to see if a particular system can run rv32 binaries rather than
> relying on SIGILL to kill a process.
--
2.25.1
>
> Arnd
--
Best Regards
Guo Ren
ML: https://lore.kernel.org/linux-csky/
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox