Re: [PATCH 07/12] s390: add pte_free_defer(), with use of mmdrop_async()

2023-06-05 Thread Hugh Dickins
On Sun, 28 May 2023, Hugh Dickins wrote: > Add s390-specific pte_free_defer(), to call pte_free() via call_rcu(). > pte_free_defer() will be called inside khugepaged's retract_page_tables() > loop, where allocating extra memory cannot be relied upon. This precedes > the generic version to avoid

[PATCH 16/16] powerpc/book3s64/radix: Remove mmu_vmemmap_psize

2023-06-05 Thread Aneesh Kumar K.V
This is not used by radix anymore. Signed-off-by: Aneesh Kumar K.V --- arch/powerpc/mm/book3s64/radix_pgtable.c | 10 -- arch/powerpc/mm/init_64.c| 21 ++--- 2 files changed, 14 insertions(+), 17 deletions(-) diff --git

[PATCH 15/16] powerpc/book3s64/radix: Add support for vmemmap optimization for radix

2023-06-05 Thread Aneesh Kumar K.V
With 2M PMD-level mapping, we require 32 struct pages and a single vmemmap page can contain 1024 struct pages (PAGE_SIZE/sizeof(struct page)). Hence with 64K page size, we don't use vmemmap deduplication for PMD-level mapping. Signed-off-by: Aneesh Kumar K.V ---

[PATCH 14/16] powerpc/book3s64/vmemmap: Switch radix to use a different vmemmap handling function

2023-06-05 Thread Aneesh Kumar K.V
This is in preparation to update radix to implement vmemmap optimization for devdax. Below are the rules w.r.t radix vmemmap mapping 1. First try to map things using PMD (2M) 2. With altmap if altmap cross-boundary check returns true, fall back to PAGE_SIZE 3. IF we can't allocate PMD_SIZE

[PATCH 13/16] powerpc/book3s64/mm: Enable transparent pud hugepage

2023-06-05 Thread Aneesh Kumar K.V
This is enabled only with radix translation and 1G hugepage size. This will be used with devdax device memory with a namespace alignment of 1G. Anon transparent hugepage is not supported even though we do have helpers checking pud_trans_huge(). We should never find that return true. The only

[PATCH 12/16] mm/vmemmap optimization: Split hugetlb and devdax vmemmap optimization

2023-06-05 Thread Aneesh Kumar K.V
Arm disabled hugetlb vmemmap optimization [1] because hugetlb vmemmap optimization includes an update of both the permissions (writeable to read-only) and the output address (pfn) of the vmemmap ptes. That is not supported without unmapping of pte(marking it invalid) by some architectures. With

[PATCH 11/16] mm/huge pud: Use transparent huge pud helpers only with CONFIG_TRANSPARENT_HUGEPAGE

2023-06-05 Thread Aneesh Kumar K.V
pudp_set_wrprotect and move_huge_pud helpers are only used when CONFIG_TRANSPARENT_HUGEPAGE is enabled. Similar to pmdp_set_wrprotect and move_huge_pmd_helpers use architecture override only if CONFIG_TRANSPARENT_HUGEPAGE is set Signed-off-by: Aneesh Kumar K.V --- include/linux/pgtable.h | 2 ++

[PATCH 10/16] mm: Add __HAVE_ARCH_PUD_SAME similar to __HAVE_ARCH_P4D_SAME

2023-06-05 Thread Aneesh Kumar K.V
This helps architectures to override pmd_same and pud_same independently. Signed-off-by: Aneesh Kumar K.V --- include/linux/pgtable.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h index 2fe19720075e..8c5174d1f9db 100644 ---

[PATCH 09/16] mm/vmemmap: Allow architectures to override how vmemmap optimization works

2023-06-05 Thread Aneesh Kumar K.V
Architectures like powerpc will like to use different page table allocators and mapping mechanisms to implement vmemmap optimization. Similar to vmemmap_populate allow architectures to implement vmemap_populate_compound_pages Signed-off-by: Aneesh Kumar K.V --- mm/sparse-vmemmap.c | 3 +++ 1

