The hardware description for BARs is scattered in many different variables
in pci_epc_features. Some of these things are mutually exclusive, so it
can create confusion over which variable that has precedence over another.
Improve the situation by creating a struct pci_epc_bar_desc, and a new
enum
The series is based on top of:
https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/log/?h=endpoint
Hello all,
This series cleans up the hardware description for PCI endpoint BARs.
The problems with the existing hardware description:
-The documentation is lackluster.
-Some of the names
Now that the driver core can properly handle constant struct bus_type,
move the ibmebus_bus_type variable to be a constant structure as well,
placing it into read-only memory which can not be modified at runtime.
Cc: Greg Kroah-Hartman
Suggested-by: Greg Kroah-Hartman
Signed-off-by: Ricardo B.
Now that the driver core can properly handle constant struct bus_type,
move the mpic_subsys variable to be a constant structure as well,
placing it into read-only memory which can not be modified at runtime.
Cc: Greg Kroah-Hartman
Suggested-by: Greg Kroah-Hartman
Signed-off-by: Ricardo B.
Now that the driver core can properly handle constant struct bus_type,
move the vio_bus_type variable to be a constant structure as well,
placing it into read-only memory which can not be modified at runtime.
Cc: Greg Kroah-Hartman
Suggested-by: Greg Kroah-Hartman
Signed-off-by: Ricardo B.
In order to make the distinction of the vio_bus_type variable based on
CONFIG_PPC_SMLPAR more explicit, move the required structs into a new
ifdef block. This is needed in order to make vio_bus_type const and
because the distinction is made explicit, there is no need to set the
fields within the
: 20240209-bus_cleanup-powerpc2-498426fccb98
Best regards,
--
Ricardo B. Marliere
On 09/02/2024 22:16, David Hildenbrand wrote:
>>> 1) Convert READ_ONCE() -> ptep_get()
>>> 2) Convert set_pte_at() -> set_ptes()
>>> 3) All the "New layer" renames and addition of the trivial wrappers
>>
>> Yep that makes sense. I'll start prepping that today. I'll hold off reposting
>> until I
On 2/8/2024 9:42 PM, Anshuman Khandual wrote:
All platforms could benefit from page order check against MAX_PAGE_ORDER
before allocating a CMA area for gigantic hugetlb pages. Let's move this
check from individual platforms to generic hugetlb.
Cc: Catalin Marinas
Cc: Will Deacon
Cc: Michael
On 08.02.24 07:10, Mike Rapoport wrote:
On Mon, Jan 29, 2024 at 01:46:35PM +0100, David Hildenbrand wrote:
From: Ryan Roberts
Since the high bits [51:48] of an OA are not stored contiguously in the
PTE, there is a theoretical bug in set_ptes(), which just adds PAGE_SIZE
to the pte to get the
1) Convert READ_ONCE() -> ptep_get()
2) Convert set_pte_at() -> set_ptes()
3) All the "New layer" renames and addition of the trivial wrappers
Yep that makes sense. I'll start prepping that today. I'll hold off reposting
until I have your comments on 19-25. I'm also hoping that David will
It's a pain that we have to handle cond_resched() in
tlb_batch_pages_flush() manually and cannot simply handle it in
release_pages() -- release_pages() can be called from atomic context.
Well, in a perfect world we wouldn't have to make our code more at all.
With page poisoning and init_on_free,
Similar to how we optimized fork(), let's implement PTE batching when
consecutive (present) PTEs map consecutive pages of the same large
folio.
Most infrastructure we need for batching (mmu gather, rmap) is already
there. We only have to add get_and_clear_full_ptes() and
clear_full_ptes().
Add __tlb_remove_folio_pages(), which will remove multiple consecutive
pages that belong to the same large folio, instead of only a single
page. We'll be using this function when optimizing unmapping/zapping of
large folios that are mapped by PTEs.
We're using the remaining spare bit in an
Let's add a helper that lets us batch-process multiple consecutive PTEs.
Note that the loop will get optimized out on all architectures except on
powerpc. We have to add an early define of __tlb_remove_tlb_entry() on
ppc to make the compiler happy (and avoid making tlb_remove_tlb_entries() a
Nowadays, encoded pages are only used in mmu_gather handling. Let's
update the documentation, and define ENCODED_PAGE_BIT_DELAY_RMAP. While at
it, rename ENCODE_PAGE_BITS to ENCODED_PAGE_BITS.
If encoded page pointers would ever be used in other context again, we'd
likely want to change the
We have two bits available in the encoded page pointer to store
additional information. Currently, we use one bit to request delay of the
rmap removal until after a TLB flush.
We want to make use of the remaining bit internally for batching of
multiple pages of the same folio, specifying that the
Let's prepare for further changes by factoring it out into a separate
function.
Reviewed-by: Ryan Roberts
Signed-off-by: David Hildenbrand
---
mm/memory.c | 53 -
1 file changed, 32 insertions(+), 21 deletions(-)
diff --git a/mm/memory.c
We don't need up-to-date accessed-dirty information for anon folios and can
simply work with the ptent we already have. Also, we know the RSS counter
we want to update.
We can safely move arch_check_zapped_pte() + tlb_remove_tlb_entry() +
zap_install_uffd_wp_if_needed() after updating the folio
We don't need uptodate accessed/dirty bits, so in theory we could
replace ptep_get_and_clear_full() by an optimized ptep_clear_full()
function. Let's rely on the provided pte.
Further, there is no scenario where we would have to insert uffd-wp
markers when zapping something that is not a normal
Let's prepare for further changes by factoring out processing of present
PTEs.
Signed-off-by: David Hildenbrand
---
mm/memory.c | 94 ++---
1 file changed, 53 insertions(+), 41 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index
This series is based on [1]. Similar to what we did with fork(), let's
implement PTE batching during unmap/zap when processing PTE-mapped THPs.
We collect consecutive PTEs that map consecutive pages of the same large
folio, making sure that the other PTE bits are compatible, and (a) adjust
the
On Tue, 6 Feb 2024 15:07:14 +0100 Herve Codina wrote:
> The bitmap_onto() function translates one bitmap relative to another but
> no function are present to perform the reverse translation.
>
> Introduce bitmap_off() to fill this hole.
Argh, Yury is not even CCed on this? I was about to ping
On Fri, 09 Feb 2024 15:59:07 +0100, Christian Lamparter wrote:
> the driver currently fails to compile on 6.8-rc3 due to:
> | spi-ppc4xx.c: In function ‘spi_ppc4xx_of_probe’:
> | @346:36: error: invalid use of undefined type ‘struct platform_device’
> | 346 | struct device_node *np =
Hi
Am 09.02.24 um 06:15 schrieb Michael Ellerman:
Thomas Zimmermann writes:
Am 07.02.24 um 17:13 schrieb Randy Dunlap:
When VIDEO is not set, there is a build error. Fix that by selecting
VIDEO for PS3_PS3AV.
ERROR: modpost: ".video_get_options" [drivers/ps3/ps3av_mod.ko] undefined!
Fixes:
On 09/02/2024 10.11, Nicholas Piggin wrote:
Console output required to support migration becomes quite noisy
when doing lots of migrations. Provide a migrate_quiet() call that
suppresses console output and doesn't log a message.
Signed-off-by: Nicholas Piggin
---
lib/migrate.c | 11
On 09/02/2024 10.11, Nicholas Piggin wrote:
Support multiple migrations by flipping dest file/socket variables to
source after the migration is complete, ready to start again. A new
destination is created if the test outputs the migrate line again.
Test cases may now switch to calling migrate()
On Thu, Dec 14, 2023 at 08:36:04PM +0300, George Stark wrote:
> This patch series fixes the problem of devm_led_classdev_register misusing.
>
> The basic problem is described in [1]. Shortly when
> devm_led_classdev_register()
> is used then led_classdev_unregister() called after driver's
On Thu, Dec 21, 2023 at 03:11:11PM +, Lee Jones wrote:
> On Thu, 14 Dec 2023, George Stark wrote:
>
> > This patch series fixes the problem of devm_led_classdev_register misusing.
> >
> > The basic problem is described in [1]. Shortly when
> > devm_led_classdev_register()
> > is used then
On Tue, Jan 02, 2024 at 10:16:04AM +0530, Aneesh Kumar K.V wrote:
> Michael Ellerman writes:
>
>
>
> > #ifdef CONFIG_PPC64
> > int boot_cpu_hwid = -1;
> > @@ -492,12 +493,26 @@ void __init smp_setup_cpu_maps(void)
> > avail = !of_property_match_string(dn,
> >
On 09/02/2024 10.11, Nicholas Piggin wrote:
Rather than put a big script into the trap handler, have it call
a function.
Signed-off-by: Nicholas Piggin
---
scripts/arch-run.bash | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/scripts/arch-run.bash
the driver currently fails to compile on 6.8-rc3 due to:
| spi-ppc4xx.c: In function ‘spi_ppc4xx_of_probe’:
| @346:36: error: invalid use of undefined type ‘struct platform_device’
| 346 | struct device_node *np = op->dev.of_node;
| |^~
| ... (more
Add a selftest for migration support in guest library and test harness
code. It performs migrations in a tight loop to irritate races and bugs
in the test harness code.
Include the test in arm, s390, powerpc.
Acked-by: Claudio Imbrenda (s390x)
Reviewed-by: Thomas Huth
Signed-off-by: Nicholas
x86/sieve.c is used by s390x, arm, and riscv via symbolic link. Make a
new directory common/ for architecture-independent tests and move
sieve.c here.
Reviewed-by: Thomas Huth
Signed-off-by: Nicholas Piggin
---
arm/sieve.c| 2 +-
common/sieve.c | 51
Console output required to support migration becomes quite noisy
when doing lots of migrations. Provide a migrate_quiet() call that
suppresses console output and doesn't log a message.
Signed-off-by: Nicholas Piggin
---
lib/migrate.c | 11 +++
lib/migrate.h | 1 +
Using 1 and 2 for source and destination is confusing, particularly
now with multiple migrations that flip between them. Do a rename
pass to 'src' and 'dst' to tidy things up.
Acked-by: Thomas Huth
Signed-off-by: Nicholas Piggin
---
scripts/arch-run.bash | 111
Support multiple migrations by flipping dest file/socket variables to
source after the migration is complete, ready to start again. A new
destination is created if the test outputs the migrate line again.
Test cases may now switch to calling migrate() one or more times.
Signed-off-by: Nicholas
Starting a pipeline of jobs in the background does not seem to have
a simple way to reliably find the pid of a particular process in the
pipeline (because not all processes are started when the shell
continues to execute).
The way PID of QEMU is derived can result in a failure waiting on a
PID
Rather than put a big script into the trap handler, have it call
a function.
Signed-off-by: Nicholas Piggin
---
scripts/arch-run.bash | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/scripts/arch-run.bash b/scripts/arch-run.bash
index 11d47a85..c1dd67ab 100644
Migration files were not being removed when the QEMU process is
interrupted (e.g., with ^C). This is becaus the SIGINT propagates to the
bash TRAP handler, which recursively TRAPs due to the 'kill 0' in the
handler. This eventually crashes bash.
This can be observed by interrupting a long-running
Thanks for the detailed reviews. Hopefully this is the last one...
Since v3:
- Addressed Thomas's review comments:
- Patch 2 initrd cleanup unset the old variable in the correct place.
- Patch 4 multi migration removed the extra wait for "Now migrate the
VM" message, and updated comments around
On 08/02/2024 17:34, Mark Rutland wrote:
> On Fri, Feb 02, 2024 at 08:07:31AM +, Ryan Roberts wrote:
>> Hi All,
>
> Hi Ryan,
>
> I assume this is the same as your 'features/granule_perf/contpte-lkml_v'
> branch
> on https://gitlab.arm.com/linux-arm/linux-rr/
Yep - great detective work!
On 09/02/2024 09.39, Nicholas Piggin wrote:
On Fri Feb 9, 2024 at 6:19 PM AEST, Thomas Huth wrote:
On 09/02/2024 08.01, Nicholas Piggin wrote:
Support multiple migrations by flipping dest file/socket variables to
source after the migration is complete, ready to start again. A new
destination
On Fri Feb 9, 2024 at 6:19 PM AEST, Thomas Huth wrote:
> On 09/02/2024 08.01, Nicholas Piggin wrote:
> > Support multiple migrations by flipping dest file/socket variables to
> > source after the migration is complete, ready to start again. A new
> > destination is created if the test outputs the
On 09/02/2024 08.01, Nicholas Piggin wrote:
Add a selftest for migration support in guest library and test harness
code. It performs migrations a tight loop to irritate races and bugs in
"*in* a tight loop" ?
the test harness code.
Include the test in arm, s390, powerpc.
Acked-by: Claudio
On 09/02/2024 08.01, Nicholas Piggin wrote:
x86/sieve.c is used by s390x, arm, and riscv via symbolic link. Make a
new directory common/ for architecture-independent tests and move
sieve.c here.
Signed-off-by: Nicholas Piggin
---
arm/sieve.c| 2 +-
common/sieve.c | 51
On 09/02/2024 08.01, Nicholas Piggin wrote:
Using 1 and 2 for source and destination is confusing, particularly
now with multiple migrations that flip between them. Do a rename
pass to tidy things up.
Signed-off-by: Nicholas Piggin
---
scripts/arch-run.bash | 115
On Fri Feb 9, 2024 at 5:32 PM AEST, Thomas Huth wrote:
> On 09/02/2024 08.01, Nicholas Piggin wrote:
> > Rather than put a big script into the trap handler, have it call
> > a function.
> >
> > Signed-off-by: Nicholas Piggin
> > ---
> > scripts/arch-run.bash | 13 -
> > 1 file
On 09/02/2024 08.01, Nicholas Piggin wrote:
Support multiple migrations by flipping dest file/socket variables to
source after the migration is complete, ready to start again. A new
destination is created if the test outputs the migrate line again.
Test cases may now switch to calling migrate()
Michael reported that we are seeing ftrace bug on bootup when KASAN is
enabled, and if we are using -fpatchable-function-entry:
ftrace: allocating 47780 entries in 18 pages
ftrace-powerpc: 0xc20b3d5c: No module provided for non-kernel
address
[ ftrace bug
On 09/02/2024 08.01, Nicholas Piggin wrote:
Console output required to support migration becomes quite noisy
when doing lots of migrations. Provide a migrate_quiet() call that
suppresses console output and doesn't log a message.
Signed-off-by: Nicholas Piggin
---
lib/migrate.c | 12
51 matches
Mail list logo
