From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
---
arch/arm/Kconfig | 16 +---
1 file changed, 9
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
---
arch/sh/mm/Kconfig | 17 +
1 file changed, 9
From: "Mike Rapoport (IBM)"
PowerPC defines ranges for ARCH_FORCE_MAX_ORDER some of which are
insanely allowing MAX_ORDER up to 63, which implies maximal contiguous
allocation size of 2^63 pages.
Drop bogus definitions of ranges for ARCH_FORCE_MAX_ORDER and leave it a
simple integer with
On Thu, Mar 23, 2023 at 2:24 AM Mike Rapoport wrote:
>
> From: "Mike Rapoport (IBM)"
>
> The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
> describe this configuration option.
>
> Update both to actually describe what this option does.
>
> Signed-off-by: Mike Rapoport (IBM)
On 20/03/2023 08.03, Nicholas Piggin wrote:
This adds the non-migration variant of the SPR test to the matrix,
which can be simpler to run and debug.
Reviewed-by: Thomas Huth
Signed-off-by: Nicholas Piggin
---
powerpc/unittests.cfg | 4
1 file changed, 4 insertions(+)
diff --git
On Mon, 2023-03-06 at 15:33 -0600, Nathan Lynch via B4 Relay wrote:
> From: Nathan Lynch
>
> The kernel can handle retrying RTAS function calls in response to
> -2/990x in the sys_rtas() handler instead of relaying the
> intermediate
> status to user space.
>
> Justifications:
>
> * Currently
From: "Mike Rapoport (IBM)"
nios2 defines range for ARCH_FORCE_MAX_ORDER allowing MAX_ORDER
up to 19, which implies maximal contiguous allocation size of 2^19
pages or 2GiB.
Drop bogus definition of ranges for ARCH_FORCE_MAX_ORDER and leave it a
simple integer with sensible default.
Users that
On Thu, Mar 23, 2023 at 11:21:45AM +0200, Mike Rapoport wrote:
> From: "Mike Rapoport (IBM)"
>
> The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
> describe this configuration option.
>
> Update both to actually describe what this option does.
>
> Signed-off-by: Mike
On Thu, Mar 23, 2023 at 10:15:33AM +, Catalin Marinas wrote:
> On Thu, Mar 23, 2023 at 11:21:44AM +0200, Mike Rapoport wrote:
> > From: "Mike Rapoport (IBM)"
> >
> > It is not a good idea to change fundamental parameters of core memory
> > management. Having predefined ranges suggests that
While running rcutorture tests from LTP on an IBM Power10 server booted with
6.3.0-rc3-next-20230322 following warning is observed:
[ 3629.242831] [ cut here ]
[ 3629.242835] WARNING: CPU: 8 PID: 614614 at kernel/workqueue.c:3182
__flush_work.isra.44+0x44/0x370
[
On Thu, Mar 23, 2023 at 11:21:42AM +0200, Mike Rapoport wrote:
> From: "Mike Rapoport (IBM)"
>
> Hi,
>
> Several architectures have ARCH_FORCE_MAX_ORDER in their Kconfig and
> they all have wrong and misleading prompt and help text for this option.
>
> Besides, some define insane limits for
On Mon, 2023-03-06 at 15:33 -0600, Nathan Lynch via B4 Relay wrote:
> From: Nathan Lynch
>
> Add lockdep annotations for the following properties that must hold:
>
> * Any error log retrieval must be atomically coupled with the prior
> RTAS call, without a window for another RTAS call to
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
---
arch/arm64/Kconfig | 25 -
1 file
From: "Mike Rapoport (IBM)"
It is not a good idea to change fundamental parameters of core memory
management. Having predefined ranges suggests that the values within
those ranges are sensible, but one has to *really* understand
implications of changing MAX_ORDER before actually amending it and
From: "Mike Rapoport (IBM)"
It is enough to keep default values for base and huge pages without
letting users to override ARCH_FORCE_MAX_ORDER.
Drop the prompt to make the option unvisible in *config.
Signed-off-by: Mike Rapoport (IBM)
---
arch/ia64/Kconfig | 3 +--
1 file changed, 1
On Thu, Mar 23, 2023 at 11:21:44AM +0200, Mike Rapoport wrote:
> From: "Mike Rapoport (IBM)"
>
> It is not a good idea to change fundamental parameters of core memory
> management. Having predefined ranges suggests that the values within
> those ranges are sensible, but one has to *really*
Benjamin Gray writes:
> The ISA 3.1B hashst and hashchk instructions use a per-cpu SPR HASHKEYR
> to hold a key used in the hash calculation. This key should be different
> for each process to make it harder for a malicious process to recreate
> valid hash values for a victim process.
>
> Add
On 20/03/2023 08.03, Nicholas Piggin wrote:
KVM development on powerpc has moved to the Linux on Power mailing list,
as per linux.git commit 19b27f37ca97d ("MAINTAINERS: Update powerpc KVM
entry").
Signed-off-by: Nicholas Piggin
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1
The series looks fine to me. How should we merge it?
From: "Mike Rapoport (IBM)"
The default value of ARCH_FORCE_MAX_ORDER matches the generic default
defined in the MM code, the architecture does not support huge pages, so
there is no need to keep ARCH_FORCE_MAX_ORDER option available.
Drop it.
Signed-off-by: Mike Rapoport (IBM)
---
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
---
arch/m68k/Kconfig.cpu | 16 +---
1 file changed, 9
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
---
arch/nios2/Kconfig | 16 +---
1 file changed, 9
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
---
arch/sparc/Kconfig | 16 +---
1 file changed, 9
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
---
arch/xtensa/Kconfig | 16 +---
1 file changed, 9
Nathan Lynch via B4 Relay writes:
> From: Nathan Lynch
>
> The kernel can handle retrying RTAS function calls in response to
> -2/990x in the sys_rtas() handler instead of relaying the intermediate
> status to user space.
This looks good in general.
One query ...
> diff --git
Hi,
I am unable to boot upstream kernels from v5.16 to the latest upstream
kernel on a maxconfig system. (Machine config details given below)
At boot, we see a series of messages like the below.
dracut-initqueue[13917]: Warning: dracut-initqueue: timeout, still waiting for
following initqueue
kvmppc_vcore_create() might not be able to allocate memory through
kzalloc. In that case the kvm->arch.online_vcores shouldn't be
incremented.
Add a check for kzalloc failure and return with -ENOMEM from
kvmppc_core_vcpu_create_hv().
Signed-off-by: Kautuk Consul
---
arch/powerpc/kvm/book3s_hv.c
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
---
arch/powerpc/Kconfig | 16 +---
1 file changed, 9
From: "Mike Rapoport (IBM)"
sh defines insane ranges for ARCH_FORCE_MAX_ORDER allowing MAX_ORDER
up to 63, which implies maximal contiguous allocation size of 2^63
pages.
Drop bogus definitions of ranges for ARCH_FORCE_MAX_ORDER and leave it a
simple integer with sensible defaults.
Users that
From: "Mike Rapoport (IBM)"
Hi,
Several architectures have ARCH_FORCE_MAX_ORDER in their Kconfig and
they all have wrong and misleading prompt and help text for this option.
Besides, some define insane limits for possible values of
ARCH_FORCE_MAX_ORDER, some carefully define ranges only for a
Exception processing pmu-events/arch/powerpc/power9/other.json
Traceback (most recent call last):
File "pmu-events/jevents.py", line 997, in
main()
File "pmu-events/jevents.py", line 979, in main
ftw(arch_path, [], preprocess_one_file)
File "pmu-events/jevents.py", line 935, in ftw
On Thu, Mar 23, 2023 at 04:30:01PM +0200, Andy Shevchenko wrote:
> On Wed, Mar 22, 2023 at 02:28:04PM -0500, Bjorn Helgaas wrote:
> > On Mon, Mar 20, 2023 at 03:16:30PM +0200, Andy Shevchenko wrote:
> ...
>
> > > + pci_dev_for_each_resource_p(dev, r) {
> > > /* zap the 2nd function of
On Thu, Mar 23, 2023 at 10:02:38AM -0500, Bjorn Helgaas wrote:
> On Thu, Mar 23, 2023 at 04:30:01PM +0200, Andy Shevchenko wrote:
...
> I poked around looking for similar patterns elsewhere with:
>
> git grep "#define.*for_each_.*_p("
> git grep "#define.*for_each_.*_idx("
>
> I didn't
Andrew Donnellan writes:
> On Mon, 2023-03-06 at 15:33 -0600, Nathan Lynch via B4 Relay wrote:
>> From: Nathan Lynch
>>
>> The function name va_rtas_call_unlocked() is confusing: it may be
>> called with or without rtas_lock held. Rename it to va_rtas_call().
>>
>> Signed-off-by: Nathan Lynch
We introduce a new HAS_IOPORT Kconfig option to indicate support for I/O
Port access. In a future patch HAS_IOPORT=n will disable compilation of
the I/O accessor functions inb()/outb() and friends on architectures
which can not meaningfully support legacy I/O spaces such as s390.
The following
Andrew Donnellan writes:
> On Mon, 2023-03-06 at 15:33 -0600, Nathan Lynch via B4 Relay wrote:
>> From: Nathan Lynch
>>
>> Any caller of rtas_call_unlocked() must provide an rtas_args
>> parameter
>> block distinct from the core rtas_args buffer used by the rtas_call()
>> path. It's an
Michael Ellerman writes:
> Nathan Lynch via B4 Relay writes:
>> From: Nathan Lynch
>>
>> The kernel can handle retrying RTAS function calls in response to
>> -2/990x in the sys_rtas() handler instead of relaying the intermediate
>> status to user space.
>
> This looks good in general.
>
> One
On Thu, Mar 23, 2023 at 10:23 AM Mike Rapoport wrote:
> From: "Mike Rapoport (IBM)"
>
> The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
> describe this configuration option.
>
> Update both to actually describe what this option does.
>
> Signed-off-by: Mike Rapoport (IBM)
On 17/03/2023 13.36, Nicholas Piggin wrote:
This is a very basic detection that does not include all new SPRs.
Signed-off-by: Nicholas Piggin
---
powerpc/sprs.c | 22 ++
1 file changed, 22 insertions(+)
Reviewed-by: Thomas Huth
On 23 Mar 2023, at 6:37, Mike Rapoport wrote:
> On Thu, Mar 23, 2023 at 10:15:33AM +, Catalin Marinas wrote:
>> On Thu, Mar 23, 2023 at 11:21:44AM +0200, Mike Rapoport wrote:
>>> From: "Mike Rapoport (IBM)"
>>>
>>> It is not a good idea to change fundamental parameters of core memory
>>>
On 20/03/2023 08.03, Nicholas Piggin wrote:
This consolidates several implementations, and it no longer leaves
MSR[EE] enabled after the decrementer interrupt is handled, but
rather disables it on return.
The handler no longer allows a continuous ticking, but rather dec
has to be re-armed and
On 20/03/2023 08.03, Nicholas Piggin wrote:
The VPA is a(n optional) memory structure shared between the hypervisor
and operating system, defined by PAPR. This test defines the structure
and adds registration, deregistration, and a few simple sanity tests.
Signed-off-by: Nicholas Piggin
---
On Wed, Mar 22, 2023 at 02:28:04PM -0500, Bjorn Helgaas wrote:
> On Mon, Mar 20, 2023 at 03:16:30PM +0200, Andy Shevchenko wrote:
...
> > + pci_dev_for_each_resource_p(dev, r) {
> > /* zap the 2nd function of the winbond chip */
> > - if (dev->resource[i].flags &
On Thu, Mar 23, 2023 at 6:11 AM Arnaldo Carvalho de Melo
wrote:
>
> Exception processing pmu-events/arch/powerpc/power9/other.json
> Traceback (most recent call last):
> File "pmu-events/jevents.py", line 997, in
> main()
> File "pmu-events/jevents.py", line 979, in main
>
Hi Andy,
On Thu, Mar 23, 2023 at 4:15 PM Andy Shevchenko
wrote:
> On Thu, Mar 23, 2023 at 10:02:38AM -0500, Bjorn Helgaas wrote:
> > I poked around looking for similar patterns elsewhere with:
> > git grep "#define.*for_each_.*_p("
> > git grep "#define.*for_each_.*_idx("
> >
> > I didn't
On Tue, 2023-03-14 at 13:37 +0100, Johannes Berg wrote:
> On Tue, 2023-03-14 at 13:11 +0100, Niklas Schnelle wrote:
> > --- a/arch/um/Kconfig
> > +++ b/arch/um/Kconfig
> > @@ -56,6 +56,7 @@ config NO_IOPORT_MAP
> >
> > config ISA
> > bool
> > + depends on HAS_IOPORT
> >
>
> config ISA
On 20/03/2023 08.03, Nicholas Piggin wrote:
This enables HV privilege registers to be tested with the powernv
machine.
Signed-off-by: Nicholas Piggin
---
powerpc/sprs.c | 31 ---
1 file changed, 24 insertions(+), 7 deletions(-)
diff --git a/powerpc/sprs.c
On 20/03/2023 08.03, Nicholas Piggin wrote:
This is a very basic detection that does not include all new SPRs.
Signed-off-by: Nicholas Piggin
---
powerpc/sprs.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/powerpc/sprs.c b/powerpc/sprs.c
index ba4ddee..6ee6dba
On 20/03/2023 08.03, Nicholas Piggin wrote:
A significant rework that builds an array of 'struct spr', where each
element describes an SPR. This makes various metadata about the SPR
like name and access type easier to carry and use.
Hypervisor privileged registers are described despite not
Hi Mike,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on 51551d71edbc998fd8c8afa7312db3d270f5998e]
url:
https://github.com/intel-lab-lkp/linux/commits/Mike-Rapoport/arm-reword-ARCH_FORCE_MAX_ORDER-prompt-and-help-text/20230323-172512
base
On Thu, Mar 23, 2023 at 04:55:54PM +0530, Sachin Sant wrote:
> While running rcutorture tests from LTP on an IBM Power10 server booted with
> 6.3.0-rc3-next-20230322 following warning is observed:
>
> [ 3629.242831] [ cut here ]
> [ 3629.242835] WARNING: CPU: 8 PID: 614614
On 20/03/2023 08.03, Nicholas Piggin wrote:
This is a basic first pass at powernv support using OPAL (skiboot)
firmware.
The ACCEL is a bit clunky, now defaulting to tcg for powernv machine.
It also does not yet run in the run_tests.sh batch process, more work
is needed to exclude certain tests
On 22/03/23 15:04, Peter Zijlstra wrote:
> @@ -798,14 +794,20 @@ static void smp_call_function_many_cond(
> }
>
> /*
> + * Trace each smp_function_call_*() as an IPI, actual IPIs
> + * will be traced with
>
The pci_bus_for_each_resource() can hide the iterator loop since
it may be not used otherwise. With this, we may drop that iterator
variable definition.
Signed-off-by: Andy Shevchenko
Reviewed-by: Krzysztof Wilczyński
---
drivers/eisa/pci_eisa.c | 4 ++--
1 file changed, 2 insertions(+), 2
The pci_bus_for_each_resource() can hide the iterator loop since
it may be not used otherwise. With this, we may drop that iterator
variable definition.
Signed-off-by: Andy Shevchenko
Reviewed-by: Krzysztof Wilczyński
Acked-by: Dominik Brodowski
---
drivers/pcmcia/rsrc_nonstatic.c | 9
On 23/03/23 18:41, Peter Zijlstra wrote:
> On Thu, Mar 23, 2023 at 04:25:25PM +, Valentin Schneider wrote:
>> On 22/03/23 15:04, Peter Zijlstra wrote:
>> > @@ -798,14 +794,20 @@ static void smp_call_function_many_cond(
>> >}
>> >
>> >/*
>> > + * Trace each
Haren Myneni writes:
> The hypervisor supports user-mode NX from Power10. pseries_vas_dlpar_cpu()
> is called from lparcfg_write() to update VAS windows for DLPAR event in
> shared processor mode and the kernel gets -ENOTSUPP for HCALLs if the
> user-mode NX is not supported. The current VAS
Hi Mike,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on 51551d71edbc998fd8c8afa7312db3d270f5998e]
url:
https://github.com/intel-lab-lkp/linux/commits/Mike-Rapoport/arm-reword-ARCH_FORCE_MAX_ORDER-prompt-and-help-text/20230323-172512
base
Replace open-coded implementations of pci_resource_n() in pci.h.
Signed-off-by: Andy Shevchenko
---
include/linux/pci.h | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 70a4684d5f26..9539cf63fe5e 100644
---
kernel.h is being used as a dump for all kinds of stuff for a long time.
The COUNT_ARGS() and CONCATENATE() macros may be used in some places
without need of the full kernel.h dependency train with it.
Here is the attempt on cleaning it up by splitting out these macros().
Signed-off-by: Andy
On Thu, Mar 23, 2023 at 04:25:25PM +, Valentin Schneider wrote:
> On 22/03/23 15:04, Peter Zijlstra wrote:
> > @@ -798,14 +794,20 @@ static void smp_call_function_many_cond(
> > }
> >
> > /*
> > +* Trace each smp_function_call_*() as an IPI, actual IPIs
>
On Thu, Mar 23, 2023 at 11:00:59PM +0530, Sachin Sant wrote:
>
> >> [ 3629.243407] NIP [7fff8cd39558] 0x7fff8cd39558
> >> [ 3629.243410] LR [00010d800398] 0x10d800398
> >> [ 3629.243413] --- interrupt: c00
> >> [ 3629.243415] Code: 419dffa4 e93a0078 3941 552907be 2f89 7d20579e
>
Andrew Donnellan writes:
> On Mon, 2023-03-06 at 15:33 -0600, Nathan Lynch via B4 Relay wrote:
>> * We can expect performance improvements for existing sys_rtas()
>> users, not only because of overall reduction in the number of
>> system
>> calls issued, but also due to the better handling
>> [ 3629.243407] NIP [7fff8cd39558] 0x7fff8cd39558
>> [ 3629.243410] LR [00010d800398] 0x10d800398
>> [ 3629.243413] --- interrupt: c00
>> [ 3629.243415] Code: 419dffa4 e93a0078 3941 552907be 2f89 7d20579e
>> 0b09 e95a0078 e91a0080 3921 7fa85000 7d204f9e <0b09>
Refactor pci_bus_for_each_resource() in the same way as it's done in
pci_dev_for_each_resource() case. This will allow to hide iterator
inside the loop, where it's not used otherwise.
No functional changes intended.
Signed-off-by: Andy Shevchenko
Reviewed-by: Krzysztof Wilczyński
---
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 7c4a254d78f89546d0e74a40617ef24c6151c8d1 Add linux-next specific
files for 20230323
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202303161521.jbgbafjj-...@intel.com
https
From: Mika Westerberg
Instead of open-coding it everywhere introduce a tiny helper that can be
used to iterate over each resource of a PCI device, and convert the most
obvious users into it.
While at it drop doubled empty line before pdev_sort_resources().
No functional changes intended.
Provide two new helper macros to iterate over PCI device resources and
convert users.
Looking at it, refactor existing pci_bus_for_each_resource() and convert
users accordingly.
Changelog v7:
- made both macros to share same name (Bjorn)
- split out the pci_resource_n() conversion (Bjorn)
Hi,
I got a report sent to me from mariadb, in where 5.10.158 works fine and
5.10.162 is broken. And in fact, current 6.3-rc also fails the test
case. Beware that this email is long, as I'm trying to include
everything that may be relevant...
The test case in question is pretty simple. On debian
On Wed, Mar 22, 2023 at 11:26 AM Nick Desaulniers
wrote:
>
> On Fri, Feb 24, 2023 at 7:58 AM Björn Töpel wrote:
> >
> > Alexandre Ghiti writes:
> >
> > > +cc linux-kbuild, llvm, Nathan, Nick
> > >
> > > On 2/15/23 15:36, Alexandre Ghiti wrote:
> > >> From: Alexandre Ghiti
> > >>
> > > I tried
> 2023年3月23日 07:29，Christoph Hellwig 写道：
>
> The series looks fine to me. How should we merge it?
Perhaps go through dma-mapping tree?
Thanks
- Jiaxun
On Thu, 2023-03-23 at 08:50 -0700, Ian Rogers wrote:
> On Thu, Mar 23, 2023 at 6:11 AM Arnaldo Carvalho de Melo
> wrote:
> >
> > Exception processing pmu-events/arch/powerpc/power9/other.json
> > Traceback (most recent call last):
> > File "pmu-events/jevents.py", line 997, in
> > main()
Nathan Lynch writes:
>
> aside: does anyone know if the display_status() code is worth keeping?
> It looks like it is used to drive the 16-character wide physical LCD I
> remember seeing on P4-era and older machines. Is it a vestige of
> non-LPAR pseries that should be dropped, or is it perhaps
On Fri, Mar 24, 2023 at 05:34:18AM +0800, kernel test robot wrote:
> tree/branch:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> branch HEAD: 7c4a254d78f89546d0e74a40617ef24c6151c8d1 Add linux-next
> specific files for 20230323
>
> Err
On Mon, Mar 06, 2023 at 11:29:53AM -0600, Timothy Pearson wrote:
> This patch series reenables VFIO support on POWER systems. It
> is based on Alexey Kardashevskiys's patch series, rebased and
> successfully tested under QEMU with a Marvell PCIe SATA controller
> on a POWER9 Blackbird host.
>
>
Michael,
Any comments on this one?
On Fri, Feb 24, 2023 at 11:02:31AM +, Christophe Leroy wrote:
>
>
> Le 24/02/2023 à 11:39, Nysal Jan K.A a écrit :
> > [Vous ne recevez pas souvent de courriers de ny...@linux.ibm.com. Découvrez
> > pourquoi ceci est important à
>>> Hello, Sachin, and it looks like you hit something that Zqiang and I
>>> have been tracking down. I am guessing that you were using modprobe
>>> and rmmod to make this happen, and that this happened at rmmod time.
>>>
>> Yes, the LTP test script rcu_torture.sh relies on modprobe to
On Thu, Mar 23, 2023 at 09:07:31PM +, Jiaxun Yang wrote:
>
>
> > 2023年3月23日 07:29，Christoph Hellwig 写道：
> >
> > The series looks fine to me. How should we merge it?
>
> Perhaps go through dma-mapping tree?
Is patch a 6.3 candidate or should all of it go into 6.4?
Add tests that exercise basic functions of the kvm selftests framework,
guest creation, ucalls, hcalls, copying data between guest and host,
interrupts and page faults.
These don't stress KVM so much as being useful when developing support
for powerpc.
Signed-off-by: Nicholas Piggin
---
Implement KVM selftests support for powerpc (Book3S-64).
ucalls are implemented with an unsuppored PAPR hcall number which causes
KVM to exit to userspace.
Virtual memory is only implemented for 64K page size and the radix MMU,
and only the base page size is supported for now.
Guest interrupt
Hi,
This series adds initial KVM selftests support for powerpc
(64-bit, BookS). It spans 3 maintainers but it does not really
affect arch/powerpc, and it is well contained in selftests
code, just touches some makefiles and a tiny bit headers so
conflicts should be unlikely and trivial.
Hey Paolo
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
Acked-by: Kirill A. Shutemov
---
arch/arm64/Kconfig | 24
From: "Mike Rapoport (IBM)"
The default value of ARCH_FORCE_MAX_ORDER matches the generic default
defined in the MM code, the architecture does not support huge pages, so
there is no need to keep ARCH_FORCE_MAX_ORDER option available.
Drop it.
Signed-off-by: Mike Rapoport (IBM)
Acked-by:
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
Acked-by: Kirill A. Shutemov
Acked-by: Geert Uytterhoeven
---
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
Acked-by: Kirill A. Shutemov
---
arch/nios2/Kconfig | 16
From: "Mike Rapoport (IBM)"
It is enough to keep default values for base and huge pages without
letting users to override ARCH_FORCE_MAX_ORDER.
Drop the prompt to make the option unvisible in *config.
Signed-off-by: Mike Rapoport (IBM)
Acked-by: Kirill A. Shutemov
---
arch/ia64/Kconfig | 3
From: "Mike Rapoport (IBM)"
sh defines insane ranges for ARCH_FORCE_MAX_ORDER allowing MAX_ORDER
up to 63, which implies maximal contiguous allocation size of 2^63
pages.
Drop bogus definitions of ranges for ARCH_FORCE_MAX_ORDER and leave it a
simple integer with sensible defaults.
Users that
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
Acked-by: Kirill A. Shutemov
---
arch/sparc/Kconfig | 16
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
Reviewed-by: Max Filippov
Acked-by: Kirill A. Shutemov
---
On Fri, Mar 24, 2023 at 08:47:38AM +0530, Sachin Sant wrote:
>
> >>> Hello, Sachin, and it looks like you hit something that Zqiang and I
> >>> have been tracking down. I am guessing that you were using modprobe
> >>> and rmmod to make this happen, and that this happened at rmmod time.
> >>>
>
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
Acked-by: Kirill A. Shutemov
---
arch/arm/Kconfig | 16
From: "Mike Rapoport (IBM)"
It is not a good idea to change fundamental parameters of core memory
management. Having predefined ranges suggests that the values within
those ranges are sensible, but one has to *really* understand
implications of changing MAX_ORDER before actually amending it and
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
Acked-by: Kirill A. Shutemov
---
arch/powerpc/Kconfig | 16
From: "Mike Rapoport (IBM)"
nios2 defines range for ARCH_FORCE_MAX_ORDER allowing MAX_ORDER
up to 19, which implies maximal contiguous allocation size of 2^19
pages or 2GiB.
Drop bogus definition of ranges for ARCH_FORCE_MAX_ORDER and leave it a
simple integer with sensible default.
Users that
From: "Mike Rapoport (IBM)"
Hi,
Several architectures have ARCH_FORCE_MAX_ORDER in their Kconfig and
they all have wrong and misleading prompt and help text for this option.
Besides, some define insane limits for possible values of
ARCH_FORCE_MAX_ORDER, some carefully define ranges only for a
From: "Mike Rapoport (IBM)"
The prompt and help text of ARCH_FORCE_MAX_ORDER are not even close to
describe this configuration option.
Update both to actually describe what this option does.
Signed-off-by: Mike Rapoport (IBM)
Acked-by: Kirill A. Shutemov
---
arch/sh/mm/Kconfig | 17
From: "Mike Rapoport (IBM)"
PowerPC defines ranges for ARCH_FORCE_MAX_ORDER some of which are
insanely allowing MAX_ORDER up to 63, which implies maximal contiguous
allocation size of 2^63 pages.
Drop bogus definitions of ranges for ARCH_FORCE_MAX_ORDER and leave it a
simple integer with
97 matches
Mail list logo