[PATCH 08/16] mm/vmemmap: Improve vmemmap_can_optimize and allow architectures to override

2023-06-05 Thread Aneesh Kumar K.V
dax vmemmap optimization requires a minimum of 2 PAGE_SIZE area within vmemmap such that tail page mapping can point to the second PAGE_SIZE area. Enforce that in vmemmap_can_optimize() function. Architectures like powerpc also want to enable vmemmap optimization conditionally (only with radix

[PATCH 07/16] mm: Change pudp_huge_get_and_clear_full take vm_area_struct as arg

2023-06-05 Thread Aneesh Kumar K.V
We will use this in a later patch to do tlb flush when clearing pud entries on powerpc. This is similar to commit 93a98695f2f9 ("mm: change pmdp_huge_get_and_clear_full take vm_area_struct as arg") Signed-off-by: Aneesh Kumar K.V --- include/linux/pgtable.h | 4 ++-- mm/debug_vm_pgtable.c |

[PATCH 06/16] mm/hugepage pud: Allow arch-specific helper function to check huge page pud support

2023-06-05 Thread Aneesh Kumar K.V
Architectures like powerpc would like to enable transparent huge page pud support only with radix translation. To support that add has_transparent_pud_hugepage() helper that architectures can override. Signed-off-by: Aneesh Kumar K.V --- drivers/nvdimm/pfn_devs.c | 2 +- include/linux/pgtable.h

[PATCH 05/16] powerpc/mm/dax: Fix the condition when checking if altmap vmemap can cross-boundary

2023-06-05 Thread Aneesh Kumar K.V
Without this fix, the last subsection vmemmap can end up in memory even if the namespace is created with -M mem and has sufficient space in the altmap area. Fixes: cf387d9644d8 ("libnvdimm/altmap: Track namespace boundaries in altmap") Signed-off-by: Aneesh Kumar K.V ---

[PATCH 04/16] powerpc/book3s64/mm: Use PAGE_KERNEL instead of opencoding

2023-06-05 Thread Aneesh Kumar K.V
No functional change in this patch. Signed-off-by: Aneesh Kumar K.V --- arch/powerpc/mm/book3s64/radix_pgtable.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c b/arch/powerpc/mm/book3s64/radix_pgtable.c index

[PATCH 03/16] powerpc/book3s64/mm: Fix DirectMap stats in /proc/meminfo

2023-06-05 Thread Aneesh Kumar K.V
On memory unplug reduce DirectMap page count correctly. root@ubuntu-guest:# grep Direct /proc/meminfo DirectMap4k: 0 kB DirectMap64k: 0 kB DirectMap2M:115343360 kB DirectMap1G: 0 kB Before fix: root@ubuntu-guest:# ndctl disable-namespace all disabled 1 namespace

[PATCH 02/16] powerpc/book3s64/mm: mmu_vmemmap_psize is used by radix

2023-06-05 Thread Aneesh Kumar K.V
This should not be within CONFIG_PPC_64S_HASHS_MMU. We use mmu_vmemmap_psize on radix while mapping the vmemmap area. Signed-off-by: Aneesh Kumar K.V --- arch/powerpc/mm/book3s64/radix_pgtable.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c

[PATCH 01/16] powerpc/mm/book3s64: Use pmdp_ptep helper instead of typecasting.

2023-06-05 Thread Aneesh Kumar K.V
No functional change in this patch. Signed-off-by: Aneesh Kumar K.V --- arch/powerpc/mm/book3s64/radix_pgtable.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c b/arch/powerpc/mm/book3s64/radix_pgtable.c index

[PATCH 00/16] Add support for DAX vmemmap optimization for ppc64

2023-06-05 Thread Aneesh Kumar K.V
This patch series implements changes required to support DAX vmemmap optimization for ppc64. The vmemmap optimization is only enabled with radix MMU translation and 1GB PUD mapping with 64K page size. The patch series also split hugetlb vmemmap optimization as a separate Kconfig variable so that

Re: [PATCHv2 pci-next 2/2] PCI/AER: Rate limit the reporting of the correctable errors

2023-06-05 Thread Grant Grundler
On Wed, May 17, 2023 at 11:11 PM Grant Grundler wrote: > On Fri, Apr 7, 2023 at 12:46 PM Bjorn Helgaas wrote: > ... > > But I don't think we need output in a single step; we just need a > > single instance of ratelimit_state (or one for CPER path and another > > for native AER path), and that

[PATCHv3 pci-next 2/2] PCI/AER: Rate limit the reporting of the correctable errors

2023-06-05 Thread Grant Grundler
From: Rajat Khandelwal There are many instances where correctable errors tend to inundate the message buffer. We observe such instances during thunderbolt PCIe tunneling. It's true that they are mitigated by the hardware and are non-fatal but we shouldn't be spamming the logs with such

[PATCHv3 pci-next 1/2] PCI/AER: correctable error message as KERN_INFO

2023-06-05 Thread Grant Grundler
Since correctable errors have been corrected (and counted), the dmesg output should not be reported as a warning, but rather as "informational". Otherwise, using a certain well known vendor's PCIe parts in a USB4 docking station, the dmesg buffer can be spammed with correctable errors, 717 bytes

[PATCH 2/2] PCI/AER: Rate limit the reporting of the correctable errors

2023-06-05 Thread Grant Grundler
From: Rajat Khandelwal There are many instances where correctable errors tend to inundate the message buffer. We observe such instances during thunderbolt PCIe tunneling. It's true that they are mitigated by the hardware and are non-fatal but we shouldn't be spamming the logs with such

[PATCH 1/2] PCI/AER: correctable error message as KERN_INFO

2023-06-05 Thread Grant Grundler
Since correctable errors have been corrected (and counted), the dmesg output should not be reported as a warning, but rather as "informational". Otherwise, using a certain well known vendor's PCIe parts in a USB4 docking station, the dmesg buffer can be spammed with correctable errors, 717 bytes

Re: [PATCH 06/12] sparc: add pte_free_defer() for pgtables sharing page

2023-06-05 Thread Hugh Dickins
On Sun, 28 May 2023, Hugh Dickins wrote: > Add sparc-specific pte_free_defer(), to call pte_free() via call_rcu(). > pte_free_defer() will be called inside khugepaged's retract_page_tables() > loop, where allocating extra memory cannot be relied upon. This precedes > the generic version to avoid

Re: [PATCHv2 pci-next 2/2] PCI/AER: Rate limit the reporting of the correctable errors

2023-06-05 Thread Grant Grundler
[plain text only this time...] On Wed, May 17, 2023 at 11:11 PM Grant Grundler wrote: > > On Fri, Apr 7, 2023 at 12:46 PM Bjorn Helgaas wrote: > ... > > But I don't think we need output in a single step; we just need a > > single instance of ratelimit_state (or one for CPER path and another > >

Re: [PATCH 05/12] powerpc: add pte_free_defer() for pgtables sharing page

2023-06-05 Thread Hugh Dickins
On Fri, 2 Jun 2023, Jason Gunthorpe wrote: > On Mon, May 29, 2023 at 03:02:02PM +0100, Matthew Wilcox wrote: > > On Sun, May 28, 2023 at 11:20:21PM -0700, Hugh Dickins wrote: > > > +void pte_free_defer(struct mm_struct *mm, pgtable_t pgtable) > > > +{ > > > + struct page *page; > > > + > > > +

Re: [PATCH 00/89] i2c: Convert to platform remove callback returning void

2023-06-05 Thread Wolfram Sang
On Thu, Jun 01, 2023 at 03:54:50PM +0200, Wolfram Sang wrote: > > > I wonder how this series will go in. My expectation was that Wolfram > > picks up the whole series via his tree?! > > Will do. I am currently super-busy, though. Whole series applied to for-next. I squashed all the commits into

Re: [PATCH v4 RESEND 0/3] sed-opal: keyrings, discovery, revert, key store

2023-06-05 Thread Jens Axboe
On 6/1/23 4:37 PM, gjo...@linux.vnet.ibm.com wrote: > From: Greg Joyce > > This patchset has gone through numerous rounds of review and > all comments/suggetions have been addressed. I believe that > this patchset is ready for inclusion. > > TCG SED Opal is a specification from The Trusted

Re: [PATCH 00/13] mm: jit/text allocator

2023-06-05 Thread Kent Overstreet
On Mon, Jun 05, 2023 at 12:20:40PM +0300, Mike Rapoport wrote: > On Fri, Jun 02, 2023 at 10:35:09AM +0100, Mark Rutland wrote: > > On Thu, Jun 01, 2023 at 02:14:56PM -0400, Kent Overstreet wrote: > > > On Thu, Jun 01, 2023 at 05:12:03PM +0100, Mark Rutland wrote: > > > > For a while I have wanted

Re: [PATCH 12/13] x86/jitalloc: prepare to allocate exectuatble memory as ROX

2023-06-05 Thread Nadav Amit
> On Jun 5, 2023, at 9:10 AM, Edgecombe, Rick P > wrote: > > On Mon, 2023-06-05 at 11:11 +0300, Mike Rapoport wrote: >> On Sun, Jun 04, 2023 at 10:52:44PM -0400, Steven Rostedt wrote: >>> On Thu, 1 Jun 2023 16:54:36 -0700 >>> Nadav Amit wrote: >>> > The way text_poke() is used here, it

Re: [PATCH 12/13] x86/jitalloc: prepare to allocate exectuatble memory as ROX

2023-06-05 Thread Edgecombe, Rick P
On Mon, 2023-06-05 at 23:42 +0300, Mike Rapoport wrote: > > I tried this technique previously [0], and I thought it was not too > > bad. In most of the callers it looks similar to what you have in > > do_text_poke(). Sometimes less, sometimes more. It might need > > enlightening of some of the

Re: [PATCH 12/13] x86/jitalloc: prepare to allocate exectuatble memory as ROX

2023-06-05 Thread Mike Rapoport
On Mon, Jun 05, 2023 at 04:10:21PM +, Edgecombe, Rick P wrote: > On Mon, 2023-06-05 at 11:11 +0300, Mike Rapoport wrote: > > On Sun, Jun 04, 2023 at 10:52:44PM -0400, Steven Rostedt wrote: > > > On Thu, 1 Jun 2023 16:54:36 -0700 > > > Nadav Amit wrote: > > > > > > > > The way text_poke() is

[PATCH] powerpc/iommu: Only build sPAPR access functions on pSeries

2023-06-05 Thread Timothy Pearson
and PowerNV A build failure with CONFIG_HAVE_PCI=y set without PSERIES or POWERNV set was caught by the random configuration checker. Guard the sPAPR specific IOMMU functions on CONFIG_PPC_PSERIES || CONFIG_PPC_POWERNV. Signed-off-by: Timothy Pearson --- arch/powerpc/kernel/iommu.c | 4

Re: [PATCH 12/13] x86/jitalloc: prepare to allocate exectuatble memory as ROX

2023-06-05 Thread Edgecombe, Rick P
On Mon, 2023-06-05 at 11:11 +0300, Mike Rapoport wrote: > On Sun, Jun 04, 2023 at 10:52:44PM -0400, Steven Rostedt wrote: > > On Thu, 1 Jun 2023 16:54:36 -0700 > > Nadav Amit wrote: > > > > > > The way text_poke() is used here, it is creating a new writable > > > > alias > > > > and flushing it

Re: [PATCH v3 2/2] serial: 8250: Apply FSL workarounds also without SERIAL_8250_CONSOLE

2023-06-05 Thread Ilpo Järvinen
On Mon, 5 Jun 2023, Uwe Kleine-König wrote: > Hello Ilpo, > > On Mon, Jun 05, 2023 at 04:44:08PM +0300, Ilpo Järvinen wrote: > > On Mon, 5 Jun 2023, Uwe Kleine-König wrote: > > > On Mon, Jun 05, 2023 at 04:22:55PM +0300, Ilpo Järvinen wrote: > > > > On Mon, 5 Jun 2023, Uwe Kleine-König wrote: >

Re: [PATCH v3 2/2] serial: 8250: Apply FSL workarounds also without SERIAL_8250_CONSOLE

2023-06-05 Thread Uwe Kleine-König
Hello Ilpo, On Mon, Jun 05, 2023 at 04:44:08PM +0300, Ilpo Järvinen wrote: > On Mon, 5 Jun 2023, Uwe Kleine-König wrote: > > On Mon, Jun 05, 2023 at 04:22:55PM +0300, Ilpo Järvinen wrote: > > > On Mon, 5 Jun 2023, Uwe Kleine-König wrote: > > > > > > > The need to handle the FSL variant of 8250

Re: [PATCH v8 0/7] Add pci_dev_for_each_resource() helper and update users

2023-06-05 Thread Andy Shevchenko
On Wed, May 31, 2023 at 04:30:28PM -0500, Bjorn Helgaas wrote: > On Wed, May 31, 2023 at 08:48:35PM +0200, Jonas Gorski wrote: ... > > Looking at the code I understand where coverity is coming from: > > > > #define __pci_dev_for_each_res0(dev, res, ...) \ > >for

Re: [PATCH v3 2/2] serial: 8250: Apply FSL workarounds also without SERIAL_8250_CONSOLE

2023-06-05 Thread Andy Shevchenko
On Mon, Jun 05, 2023 at 04:44:08PM +0300, Ilpo Järvinen wrote: > On Mon, 5 Jun 2023, Uwe Kleine-König wrote: > > On Mon, Jun 05, 2023 at 04:22:55PM +0300, Ilpo Järvinen wrote: > > > On Mon, 5 Jun 2023, Uwe Kleine-König wrote: > > > > The need to handle the FSL variant of 8250 in a special way is

Re: [PATCH v3 2/2] serial: 8250: Apply FSL workarounds also without SERIAL_8250_CONSOLE

2023-06-05 Thread Ilpo Järvinen
On Mon, 5 Jun 2023, Uwe Kleine-König wrote: > On Mon, Jun 05, 2023 at 04:22:55PM +0300, Ilpo Järvinen wrote: > > On Mon, 5 Jun 2023, Uwe Kleine-König wrote: > > > > > The need to handle the FSL variant of 8250 in a special way is also > > > present without console support. So soften the

Re: [PATCH v3 2/2] serial: 8250: Apply FSL workarounds also without SERIAL_8250_CONSOLE

2023-06-05 Thread Uwe Kleine-König
On Mon, Jun 05, 2023 at 04:22:55PM +0300, Ilpo Järvinen wrote: > On Mon, 5 Jun 2023, Uwe Kleine-König wrote: > > > The need to handle the FSL variant of 8250 in a special way is also > > present without console support. So soften the dependency for > > SERIAL_8250_FSL accordingly. Note that with

Re: [PATCH v3 2/2] serial: 8250: Apply FSL workarounds also without SERIAL_8250_CONSOLE

2023-06-05 Thread Ilpo Järvinen
On Mon, 5 Jun 2023, Uwe Kleine-König wrote: > The need to handle the FSL variant of 8250 in a special way is also > present without console support. So soften the dependency for > SERIAL_8250_FSL accordingly. Note that with the 8250 driver compiled as > a module, some devices still might not make

[PATCH v3 2/2] serial: 8250: Apply FSL workarounds also without SERIAL_8250_CONSOLE

2023-06-05 Thread Uwe Kleine-König
The need to handle the FSL variant of 8250 in a special way is also present without console support. So soften the dependency for SERIAL_8250_FSL accordingly. Note that with the 8250 driver compiled as a module, some devices still might not make use of the needed workarounds. That affects the

[PATCH v3 0/2] serial: 8250: Apply FSL workarounds also without SERIAL_8250_CONSOLE

2023-06-05 Thread Uwe Kleine-König
Hello, this is v3 of the series that now also copes for arch/powerpc/kernel/legacy_serial.c using fsl8250_handle_irq(). For kernel configurations that already before were correctly using the Freescale workarounds, this is the case with this series applied, too. So in all cases the situation

[PATCH v3 1/2] powerpc/legacy_serial: Warn about 8250 devices operated without active FSL workarounds

2023-06-05 Thread Uwe Kleine-König
If the 8250 driver is built as a module (or built-in without console support) the Freescale specific workaround were silently not activated. Add a warning in this case. Currently CONFIG_SERIAL_8250_FSL=y implies that the function fsl8250_handle_irq() is built-in and can be used. However with the

[PATCH 4/4] powerpc/kuap: Make disabling KUAP at boottime optional

2023-06-05 Thread Christophe Leroy
It is possible to disable KUAP at boottime with 'nosmap' parameter. That is implemented with jump_label hence adds a 'nop' in front of each open/close of userspace access. >From a security point of view it makes sence to disallow disabling KUAP. And on processors like the 8xx where 'nop' is not

[PATCH 3/4] powerpc/kuap: Refactor static branch for disabling kuap

2023-06-05 Thread Christophe Leroy
All but book3s/64 use a static branch key for disabling kuap. book3s/64 uses a memory feature. Refactor all targets except book3s/64. Signed-off-by: Christophe Leroy --- arch/powerpc/include/asm/book3s/32/kup.h | 7 --- arch/powerpc/include/asm/book3s/64/kup.h | 1 +

[PATCH 2/4] powerpc/kuap: Avoid useless jump_label on empty function

2023-06-05 Thread Christophe Leroy
Disassembly of interrupt_enter_prepare() shows a pointless nop before the mftb c000abf0 : c000abf0: 81 23 00 84 lwz r9,132(r3) c000abf4: 71 29 40 00 andi. r9,r9,16384 c000abf8: 41 82 00 28 beq-c000ac20 c000abfc: ===> 60 00 00 00 nop <

[PATCH 1/4] powerpc/kuap: Avoid unnecessary reads of MD_AP

2023-06-05 Thread Christophe Leroy
A disassembly of interrupt_exit_kernel_prepare() shows a useless read of MD_AP register. This is shown by r9 being re-used immediately without doing anything with the value read. c000e0e0: 60 00 00 00 nop c000e0e4: ===> 7d 3a c2 a6 mfmd_ap r9< c000e0e8: 7d 20 00

Re: [PATCH 00/13] mm: jit/text allocator

2023-06-05 Thread Mark Rutland
On Mon, Jun 05, 2023 at 12:20:40PM +0300, Mike Rapoport wrote: > On Fri, Jun 02, 2023 at 10:35:09AM +0100, Mark Rutland wrote: > > On Thu, Jun 01, 2023 at 02:14:56PM -0400, Kent Overstreet wrote: > > > On Thu, Jun 01, 2023 at 05:12:03PM +0100, Mark Rutland wrote: > > > > For a while I have wanted

Re: [PATCH 00/13] mm: jit/text allocator

2023-06-05 Thread Mike Rapoport
On Fri, Jun 02, 2023 at 10:35:09AM +0100, Mark Rutland wrote: > On Thu, Jun 01, 2023 at 02:14:56PM -0400, Kent Overstreet wrote: > > On Thu, Jun 01, 2023 at 05:12:03PM +0100, Mark Rutland wrote: > > > For a while I have wanted to give kprobes its own allocator so that it > > > can work > > > even

[PATCH] powerpc/interrupt: Don't read MSR from interrupt_exit_kernel_prepare()

2023-06-05 Thread Christophe Leroy
A disassembly of interrupt_exit_kernel_prepare() shows a useless read of MSR register. This is shown by r9 being re-used immediately without doing anything with the value read. c000e0e0: 60 00 00 00 nop c000e0e4: 7d 3a c2 a6 mfmd_ap r9 c000e0e8: 7d 20 00 a6

[PATCH] powerpc/signal32: Force inlining of __unsafe_save_user_regs() and save_tm_user_regs_unsafe()

2023-06-05 Thread Christophe Leroy
Looking at generated code for handle_signal32() shows calls to a function called __unsafe_save_user_regs.constprop.0 while user access is open. And that __unsafe_save_user_regs.constprop.0 function has two nops at the begining, allowing it to be traced, which is unexpected during user access open

Re: [PATCH 12/13] x86/jitalloc: prepare to allocate exectuatble memory as ROX

2023-06-05 Thread Mike Rapoport
On Sun, Jun 04, 2023 at 10:52:44PM -0400, Steven Rostedt wrote: > On Thu, 1 Jun 2023 16:54:36 -0700 > Nadav Amit wrote: > > > > The way text_poke() is used here, it is creating a new writable alias > > > and flushing it for *each* write to the module (like for each write of > > > an individual

Re: [RFC 1/1] sched/fair: Consider asymmetric scheduler groups in load balancer

2023-06-05 Thread Tobias Huschle
On 2023-05-16 15:36, Vincent Guittot wrote: On Mon, 15 May 2023 at 13:46, Tobias Huschle wrote: The current load balancer implementation implies that scheduler groups, within the same domain, all host the same number of CPUs. This is reflected in the condition, that a scheduler group, which

Re: [PATCH] sound: Switch i2c drivers back to use .probe()

2023-06-05 Thread Takashi Iwai
On Thu, 25 May 2023 22:36:40 +0200, Uwe Kleine-König wrote: > > After commit b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new() > call-back type"), all drivers being converted to .probe_new() and then > 03c835f498b5 ("i2c: Switch .probe() to not take an id parameter") convert > back to (the

[RFC PATCH v2 5/6] KVM: PPC: Add support for nested PAPR guests

2023-06-05 Thread Jordan Niethe
A series of hcalls have been added to the PAPR which allow a regular guest partition to create and manage guest partitions of its own. Add support to KVM to utilize these hcalls to enable running nested guests. Overview of the new hcall usage: - L1 and L0 negotiate capabilities with

[RFC PATCH v2 6/6] docs: powerpc: Document nested KVM on POWER

2023-06-05 Thread Jordan Niethe
From: Michael Neuling Document support for nested KVM on POWER using the existing API as well as the new PAPR API. This includes the new HCALL interface and how it used by KVM. Signed-off-by: Michael Neuling Signed-off-by: Jordan Niethe --- v2: - Separated into individual patch ---

[RFC PATCH v2 1/6] KVM: PPC: Use getters and setters for vcpu register state

2023-06-05 Thread Jordan Niethe
There are already some getter and setter functions used for accessing vcpu register state, e.g. kvmppc_get_pc(). There are also more complicated examples that are generated by macros like kvmppc_get_sprg0() which are generated by the SHARED_SPRNG_WRAPPER() macro. In the new PAPR API for nested

[RFC PATCH v2 2/6] KVM: PPC: Add fpr getters and setters

2023-06-05 Thread Jordan Niethe
Add wrappers for fpr registers to prepare for supporting PAPR nested guests. Signed-off-by: Jordan Niethe --- arch/powerpc/include/asm/kvm_book3s.h | 31 +++ arch/powerpc/include/asm/kvm_booke.h | 10 + arch/powerpc/kvm/book3s.c | 16 +++---

[RFC PATCH v2 0/6] KVM: PPC: Nested PAPR guests

2023-06-05 Thread Jordan Niethe
There is existing support for nested guests on powernv hosts however the hcall interface this uses is not support by other PAPR hosts. A set of new hcalls will be added to PAPR to facilitate creating and managing guests by a regular partition in the following way: - L1 and L0 negotiate

[RFC PATCH v2 4/6] KVM: PPC: Add helper library for Guest State Buffers

2023-06-05 Thread Jordan Niethe
The new PAPR nested guest API introduces the concept of a Guest State Buffer for communication about L2 guests between L1 and L0 hosts. In the new API, the L0 manages the L2 on behalf of the L1. This means that if the L1 needs to change L2 state (e.g. GPRs, SPRs, partition table...), it must

[RFC PATCH v2 3/6] KVM: PPC: Add vr getters and setters

2023-06-05 Thread Jordan Niethe
Add wrappers for vr registers to prepare for supporting PAPR nested guests. Signed-off-by: Jordan Niethe --- arch/powerpc/include/asm/kvm_book3s.h | 20 +++ arch/powerpc/kvm/powerpc.c| 50 +-- 2 files changed, 45 insertions(+), 25 deletions(-) diff