On Mon, Jan 31, 2022 at 09:50:58PM +0800, Guo Ren wrote:
> On Mon, Jan 31, 2022 at 8:26 PM Christoph Hellwig 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
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?
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!
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
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:
Excerpts from lkcl's message of January 31, 2022 2:19 pm:
>
>
> On January 31, 2022 3:31:41 AM UTC, Nicholas Piggin 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
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 writes:
> > Since the VAS windows belong to the VAS hardware resource, the
> > hypervisor expects the partition to close them
On Tue, Feb 1, 2022 at 11:02 AM Guo Ren wrote:
>
> On Mon, Jan 31, 2022 at 2:49 PM Christoph Hellwig 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.
> >
> >
On Mon, Jan 31, 2022 at 2:49 PM Christoph Hellwig 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
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
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
On Tue, Feb 1, 2022 at 6:19 AM Arnd Bergmann wrote:
>
> On Mon, Jan 31, 2022 at 7:49 AM Christoph Hellwig 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
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
https://bugzilla.kernel.org/show_bug.cgi?id=215389
--- Comment #11 from Erhard F. (erhar...@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
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
On Mon, Jan 31, 2022 at 7:49 AM Christoph Hellwig 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
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,
Nicholas Piggin 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
Nicholas Piggin 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
Hi Haren,
Mostly this seems OK to me. Some questions:
Haren Myneni 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
On Thu, 20 Jan 2022 01:26:00 +0100, Linus Walleij wrote:
> This driver is already relying on the core to provide
> valid GPIO numbers in spi->cs_gpio through
> of_spi_get_gpio_numbers(), so we can switch to letting
> the core use GPIO descriptors instead.
>
> The driver was assigning a local
On 1/31/22 03:27, Thomas Gleixner wrote:
On Sun, Jan 30 2022 at 09:12, Guenter Roeck wrote:
On Fri, Dec 10, 2021 at 11:19:26PM +0100, Thomas Gleixner wrote:
This patch results in the following runtime warning when booting x86
(32 bit) nosmp images from NVME in qemu.
[ 14.825482] nvme nvme0:
On Mon, Jan 31, 2022 at 8:21 PM Christoph Hellwig wrote:
>
> On Sat, Jan 29, 2022 at 08:17:14PM +0800, guo...@kernel.org wrote:
> > From: Guo Ren
> >
> > There are 7 64bit architectures that support Linux COMPAT mode to
> > run 32bit applications. A lot of definitions are duplicate:
> > -
On Mon, Jan 31, 2022 at 8:26 PM Christoph Hellwig 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
On Mon, Jan 31, 2022 at 2:00 PM Christoph Hellwig wrote:
>
> On Mon, Jan 31, 2022 at 01:48:58PM +0100, Arnd Bergmann wrote:
> > I thought that is what the patch does, there is already the normal 64-bit
> > defconfig, and the new makefile target makes this shared with 32-bit
> > to prevent them
Acked-by: Guo Ren
On Mon, Jan 31, 2022 at 2:49 PM Christoph Hellwig 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
On Mon, Jan 31, 2022 at 2:49 PM Christoph Hellwig wrote:
>
> Don't bother to define the symbols empty, just don't use them. That
> makes the intent a little more clear.
>
> Signed-off-by: Christoph Hellwig
> ---
> include/uapi/asm-generic/fcntl.h | 12
>
On Mon, Jan 31, 2022 at 01:48:58PM +0100, Arnd Bergmann wrote:
> I thought that is what the patch does, there is already the normal 64-bit
> defconfig, and the new makefile target makes this shared with 32-bit
> to prevent them from diverging again.
I ment using a common fragment and the deriving
On Mon, Jan 31, 2022 at 1:23 PM Christoph Hellwig wrote:
>
> On Sat, Jan 29, 2022 at 08:17:16PM +0800, guo...@kernel.org wrote:
> > From: Guo Ren
> >
> > Let's follow the origin patch's spirit:
> >
> > The only difference between rv32_defconfig and defconfig is that
> > rv32_defconfig has
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?
On Sat, Jan 29, 2022 at 08:17:16PM +0800, guo...@kernel.org wrote:
> From: Guo Ren
>
> Let's follow the origin patch's spirit:
>
> The only difference between rv32_defconfig and defconfig is that
> rv32_defconfig has CONFIG_ARCH_RV32I=y.
>
> This is helpful to compare rv64-compat-rv32 v.s.
On Sat, Jan 29, 2022 at 08:17:15PM +0800, guo...@kernel.org wrote:
> From: Guo Ren
>
> Make "uapi asm unistd.h" could be used for architectures' COMPAT
> mode. The __SYSCALL_COMPAT is first used in riscv.
>
> Signed-off-by: Guo Ren
> Signed-off-by: Guo Ren
> Reviewed-by: Arnd Bergmann
Looks
On Sat, Jan 29, 2022 at 08:17:14PM +0800, guo...@kernel.org wrote:
> From: Guo Ren
>
> There are 7 64bit architectures that support Linux COMPAT mode to
> run 32bit applications. A lot of definitions are duplicate:
> - COMPAT_USER_HZ
> - COMPAT_RLIM_INFINITY
> - COMPAT_OFF_T_MAX
> -
Looks good,
Reviewed-by: Christoph Hellwig
Looks good,
Reviewed-by: Christoph Hellwig
Reviewed-by: Guo Ren
On Mon, Jan 31, 2022 at 2:49 PM Christoph Hellwig wrote:
>
> Signed-off-by: Christoph Hellwig
> ---
> include/uapi/asm-generic/fcntl.h | 2 --
> tools/include/uapi/asm-generic/fcntl.h | 2 --
> 2 files changed, 4 deletions(-)
>
> diff --git
On Sun, Jan 30 2022 at 09:12, Guenter Roeck wrote:
> On Fri, Dec 10, 2021 at 11:19:26PM +0100, Thomas Gleixner wrote:
> This patch results in the following runtime warning when booting x86
> (32 bit) nosmp images from NVME in qemu.
>
> [ 14.825482] nvme nvme0: 1/0/0 default/read/poll queues
>
https://bugzilla.kernel.org/show_bug.cgi?id=206669
--- Comment #19 from John Paul Adrian Glaubitz (glaub...@physik.fu-berlin.de)
---
In case any runs into this issue, a workaround is disabling "dynamic_mt_modes":
# echo 0 > /sys/module/kvm_hv/parameters/dynamic_mt_modes
This fixes the crashes
On Fri, Jan 28, 2022 at 04:15:40PM +0100, David Hildenbrand 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
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
On Mon, 2022-01-31 at 04:19 +, lkcl wrote:
> > 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.
Talking of which, if we're going to make use if it (we
arch/powerpc/include/asm/nohash/{32/64}/pgtable.h has
#define __HAVE_ARCH_PTE_SAME
#define pte_same(A,B) ((pte_val(A) ^ pte_val(B)) == 0)
include/linux/pgtable.h has
#ifndef __HAVE_ARCH_PTE_SAME
static inline int pte_same(pte_t pte_a, pte_t pte_b)
{
42 matches
Mail list logo
