[powerpc:next] BUILD SUCCESS 85a616416e9e01db0bfa92f26457e92642e2236b
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next branch HEAD: 85a616416e9e01db0bfa92f26457e92642e2236b macintosh/ams: linux/platform_device.h is needed elapsed time: 1038m configs tested: 229 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alpha allnoconfig gcc alphaallyesconfig gcc alpha defconfig gcc alpharandconfig-r002-20230901 gcc alpharandconfig-r012-20230901 gcc alpharandconfig-r014-20230901 gcc alpharandconfig-r032-20230901 gcc arc allmodconfig gcc arc allnoconfig gcc arc allyesconfig gcc arc defconfig gcc arc randconfig-001-20230831 gcc arc randconfig-001-20230901 gcc arc randconfig-r002-20230901 gcc arc randconfig-r004-20230831 gcc arc randconfig-r011-20230831 gcc arc randconfig-r015-20230831 gcc arc randconfig-r023-20230831 gcc arm allmodconfig gcc arm allnoconfig gcc arm allyesconfig gcc arm defconfig gcc arm randconfig-001-20230831 gcc arm randconfig-001-20230901 clang arm randconfig-r033-20230831 clang arm64allmodconfig gcc arm64 allnoconfig gcc arm64allyesconfig gcc arm64 defconfig gcc arm64randconfig-r001-20230901 clang arm64randconfig-r011-20230901 gcc arm64randconfig-r013-20230901 gcc arm64randconfig-r015-20230901 gcc csky allmodconfig gcc csky allnoconfig gcc csky allyesconfig gcc cskydefconfig gcc hexagon randconfig-001-20230831 clang hexagon randconfig-001-20230901 clang hexagon randconfig-002-20230831 clang hexagon randconfig-002-20230901 clang hexagon randconfig-r005-20230901 clang hexagon randconfig-r013-20230831 clang hexagon randconfig-r036-20230901 clang i386 allmodconfig gcc i386 allnoconfig gcc i386 allyesconfig gcc i386 buildonly-randconfig-001-20230831 gcc i386 buildonly-randconfig-002-20230831 gcc i386 buildonly-randconfig-003-20230831 gcc i386 buildonly-randconfig-004-20230831 gcc i386 buildonly-randconfig-005-20230831 gcc i386 buildonly-randconfig-006-20230831 gcc i386 debian-10.3 gcc i386defconfig gcc i386 randconfig-001-20230831 gcc i386 randconfig-002-20230831 gcc i386 randconfig-003-20230831 gcc i386 randconfig-004-20230831 gcc i386 randconfig-005-20230831 gcc i386 randconfig-006-20230831 gcc i386 randconfig-011-20230831 clang i386 randconfig-011-20230901 gcc i386 randconfig-012-20230831 clang i386 randconfig-012-20230901 gcc i386 randconfig-013-20230831 clang i386 randconfig-013-20230901 gcc i386 randconfig-014-20230831 clang i386 randconfig-014-20230901 gcc i386 randconfig-015-20230831 clang i386 randconfig-016-20230831 clang i386 randconfig-r003-20230831 gcc i386 randconfig-r012-20230831 clang i386 randconfig-r013-20230831 clang i386 randconfig-r022-20230831 clang loongarchallmodconfig gcc loongarch allnoconfig gcc loongarchallyesconfig gcc loongarch defconfig gcc loongarch randconfig-001-20230831 gcc loongarchrandconfig-r003-20230901 gcc loongarchrandconfig-r012-20230901 gcc loongarchrandconfig-r035-20230901 gcc m68k allmodconfig gcc m68k allnoconfig gcc m68k
[powerpc:merge] BUILD SUCCESS 5c28fde1e3240c87cae1ed98a82a10118fdfa9d7
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git merge branch HEAD: 5c28fde1e3240c87cae1ed98a82a10118fdfa9d7 Automatic merge of 'next' into merge (2023-08-31 22:11) elapsed time: 1024m configs tested: 204 configs skipped: 2 The following configs have been built successfully. More configs may be tested in the coming days. tested configs: alpha allnoconfig gcc alphaallyesconfig gcc alpha defconfig gcc alpharandconfig-r026-20230901 gcc arc allmodconfig gcc arc allnoconfig gcc arc allyesconfig gcc arc defconfig gcc arc randconfig-001-20230901 gcc arc randconfig-r013-20230901 gcc arm allmodconfig gcc arm allnoconfig gcc arm allyesconfig gcc arm defconfig gcc arm randconfig-001-20230901 clang arm randconfig-r005-20230901 gcc arm randconfig-r012-20230901 clang arm randconfig-r016-20230901 clang arm randconfig-r021-20230901 clang arm randconfig-r033-20230901 gcc arm64allmodconfig gcc arm64 allnoconfig gcc arm64allyesconfig gcc arm64 defconfig gcc arm64randconfig-r004-20230901 clang arm64randconfig-r013-20230901 gcc arm64randconfig-r022-20230901 gcc csky allmodconfig gcc csky allnoconfig gcc csky allyesconfig gcc cskydefconfig gcc csky randconfig-r003-20230901 gcc csky randconfig-r011-20230901 gcc csky randconfig-r023-20230901 gcc csky randconfig-r025-20230901 gcc hexagon randconfig-001-20230901 clang hexagon randconfig-002-20230901 clang hexagon randconfig-r032-20230901 clang hexagon randconfig-r033-20230901 clang hexagon randconfig-r036-20230901 clang i386 allmodconfig gcc i386 allnoconfig gcc i386 allyesconfig gcc i386 buildonly-randconfig-001-20230901 clang i386 buildonly-randconfig-002-20230901 clang i386 buildonly-randconfig-003-20230901 clang i386 buildonly-randconfig-004-20230901 clang i386 buildonly-randconfig-005-20230901 clang i386 buildonly-randconfig-006-20230901 clang i386 debian-10.3 gcc i386defconfig gcc i386 randconfig-001-20230901 clang i386 randconfig-002-20230901 clang i386 randconfig-003-20230901 clang i386 randconfig-004-20230901 clang i386 randconfig-005-20230901 clang i386 randconfig-006-20230901 clang i386 randconfig-011-20230901 gcc i386 randconfig-012-20230901 gcc i386 randconfig-013-20230901 gcc i386 randconfig-014-20230901 gcc i386 randconfig-015-20230901 gcc i386 randconfig-016-20230901 gcc i386 randconfig-r006-20230901 clang i386 randconfig-r015-20230901 gcc loongarchallmodconfig gcc loongarch allnoconfig gcc loongarchallyesconfig gcc loongarch defconfig gcc loongarch randconfig-001-20230901 gcc loongarchrandconfig-r013-20230901 gcc loongarchrandconfig-r016-20230901 gcc m68k allmodconfig gcc m68k allnoconfig gcc m68k allyesconfig gcc m68kdefconfig gcc m68k randconfig-r011-20230901 gcc m68k randconfig-r031-20230901 gcc m68k randconfig-r035-20230901 gcc microblaze allmodconfig gcc microblazeallnoconfig gcc microblaze allyesconfig gcc microblaze defconfig gcc microblaze randconfig-r021-20230901 gcc microblaze randconfig-r024-20230901 gcc microblaze
Re: [RFC PATCH v11 12/29] KVM: Add KVM_CREATE_GUEST_MEMFD ioctl() for guest-specific backing memory
On 8/31/2023 12:44 AM, Ackerley Tng wrote:
Binbin Wu writes:
+static long kvm_gmem_allocate(struct inode *inode, loff_t offset, loff_t len)
+{
+ struct address_space *mapping = inode->i_mapping;
+ pgoff_t start, index, end;
+ int r;
+
+ /* Dedicated guest is immutable by default. */
+ if (offset + len > i_size_read(inode))
+ return -EINVAL;
+
+ filemap_invalidate_lock_shared(mapping);
+
+ start = offset >> PAGE_SHIFT;
+ end = (offset + len) >> PAGE_SHIFT;
+
+ r = 0;
+ for (index = start; index < end; ) {
+ struct folio *folio;
+
+ if (signal_pending(current)) {
+ r = -EINTR;
+ break;
+ }
+
+ folio = kvm_gmem_get_folio(inode, index);
+ if (!folio) {
+ r = -ENOMEM;
+ break;
+ }
+
+ index = folio_next_index(folio);
+
+ folio_unlock(folio);
+ folio_put(folio);
May be a dumb question, why we get the folio and then put it immediately?
Will it make the folio be released back to the page allocator?
I was wondering this too, but it is correct.
In filemap_grab_folio(), the refcount is incremented in three places:
+ When the folio is created in filemap_alloc_folio(), it is given a
refcount of 1 in
filemap_alloc_folio() -> folio_alloc() -> __folio_alloc_node() ->
__folio_alloc() -> __alloc_pages() -> get_page_from_freelist() ->
prep_new_page() -> post_alloc_hook() -> set_page_refcounted()
+ Then, in filemap_add_folio(), the refcount is incremented twice:
+ The first is from the filemap (1 refcount per page if this is a
hugepage):
filemap_add_folio() -> __filemap_add_folio() -> folio_ref_add()
+ The second is a refcount from the lru list
filemap_add_folio() -> folio_add_lru() -> folio_get() ->
folio_ref_inc()
In the other path, if the folio exists in the page cache (filemap), the
refcount is also incremented through
filemap_grab_folio() -> __filemap_get_folio() -> filemap_get_entry()
-> folio_try_get_rcu()
I believe all the branches in kvm_gmem_get_folio() are taking a refcount
on the folio while the kernel does some work on the folio like clearing
the folio in clear_highpage() or getting the next index, and then when
done, the kernel does folio_put().
This pattern is also used in shmem and hugetlb. :)
Thanks for your explanation. It helps a lot.
I'm not sure whose refcount the folio_put() in kvm_gmem_allocate() is
dropping though:
+ The refcount for the filemap depends on whether this is a hugepage or
not, but folio_put() strictly drops a refcount of 1.
+ The refcount for the lru list is just 1, but doesn't the page still
remain in the lru list?
I guess the refcount drop here is the one get on the fresh allocation.
Now the filemap has grabbed the folio, so the lifecycle of the folio now
is decided by the filemap/inode?
+
+ /* 64-bit only, wrapping the index should be impossible. */
+ if (WARN_ON_ONCE(!index))
+ break;
+
+ cond_resched();
+ }
+
+ filemap_invalidate_unlock_shared(mapping);
+
+ return r;
+}
+
[PATCH v2 3/3] kconfig: add dependencies of POWER_RESET for PowerMac
PowerMac's power off depends on ADB_CUDA to work. Enable it when POWER_RESET is set for convenience. Suggested-by: Zhangjin Wu Signed-off-by: Yuan Tan --- arch/powerpc/platforms/powermac/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/platforms/powermac/Kconfig b/arch/powerpc/platforms/powermac/Kconfig index 130707ec9f99..9e633d7e8367 100644 --- a/arch/powerpc/platforms/powermac/Kconfig +++ b/arch/powerpc/platforms/powermac/Kconfig @@ -2,6 +2,7 @@ config PPC_PMAC bool "Apple PowerMac based machines" depends on PPC_BOOK3S && CPU_BIG_ENDIAN + select ADB_CUDA if POWER_RESET select MPIC select FORCE_PCI select PPC_INDIRECT_PCI if PPC32 -- 2.34.1
[PATCH v2 2/3] kconfig: add dependencies of POWER_RESET for x86
x86 and x86_64's power off depends on ACPI and PCI to work. Enable them when POWER_RESET is set for convenience. Suggested-by: Zhangjin Wu Signed-off-by: Yuan Tan --- arch/x86/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 982b777eadc7..5c1632e40bf2 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -58,6 +58,7 @@ config X86 # # Note: keep this list sorted alphabetically # + select ACPI if POWER_RESET select ACPI_LEGACY_TABLES_LOOKUPif ACPI select ACPI_SYSTEM_POWER_STATES_SUPPORT if ACPI select ARCH_32BIT_OFF_T if X86_32 @@ -286,6 +287,7 @@ config X86 select NEED_PER_CPU_EMBED_FIRST_CHUNK select NEED_PER_CPU_PAGE_FIRST_CHUNK select NEED_SG_DMA_LENGTH + select PCI if POWER_RESET select PCI_DOMAINS if PCI select PCI_LOCKLESS_CONFIG if PCI select PERF_EVENTS -- 2.34.1
[PATCH v2 1/3] kconfig: add dependencies of POWER_RESET for mips malta
MIPS Malta's power off depends on PCI, PCI_QUIRKS, and POWER_RESET_PIIX4_POWEROFF to work. Enable them when POWER_RESET is set for convenience. Suggested-by: Zhangjin Wu Signed-off-by: Yuan Tan --- arch/mips/Kconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index bc8421859006..13bacbd05125 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -547,6 +547,9 @@ config MIPS_MALTA select MIPS_L1_CACHE_SHIFT_6 select MIPS_MSC select PCI_GT64XXX_PCI0 + select PCI if POWER_RESET + select PCI_QUIRKS if POWER_RESET + select POWER_RESET_PIIX4_POWEROFF if POWER_RESET select SMP_UP if SMP select SWAP_IO_SPACE select SYS_HAS_CPU_MIPS32_R1 -- 2.34.1
[PATCH v2 0/3] Add dependencies of POWER_RESET for MIPS Malta, x86, and PowerMac
These patches are to add dependencies of POWER_RESET for MIPS Malta, x86, and PowerMac. I am really sorry I forget to use --thread in v1[1] as I stayed up too late. So here I am resending v2 patch with a mirror fix and consolidating them into a thread. To simplify the enablement of the poweroff support, selecting the required options for CONFIG_POWER_RESET=y may make many people happy especially when they are using a customized config (maybe tinyconfig based) for a target qemu board. Without normal poweroff support from the kernel side, qemu will simply hang[2] there after a 'poweroff' command, which is a very bad experience for the automatical tests. Currently, based on tinyconfig, it is very hard to find the exact poweroff options[3]. Some architectures' poweroff works well without any dependence, the others' poweroff options are hidden deeply, which make things hard. After multiple verifications, these options have been identified as the minimum dependencies required for poweroff to function normally. Zhangjin and I invested a significant amount of time in searching for the current options on these devices. We hope that this set of patches will save time for others. If community like it, we will consider adding dependencies for POWER_RESET on other devices. --- [1]: https://lore.kernel.org/lkml/20230831201727.3177853-1-tany...@tinylab.org/ [2]: https://lore.kernel.org/lkml/511b2f6009fb830b3f32b4be3dca99596c684fa3.1689759351.git.fal...@tinylab.org/ [3]: https://lore.kernel.org/all/983843582e52e83fba79ad45cea6c79e1f62ec6c.1690489039.git.fal...@tinylab.org/ --- Changes since v1: - Fix the mistake of using spaces instead of tabs in kconfig. Yuan Tan (3): kconfig: add dependencies of POWER_RESET for mips malta kconfig: add dependencies of POWER_RESET for x86 kconfig: add dependencies of POWER_RESET for PowerMac arch/mips/Kconfig | 3 +++ arch/powerpc/platforms/powermac/Kconfig | 1 + arch/x86/Kconfig| 2 ++ 3 files changed, 6 insertions(+) -- 2.34.1
Re: Framebuffer mmap on PowerPC
On Thu, Aug 31, 2023, at 10:41, Thomas Zimmermann wrote: > Hi, > > there's a per-architecture function called fb_pgprotect() that sets > VMA's vm_page_prot for mmaped framebuffers. Most architectures use a > simple implementation based on pgprot_writecomine() [1] or > pgprot_noncached(). [2] > > On PPC this function uses phys_mem_access_prot() and therefore requires > the mmap call's file struct. [3] Removing the file argument would help > with simplifying the caller of fb_pgprotect(). [4] > > Why is the file even required on PPC? > > Is it possible to replace phys_mem_access_prot() with something simpler > that does not use the file struct? What what I can tell, the structure of the code is a result of these constraints: - some powerpc platforms use different page table flags for prefetchable vs nonprefetchable BARs on PCI memory. - page table flags must match between all mappings, in particular here between /dev/fb0 and /dev/mem, as mismatched attributes cause a checkstop. On other architectures this may cause undefined behavior instead of a checkstop It's unfortunate that we have multiple incompatible ways to determine the page flags based on firmware (ia64), pci (powerpc) or file->f_flags (arm, csky), when they all try to solve the same problem here. Christophe's suggested approach to simplify it is probably fine, another way would be to pass the f_flags value instead of the file pointer. Arnd
Re: KASAN debug kernel fails to boot at early stage when CONFIG_SMP=y is set (kernel 6.5-rc5, PowerMac G4 3,6)
On Thu, 31 Aug 2023 05:32:46 + Christophe Leroy wrote: > Ok so there is some corrupted memory somewhere. > > Can you try what happens when you remove the call to kasan_init() at the > start of setup_arch() in arch/powerpc/kernel/setup-common.c Ok, so I left the other patches in place + btext_map() instead of btext_unmap() at the end of MMU_init() + Michaels patch and additionally commented-out kasan_init() as stated above. The outcome is rather interesting! Now I deterministically get this output at boot OF console, regardless wheter it's a cold boot or warm boot: via-pmu: Server Mode is disabled PMU driver v2 initialized for Core99, firmware: 0c ioremap() called early from pmac_nvram_init+0x208/0x7c0. Use early_ioremap() instead nvram: Checking bank 0... nvram: gen0=3234, gen1=3235 nvram: Active bank is: 1 nvram: OF partition at 0x410 nvram: XP partition at 0x1020 nvram: NR partition at 0x1120 Top of RAM: 0x8000, Total RAM: 0x8000 Memory hole size: 0MB Zone ranges: DMA [mem 0x-0x2fff] Normal empty HighMem [mem 0x3000-0x7fff] Movable zone start for each node Early memory node ranges node 0: [mem 0x-0x7fff] Initmem setup node 0 [mem 0x-0x7fff] percpu: Embedded 14 pages/cpu s24608 r8192 d24544 u57344 pcpu-alloc: s24608 r8192 d24544 u57344 alloc=14*4096 pcpu-alloc: [0] 0 Kernel command line: ro root=/dev/sda5 nr_cpus=1 zswap.max_pool_percent=16 slub_debug=FZP page_poison=1 netconsole=@192.168.178.8/eth0,@192.168.178.3/70:85:C2:30:EC:01 init=/usr/lib/systemd/systemd Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear) Built 1 zonelists, mobility grouping on. Total pages: 522560 mem auto-init: stack:all(pattern), heap alloc:off, heap free:off stackdepot: allocating hash table via alloc_large_system_hash stackdepot hash table entries: 1048576 (order: 10, 4194304 bytes, linear) == BUG: KASAN: stack-out-of-bounds in __kernel_poison_pages+0x6c/0xd0 Write of size 4896 at addr c17a7000 by task swapper/0 CPU: 0 PID: 0 Comm: swapper Tainted: GT 6.5.0-rc7-PMacG4-dirty #7 Hardware name: PowerMac3,6 7455 0x80010303 PowerMac Call Trace: [c1717ce0] [c0f4ec40] dump_stack_lvl+0x60/0xa4 (unreliable) [c1717d00] [c0368380] print_report+0x154/0x548 [c1717d50] [c036813c] kasan_report+0xd0/0x160 [c1717db0] [c0369bb4] kasan_check_range+0x1c8/0x308 [c1717dc0] [c036ae88] memset+0x34/0x90 [c1717de0] [c035b6e0] __kernel_poison_pages+0x6c/0xd0 [c1717e00] [c03355e4] __free_pages_ok+0x418/0x500 [c1717e60] [c14372c8] memblock_free_all+0x268/0x400 [c1717f20] [c14103fc] mem_init+0x8c/0x274 [c1717f60] [c1431cd0] mm_core_init+0x240/0x4e0 [c1717fc0] [c1404694] start_kernel+0x150/0x2d8 [c1717f00] [35d0] 0x35d0 The buggy address belongs to the physical page: page:(ptrval) refcount:0 mapcount:0 mapping: index:0x0 pfn:0x17a7 flags: 0x0(zone=0) page_type: 0x() raw: eee15380 eee15380 raw: page dumped because: kasan: bad access detected Memory state around the buggy address: c17a7d00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 c17a7d80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >c17a7e00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 ^ c17a7e80: f1 f1 04 f2 04 f2 00 f3 f3 f3 00 00 00 00 00 00 c17a7f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 == Disabling lock debugging due to kernel taint > I'd also be curious to know what happens when CONFIG_DEBUG_SPINLOCK is > disabled. Disabling CONFIG_DEBUG_SPINLOCK does not change the output above. ^^ > Another question which I'm no sure I asked already: Is it a new problem > you have got with recent kernels or is it just that you never tried such > a config with older kernels ? I wanted to revisit https://bugzilla.kernel.org/show_bug.cgi?id=216041 and verify whether it was resolved. KASAN worked around 2019-2021 on my G4 as I reported some bugs with it around that time and you fixed some of the bugs. ;) Like kernel bugzilla #205099, #216190, #205885. But it always seemed flaky on the G4 and had it's problems. So I can't tell whether this specific issue was there back then or if it's new. At least bug #216190 was also about KASAN and SMP issues. > Also, when you say you need to start with another SMP kernel first and > then you don't have the problem anymore until the next cold reboot, do > you mean you have some old kernel with KASAN that works, or is it a > kernel without KASAN that you have to start first ? First. I start with a non-KASAN SMP kernel and afterwards reboot into a KASAN kernel. But now with kasan_init() commented-out in start
Re: [RFC PATCH v2 0/7] Add audio support in v4l2 framework
Hi, Le jeudi 24 août 2023 à 19:03 +0200, Takashi Iwai a écrit : > > 3. How to handle the xrun issue. pause or resume. which are brought by ALSA. > > Doesn't V4L2 handle the overrun/underrun at all? Also, no resume > support? just a 2 cents comment. All our video m2m are job based. When there is no job available they stop and resume when there is more work in queues. As there is no time constraints coming from the hardware, there is also no API to know that there has been a period of time without anything being executed (under utilization). Only overrun can be detected by application, each chunk of work is in its own v4l2_buffer and the application will run out of buffer in that case, and will have to wait for free space in the queue. Understand though that the larger the queue, the large the latency. There is currently no way to submit job ahead of the data (unlike DRM subsystem). I have slight impression that all this seems rather inefficient for high rate / small buffer. I'd suggest creating a dummy benchmark driver to verify that the overhead isn't just too much for an audio use case. Nicolas
Framebuffer mmap on PowerPC
Hi, there's a per-architecture function called fb_pgprotect() that sets VMA's vm_page_prot for mmaped framebuffers. Most architectures use a simple implementation based on pgprot_writecomine() [1] or pgprot_noncached(). [2] On PPC this function uses phys_mem_access_prot() and therefore requires the mmap call's file struct. [3] Removing the file argument would help with simplifying the caller of fb_pgprotect(). [4] Why is the file even required on PPC? Is it possible to replace phys_mem_access_prot() with something simpler that does not use the file struct? Best regards Thomas [1] https://elixir.bootlin.com/linux/v6.5/source/include/asm-generic/fb.h#L19 [2] https://elixir.bootlin.com/linux/v6.5/source/arch/mips/include/asm/fb.h#L11 [3] https://elixir.bootlin.com/linux/v6.5/source/arch/powerpc/include/asm/fb.h#L12 [4] https://elixir.bootlin.com/linux/v6.5/source/drivers/video/fbdev/core/fbmem.c#L1299 -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Frankenstrasse 146, 90461 Nuernberg, Germany GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman HRB 36809 (AG Nuernberg) OpenPGP_signature Description: OpenPGP digital signature
Re: [PATCH v7 5/8] KVM: x86/mmu: Don't pass FOLL_GET to __kvm_follow_pfn
On Fri, Aug 25, 2023, David Stevens wrote:
> On Fri, Aug 25, 2023 at 12:15 AM Sean Christopherson
> wrote:
> >
> > On Thu, Aug 24, 2023, David Stevens wrote:
> > > On Wed, Jul 5, 2023 at 7:25 PM Yu Zhang
> > > wrote:
> > > >
> > > > On Tue, Jul 04, 2023 at 04:50:50PM +0900, David Stevens wrote:
> > > > > @@ -4529,7 +4540,8 @@ static int kvm_tdp_mmu_page_fault(struct
> > > > > kvm_vcpu *vcpu,
> > > > >
> > > > > out_unlock:
> > > > > read_unlock(>kvm->mmu_lock);
> > > > > - kvm_release_pfn_clean(fault->pfn);
> > > >
> > > > Yet kvm_release_pfn() can still be triggered for the kvm_vcpu_maped
> > > > gfns.
> > > > What if guest uses a non-referenced page(e.g., as a vmcs12)? Although I
> > > > believe this is not gonna happen in real world...
> > >
> > > kvm_vcpu_map still uses gfn_to_pfn, which eventually passes FOLL_GET
> > > to __kvm_follow_pfn. So if a guest tries to use a non-refcounted page
> > > like that, then kvm_vcpu_map will fail and the guest will probably
> > > crash. It won't trigger any bugs in the host, though.
> > >
> > > It is unfortunate that the guest will be able to use certain types of
> > > memory for some purposes but not for others. However, while it is
> > > theoretically fixable, it's an unreasonable amount of work for
> > > something that, as you say, nobody really cares about in practice [1].
> > >
> > > [1] https://lore.kernel.org/all/zbeeqtmtnpaeq...@google.com/
> >
> > There are use cases that care, which is why I suggested allow_unsafe_kmap.
> > Specifically, AWS manages their pool of guest memory in userspace and maps
> > it all
> > via /dev/mem. Without that module param to let userspace opt-in, this
> > series will
> > break such setups. It still arguably is a breaking change since it requires
> > userspace to opt-in, but allowing such behavior by default is simply not a
> > viable
> > option, and I don't have much sympathy since so much of this mess has its
> > origins
> > in commit e45adf665a53 ("KVM: Introduce a new guest mapping API").
> >
> > The use cases that no one cares about (AFAIK) is allowing _untrusted_
> > userspace
> > to back guest RAM with arbitrary memory. In other words, I want KVM to
> > allow
> > (by default) mapping device memory into the guest for things like vGPUs,
> > without
> > having to do the massive and invasive overhaul needed to safely allow
> > backing guest
> > RAM with completely arbitrary memory.
>
> Do you specifically want the allow_unsafe_kmap breaking change? v7 of
> this series should have supported everything that is currently
> supported by KVM, but you're right that the v8 version of
> hva_to_pfn_remapped doesn't support mapping
> !kvm_pfn_to_refcounted_page() pages. That could be supported
> explicitly with allow_unsafe_kmap as you suggested,
I think it needs to be explicit, i.e. needs the admin to opt-in to the unsafe
behavior.
RE: [PATCH v10 13/15] PCI/AER: Forward RCH downstream port-detected errors to the CXL.mem dev handler
Terry Bowman wrote:
> From: Robert Richter
>
> In Restricted CXL Device (RCD) mode a CXL device is exposed as an
> RCiEP, but CXL downstream and upstream ports are not enumerated and
> not visible in the PCIe hierarchy. [1] Protocol and link errors from
> these non-enumerated ports are signaled as internal AER errors, either
> Uncorrectable Internal Error (UIE) or Corrected Internal Errors (CIE)
> via an RCEC.
>
> Restricted CXL host (RCH) downstream port-detected errors have the
> Requester ID of the RCEC set in the RCEC's AER Error Source ID
> register. A CXL handler must then inspect the error status in various
> CXL registers residing in the dport's component register space (CXL
> RAS capability) or the dport's RCRB (PCIe AER extended
> capability). [2]
>
> Errors showing up in the RCEC's error handler must be handled and
> connected to the CXL subsystem. Implement this by forwarding the error
> to all CXL devices below the RCEC. Since the entire CXL device is
> controlled only using PCIe Configuration Space of device 0, function
> 0, only pass it there [3]. The error handling is limited to currently
> supported devices with the Memory Device class code set (CXL Type 3
> Device, PCI_CLASS_MEMORY_CXL, 502h), handle downstream port errors in
> the device's cxl_pci driver. Support for other CXL Device Types
> (e.g. a CXL.cache Device) can be added later.
>
> To handle downstream port errors in addition to errors directed to the
> CXL endpoint device, a handler must also inspect the CXL RAS and PCIe
> AER capabilities of the CXL downstream port the device is connected
> to.
>
> Since CXL downstream port errors are signaled using internal errors,
> the handler requires those errors to be unmasked. This is subject of a
> follow-on patch.
>
> The reason for choosing this implementation is that the AER service
> driver claims the RCEC device, but does not allow it to register a
> custom specific handler to support CXL. Connecting the RCEC hard-wired
> with a CXL handler does not work, as the CXL subsystem might not be
> present all the time. The alternative to add an implementation to the
> portdrv to allow the registration of a custom RCEC error handler isn't
> worth doing it as CXL would be its only user. Instead, just check for
> an CXL RCEC and pass it down to the connected CXL device's error
> handler. With this approach the code can entirely be implemented in
> the PCIe AER driver and is independent of the CXL subsystem. The CXL
> driver only provides the handler.
>
> [1] CXL 3.0 spec: 9.11.8 CXL Devices Attached to an RCH
> [2] CXL 3.0 spec, 12.2.1.1 RCH Downstream Port-detected Errors
> [3] CXL 3.0 spec, 8.1.3 PCIe DVSEC for CXL Devices
>
> Co-developed-by: Terry Bowman
> Signed-off-by: Terry Bowman
> Signed-off-by: Robert Richter
> Cc: "Oliver O'Halloran"
> Cc: Bjorn Helgaas
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: linux-...@vger.kernel.org
> Acked-by: Bjorn Helgaas
> Reviewed-by: Jonathan Cameron
> Reviewed-by: Dave Jiang
> ---
> drivers/pci/pcie/Kconfig | 12 +
> drivers/pci/pcie/aer.c | 96 +++-
> 2 files changed, 106 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/pcie/Kconfig b/drivers/pci/pcie/Kconfig
> index 228652a59f27..4f0e70fafe2d 100644
> --- a/drivers/pci/pcie/Kconfig
> +++ b/drivers/pci/pcie/Kconfig
> @@ -49,6 +49,18 @@ config PCIEAER_INJECT
> gotten from:
>
> https://git.kernel.org/cgit/linux/kernel/git/gong.chen/aer-inject.git/
>
> +config PCIEAER_CXL
> + bool "PCI Express CXL RAS support for Restricted Hosts (RCH)"
Why the "for Restricted Hosts (RCH)" clarification? I am seeing nothing
that prevents this from working with RCECs on VH topologies.
> + default y
Minor, but I think "default PCIEAER" makes it slightly clearer that CXL
error handling comes along for the ride with PCIE AER.
> + depends on PCIEAER && CXL_PCI
> + help
> + Enables error handling of downstream ports of a CXL host
> + that is operating in RCD mode (Restricted CXL Host, RCH).
> + The downstream port reports AER errors to a given RCEC.
> + Errors are handled by the CXL memory device driver.
> +
> + If unsure, say Y.
> +
> #
> # PCI Express ECRC
> #
> diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
> index d3344fcf1f79..c354ca5e8f2b 100644
> --- a/drivers/pci/pcie/aer.c
> +++ b/drivers/pci/pcie/aer.c
> @@ -946,14 +946,100 @@ static bool find_source_device(struct pci_dev *parent,
> return true;
> }
>
> +#ifdef CONFIG_PCIEAER_CXL
> +
> +static bool is_cxl_mem_dev(struct pci_dev *dev)
> +{
> + /*
> + * The capability, status, and control fields in Device 0,
> + * Function 0 DVSEC control the CXL functionality of the
> + * entire device (CXL 3.0, 8.1.3).
> + */
> + if (dev->devfn != PCI_DEVFN(0, 0))
> + return false;
> +
> + /*
> + * CXL Memory Devices must have the 502h class code set (CXL
> + *
[PATCH v1 0/3] Add dependencies of POWER_RESET for MIPS Malta, x86, and PowerMac.
These patches is to add dependencies of POWER_RESET for MIPS Malta, x86, and PowerMac. To simplify the enablement of the poweroff support, selecting the required options for CONFIG_POWER_RESET=y may make many people happyespecially when they are using a customized config (maybe tinyconfigbased) for a target qemu board. Without normal poweroff support from the kernel side, qemu will simply hang[1] there after a 'poweroff' command, which is a very bad experience for the automatical tests. Currently, based on tinyconfig, it is very hard to find the exact poweroff options[2]. Some architectures' poweroff works well without any dependence, the others' poweroff options are hidden deeply, which make things hard. After multiple verifications, these options have been identified as the minimum dependencies required for poweroff to function normally. Zhangjin and I invested a significant amount of time in searching for the current options on these devices. We hope that this set of patcheswill save time for others. If community like it, we will consider adding dependencies for POWER_RESET on other devices. --- [1]: https://lore.kernel.org/lkml/511b2f6009fb830b3f32b4be3dca99596c684fa3.1689759351.git.fal...@tinylab.org/ [2]: https://lore.kernel.org/all/983843582e52e83fba79ad45cea6c79e1f62ec6c.1690489039.git.fal...@tinylab.org/ Yuan Tan (3): kconfig: add dependencies of POWER_RESET for mips malta kconfig: add dependencies of POWER_RESET for x86 kconfig: add dependencies of POWER_RESET for PowerMac arch/mips/Kconfig | 3 +++ arch/powerpc/platforms/powermac/Kconfig | 1 + arch/x86/Kconfig| 2 ++ 3 files changed, 6 insertions(+) -- 2.34.1
[PATCH v1 1/3] kconfig: add dependencies of POWER_RESET for mips malta
MIPS Malta's power off depends on PCI, PCI_QUIRKS, and POWER_RESET_PIIX4_POWEROFF to work. Enable them when POWER_RESET is set for convenience. Suggested-by: Zhangjin Wu Signed-off-by: Yuan Tan --- arch/mips/Kconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index bc8421859006..1d93f3fd0552 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -547,6 +547,9 @@ config MIPS_MALTA select MIPS_L1_CACHE_SHIFT_6 select MIPS_MSC select PCI_GT64XXX_PCI0 + select PCI if POWER_RESET +select PCI_QUIRKS if POWER_RESET +select POWER_RESET_PIIX4_POWEROFF if POWER_RESET select SMP_UP if SMP select SWAP_IO_SPACE select SYS_HAS_CPU_MIPS32_R1 -- 2.34.1
[PATCH v1 2/3] kconfig: add dependencies of POWER_RESET for x86
x86 and x86_64's power off depends on ACPI and PCI to work. Enable them when POWER_RESET is set for convenience. Suggested-by: Zhangjin Wu Signed-off-by: Yuan Tan --- arch/x86/Kconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 982b777eadc7..5c1632e40bf2 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -58,6 +58,7 @@ config X86 # # Note: keep this list sorted alphabetically # + select ACPI if POWER_RESET select ACPI_LEGACY_TABLES_LOOKUPif ACPI select ACPI_SYSTEM_POWER_STATES_SUPPORT if ACPI select ARCH_32BIT_OFF_T if X86_32 @@ -286,6 +287,7 @@ config X86 select NEED_PER_CPU_EMBED_FIRST_CHUNK select NEED_PER_CPU_PAGE_FIRST_CHUNK select NEED_SG_DMA_LENGTH + select PCI if POWER_RESET select PCI_DOMAINS if PCI select PCI_LOCKLESS_CONFIG if PCI select PERF_EVENTS -- 2.34.1
[PATCH v1 3/3] kconfig: add dependencies of POWER_RESET for PowerMac
PowerMac's power off depends on ADB_CUDA to work. Enable it when POWER_RESET is set for convenience. Suggested-by: Zhangjin Wu Signed-off-by: Yuan Tan --- arch/powerpc/platforms/powermac/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/powerpc/platforms/powermac/Kconfig b/arch/powerpc/platforms/powermac/Kconfig index 130707ec9f99..9e633d7e8367 100644 --- a/arch/powerpc/platforms/powermac/Kconfig +++ b/arch/powerpc/platforms/powermac/Kconfig @@ -2,6 +2,7 @@ config PPC_PMAC bool "Apple PowerMac based machines" depends on PPC_BOOK3S && CPU_BIG_ENDIAN + select ADB_CUDA if POWER_RESET select MPIC select FORCE_PCI select PPC_INDIRECT_PCI if PPC32 -- 2.34.1
Re: [GIT PULL] Please pull powerpc/linux.git powerpc-6.6-1 tag
The pull request you sent on Thu, 31 Aug 2023 22:42:24 +1000: > https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git > tags/powerpc-6.6-1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/4ad0a4c2343d3981e92df2b39fa262be62a9091a Thank you! -- Deet-doot-dot, I am a bot. https://korg.docs.kernel.org/prtracker.html
[PATCH v3] kbuild: Show marked Kconfig fragments in "help"
Currently the Kconfig fragments in kernel/configs and arch/*/configs that aren't used internally aren't discoverable through "make help", which consists of hard-coded lists of config fragments. Instead, list all the fragment targets that have a "# Help: " comment prefix so the targets can be generated dynamically. Add logic to the Makefile to search for and display the fragment and comment. Add comments to fragments that are intended to be direct targets. Cc: Nicolas Schier Cc: Michael Ellerman Cc: Christophe Leroy Cc: Randy Dunlap Cc: linux-ker...@vger.kernel.org Cc: x...@kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-ri...@lists.infradead.org Cc: linux-s...@vger.kernel.org Cc: linux-kbu...@vger.kernel.org Cc: linux-harden...@vger.kernel.org Signed-off-by: Kees Cook Co-developed-by: Masahiro Yamada --- v3: - Use Makefile logic from Masahiro Yamada - Use "# Help: " prefix, but only on desired fragment targets v2: https://lore.kernel.org/all/20230825194329.gonna.911-k...@kernel.org v1: https://lore.kernel.org/all/20230824223606.never.762-k...@kernel.org --- Makefile | 1 - arch/arm/configs/dram_0x.config| 1 + arch/arm/configs/dram_0xc000.config| 1 + arch/arm/configs/dram_0xd000.config| 1 + arch/arm/configs/lpae.config | 1 + arch/arm64/configs/virt.config | 1 + arch/powerpc/configs/disable-werror.config | 1 + arch/powerpc/configs/security.config | 4 +++- arch/riscv/configs/32-bit.config | 1 + arch/riscv/configs/64-bit.config | 1 + arch/s390/configs/btf.config | 1 + arch/s390/configs/kasan.config | 1 + arch/x86/Makefile | 4 kernel/configs/debug.config| 2 ++ kernel/configs/kvm_guest.config| 1 + kernel/configs/nopm.config | 2 ++ kernel/configs/rust.config | 1 + kernel/configs/tiny.config | 2 ++ kernel/configs/x86_debug.config| 1 + kernel/configs/xen.config | 2 ++ scripts/kconfig/Makefile | 15 --- 21 files changed, 36 insertions(+), 9 deletions(-) diff --git a/Makefile b/Makefile index 4739c21a63e2..91c90ce8e0e3 100644 --- a/Makefile +++ b/Makefile @@ -1674,7 +1674,6 @@ help: @echo ' mrproper- Remove all generated files + config + various backup files' @echo ' distclean - mrproper + remove editor backup and patch files' @echo '' - @echo 'Configuration targets:' @$(MAKE) -f $(srctree)/scripts/kconfig/Makefile help @echo '' @echo 'Other generic targets:' diff --git a/arch/arm/configs/dram_0x.config b/arch/arm/configs/dram_0x.config index db96dcb420ce..8803a0f58343 100644 --- a/arch/arm/configs/dram_0x.config +++ b/arch/arm/configs/dram_0x.config @@ -1 +1,2 @@ +# Help: DRAM base at 0x CONFIG_DRAM_BASE=0x diff --git a/arch/arm/configs/dram_0xc000.config b/arch/arm/configs/dram_0xc000.config index 343d5333d973..aab8f864686b 100644 --- a/arch/arm/configs/dram_0xc000.config +++ b/arch/arm/configs/dram_0xc000.config @@ -1 +1,2 @@ +# Help: DRAM base at 0xc000 CONFIG_DRAM_BASE=0xc000 diff --git a/arch/arm/configs/dram_0xd000.config b/arch/arm/configs/dram_0xd000.config index 61ba7045f8a1..4aabce4ea3d4 100644 --- a/arch/arm/configs/dram_0xd000.config +++ b/arch/arm/configs/dram_0xd000.config @@ -1 +1,2 @@ +# Help: DRAM base at 0xd000 CONFIG_DRAM_BASE=0xd000 diff --git a/arch/arm/configs/lpae.config b/arch/arm/configs/lpae.config index a6d6f7ab3c01..1ab94da8345d 100644 --- a/arch/arm/configs/lpae.config +++ b/arch/arm/configs/lpae.config @@ -1,2 +1,3 @@ +# Help: Enable Large Physical Address Extension mode CONFIG_ARM_LPAE=y CONFIG_VMSPLIT_2G=y diff --git a/arch/arm64/configs/virt.config b/arch/arm64/configs/virt.config index 6865d54e68f8..c47c36f8f67b 100644 --- a/arch/arm64/configs/virt.config +++ b/arch/arm64/configs/virt.config @@ -1,3 +1,4 @@ +# Help: Virtualization guest # # Base options for platforms # diff --git a/arch/powerpc/configs/disable-werror.config b/arch/powerpc/configs/disable-werror.config index 6ea12a12432c..7776b91da37f 100644 --- a/arch/powerpc/configs/disable-werror.config +++ b/arch/powerpc/configs/disable-werror.config @@ -1 +1,2 @@ +# Help: Disable -Werror CONFIG_PPC_DISABLE_WERROR=y diff --git a/arch/powerpc/configs/security.config b/arch/powerpc/configs/security.config index 1c91a35c6a73..0d54e29e2cdf 100644 --- a/arch/powerpc/configs/security.config +++ b/arch/powerpc/configs/security.config @@ -1,3 +1,5 @@ +# Help: Common security options for PowerPC builds + # This is the equivalent of booting with lockdown=integrity CONFIG_SECURITY=y CONFIG_SECURITYFS=y @@ -12,4 +14,4 @@ CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y #
Re: [PATCH v2 1/2] maple_tree: Disable mas_wr_append() when other readers are possible
On Aug 31 2023, Michael Ellerman wrote: > Andreas Schwab writes: >> This breaks booting on ppc32: > > Does enabling CONFIG_DEBUG_ATOMIC_SLEEP fix the crash? Yes, it does. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: [PATCH RFC 1/2] powerpc/pseries: papr-vpd char driver for VPD retrieval
Michal Suchánek writes:
> On Thu, Aug 31, 2023 at 09:37:12PM +1000, Michael Ellerman wrote:
>> Michal Suchánek writes:
>> > On Thu, Aug 31, 2023 at 03:34:37PM +1000, Michael Ellerman wrote:
>> >> Michal Suchánek writes:
>> >> > On Tue, Aug 22, 2023 at 04:33:39PM -0500, Nathan Lynch via B4 Relay
>> >> > wrote:
>> >> >> From: Nathan Lynch
>> >> >>
>> >> >> PowerVM LPARs may retrieve Vital Product Data (VPD) for system
>> >> >> components using the ibm,get-vpd RTAS function.
>> >> >>
>> >> >> We can expose this to user space with a /dev/papr-vpd character
>> >> >> device, where the programming model is:
>> >> >>
>> >> >> struct papr_location_code plc = { .str = "", }; /* obtain all VPD */
>> >> >> int devfd = open("/dev/papr-vpd", O_WRONLY);
>> >> >> int vpdfd = ioctl(devfd, PAPR_VPD_CREATE_HANDLE, );
>> >> >> size_t size = lseek(vpdfd, 0, SEEK_END);
>> >> >> char *buf = malloc(size);
>> >> >> pread(devfd, buf, size, 0);
>> >> >>
>> >> >> When a file descriptor is obtained from ioctl(PAPR_VPD_CREATE_HANDLE),
>> >> >> the file contains the result of a complete ibm,get-vpd sequence. The
>> >> >
>> >> > Could this be somewhat less obfuscated?
>> >> >
>> >> > What the caller wants is the result of "ibm,get-vpd", which is a
>> >> > well-known string identifier of the rtas call.
>> >>
>> >> Not really. What the caller wants is *the VPD*. Currently that's done
>> >> by calling the RTAS "ibm,get-vpd" function, but that could change in
>> >> future. There's RTAS calls that have been replaced with a "version 2" in
>> >> the past, that could happen here too. Or the RTAS call could be replaced
>> >> by a hypercall (though unlikely).
>> >>
>> >> But hopefully if the underlying mechanism changed the kernel would be
>> >> able to hide that detail behind this new API, and users would not need
>> >> to change at all.
>> >>
>> >> > Yet this identifier is never passed in. Instead we have this new
>> >> > PAPR_VPD_CREATE_HANDLE. This is a completely new identifier, specific to
>> >> > this call only as is the /dev/papr-vpd device name, another new
>> >> > identifier.
>> >> >
>> >> > Maybe the interface could provide a way to specify the service name?
>> >> >
>> >> >> file contents are immutable from the POV of user space. To get a new
>> >> >> view of VPD, clients must create a new handle.
>> >> >
>> >> > Which is basically the same as creating a file descriptor with open().
>> >>
>> >> Sort of. But much cleaner becuase you don't need to create a file in the
>> >> filesystem and tell userspace how to find it.
>> >
>> > You very much do. There is the /dev/papr-vpd and PAPR_VPD_CREATE_HANDLE
>> > which userspace has to know about, the PAPR_VPD_CREATE_HANDLE is not
>> > even possible to find at all.
>>
>> Well yeah you need the device itself :)
>
> And as named it's specific to this call, and new devices will be needed
> for any additional rtas called implemented.
>
>>
>> And yes the ioctl is defined in a header, not in the filesystem, but
>> that's entirely normal for an ioctl based API.
>
> Of course, because the ioctl API has no safe way of passing a string
> identifier for the function. Then it needs to create these obscure IDs.
>
> Other APIs that don't have this problem exist.
Looking at the cover letter for the series, I wonder if my framing and
word choice is confusing? Instead of "new character devices for RTAS
functions", what I would really like to convey is "new character devices
for platform features that are currently only accessible through the
rtas() syscall". But that's too long :-)
You (Michal) seem to favor a kernel-user ABI where user space is allowed
to invoke arbitrary RTAS functions by name. But we already have that in
the form of the rtas() syscall. (User space looks up function tokens by
name in the DT.) The point of the series is that we need to move away
from that. It's too low-level and user space has to use /dev/mem when
invoking any of the less-simple RTAS functions.
Re: Framebuffer mmap on PowerPC
Le 31/08/2023 à 19:38, Christophe Leroy a écrit :
>
>
> Le 31/08/2023 à 16:41, Thomas Zimmermann a écrit :
>> Hi,
>>
>> there's a per-architecture function called fb_pgprotect() that sets
>> VMA's vm_page_prot for mmaped framebuffers. Most architectures use a
>> simple implementation based on pgprot_writecomine() [1] or
>> pgprot_noncached(). [2]
>>
>> On PPC this function uses phys_mem_access_prot() and therefore
>> requires the mmap call's file struct. [3] Removing the file argument
>> would help with simplifying the caller of fb_pgprotect(). [4]
>>
>> Why is the file even required on PPC?
>>
>> Is it possible to replace phys_mem_access_prot() with something
>> simpler that does not use the file struct?
>
> Looks like phys_mem_access_prot() defaults to calling pgprot_noncached()
> see
> https://elixir.bootlin.com/linux/v6.5/source/arch/powerpc/mm/mem.c#L37
> but for a few platforms that's superseeded by
> pci_phys_mem_access_prot(), see
> https://elixir.bootlin.com/linux/v6.5/source/arch/powerpc/kernel/pci-common.c#L524
>
> However, as far as I can see pci_phys_mem_access_prot() doesn't use file
> so you could likely drop that argument on phys_mem_access_prot() on
> powerpc. But when I for instance look at arm, I see that the file
> argument is used, see
> https://elixir.bootlin.com/linux/v6.5/source/arch/arm/mm/mmu.c#L713
>
> So, the simplest is maybe the following, allthough that's probably worth
> a comment:
>
> diff --git a/arch/powerpc/include/asm/fb.h b/arch/powerpc/include/asm/fb.h
> index 5f1a2e5f7654..8b9b856f476e 100644
> --- a/arch/powerpc/include/asm/fb.h
> +++ b/arch/powerpc/include/asm/fb.h
> @@ -6,10 +6,9 @@
>
> #include
>
> -static inline void fb_pgprotect(struct file *file, struct
> vm_area_struct *vma,
> - unsigned long off)
> +static inline void fb_pgprotect(struct vm_area_struct *vma, unsigned
> long off)
> {
> - vma->vm_page_prot = phys_mem_access_prot(file, off >> PAGE_SHIFT,
> + vma->vm_page_prot = phys_mem_access_prot(NULL, off >> PAGE_SHIFT,
> vma->vm_end - vma->vm_start,
> vma->vm_page_prot);
> }
And while at it, maybe also replace off >> PAGE_SHIFT by PHYS_PFN(off)
Christophe
>
>
> Christophe
>
>
>>
>> Best regards
>> Thomas
>>
>>
>> [1]
>> https://elixir.bootlin.com/linux/v6.5/source/include/asm-generic/fb.h#L19
>> [2]
>> https://elixir.bootlin.com/linux/v6.5/source/arch/mips/include/asm/fb.h#L11
>> [3]
>> https://elixir.bootlin.com/linux/v6.5/source/arch/powerpc/include/asm/fb.h#L12
>> [4]
>> https://elixir.bootlin.com/linux/v6.5/source/drivers/video/fbdev/core/fbmem.c#L1299
>>
>>
Re: Framebuffer mmap on PowerPC
Le 31/08/2023 à 16:41, Thomas Zimmermann a écrit :
> Hi,
>
> there's a per-architecture function called fb_pgprotect() that sets
> VMA's vm_page_prot for mmaped framebuffers. Most architectures use a
> simple implementation based on pgprot_writecomine() [1] or
> pgprot_noncached(). [2]
>
> On PPC this function uses phys_mem_access_prot() and therefore requires
> the mmap call's file struct. [3] Removing the file argument would help
> with simplifying the caller of fb_pgprotect(). [4]
>
> Why is the file even required on PPC?
>
> Is it possible to replace phys_mem_access_prot() with something simpler
> that does not use the file struct?
Looks like phys_mem_access_prot() defaults to calling pgprot_noncached()
see
https://elixir.bootlin.com/linux/v6.5/source/arch/powerpc/mm/mem.c#L37
but for a few platforms that's superseeded by
pci_phys_mem_access_prot(), see
https://elixir.bootlin.com/linux/v6.5/source/arch/powerpc/kernel/pci-common.c#L524
However, as far as I can see pci_phys_mem_access_prot() doesn't use file
so you could likely drop that argument on phys_mem_access_prot() on
powerpc. But when I for instance look at arm, I see that the file
argument is used, see
https://elixir.bootlin.com/linux/v6.5/source/arch/arm/mm/mmu.c#L713
So, the simplest is maybe the following, allthough that's probably worth
a comment:
diff --git a/arch/powerpc/include/asm/fb.h b/arch/powerpc/include/asm/fb.h
index 5f1a2e5f7654..8b9b856f476e 100644
--- a/arch/powerpc/include/asm/fb.h
+++ b/arch/powerpc/include/asm/fb.h
@@ -6,10 +6,9 @@
#include
-static inline void fb_pgprotect(struct file *file, struct
vm_area_struct *vma,
- unsigned long off)
+static inline void fb_pgprotect(struct vm_area_struct *vma, unsigned
long off)
{
- vma->vm_page_prot = phys_mem_access_prot(file, off >> PAGE_SHIFT,
+ vma->vm_page_prot = phys_mem_access_prot(NULL, off >> PAGE_SHIFT,
vma->vm_end - vma->vm_start,
vma->vm_page_prot);
}
Christophe
>
> Best regards
> Thomas
>
>
> [1]
> https://elixir.bootlin.com/linux/v6.5/source/include/asm-generic/fb.h#L19
> [2]
> https://elixir.bootlin.com/linux/v6.5/source/arch/mips/include/asm/fb.h#L11
> [3]
> https://elixir.bootlin.com/linux/v6.5/source/arch/powerpc/include/asm/fb.h#L12
> [4]
> https://elixir.bootlin.com/linux/v6.5/source/drivers/video/fbdev/core/fbmem.c#L1299
>
>
[PATCH v10 13/15] PCI/AER: Forward RCH downstream port-detected errors to the CXL.mem dev handler
From: Robert Richter
In Restricted CXL Device (RCD) mode a CXL device is exposed as an
RCiEP, but CXL downstream and upstream ports are not enumerated and
not visible in the PCIe hierarchy. [1] Protocol and link errors from
these non-enumerated ports are signaled as internal AER errors, either
Uncorrectable Internal Error (UIE) or Corrected Internal Errors (CIE)
via an RCEC.
Restricted CXL host (RCH) downstream port-detected errors have the
Requester ID of the RCEC set in the RCEC's AER Error Source ID
register. A CXL handler must then inspect the error status in various
CXL registers residing in the dport's component register space (CXL
RAS capability) or the dport's RCRB (PCIe AER extended
capability). [2]
Errors showing up in the RCEC's error handler must be handled and
connected to the CXL subsystem. Implement this by forwarding the error
to all CXL devices below the RCEC. Since the entire CXL device is
controlled only using PCIe Configuration Space of device 0, function
0, only pass it there [3]. The error handling is limited to currently
supported devices with the Memory Device class code set (CXL Type 3
Device, PCI_CLASS_MEMORY_CXL, 502h), handle downstream port errors in
the device's cxl_pci driver. Support for other CXL Device Types
(e.g. a CXL.cache Device) can be added later.
To handle downstream port errors in addition to errors directed to the
CXL endpoint device, a handler must also inspect the CXL RAS and PCIe
AER capabilities of the CXL downstream port the device is connected
to.
Since CXL downstream port errors are signaled using internal errors,
the handler requires those errors to be unmasked. This is subject of a
follow-on patch.
The reason for choosing this implementation is that the AER service
driver claims the RCEC device, but does not allow it to register a
custom specific handler to support CXL. Connecting the RCEC hard-wired
with a CXL handler does not work, as the CXL subsystem might not be
present all the time. The alternative to add an implementation to the
portdrv to allow the registration of a custom RCEC error handler isn't
worth doing it as CXL would be its only user. Instead, just check for
an CXL RCEC and pass it down to the connected CXL device's error
handler. With this approach the code can entirely be implemented in
the PCIe AER driver and is independent of the CXL subsystem. The CXL
driver only provides the handler.
[1] CXL 3.0 spec: 9.11.8 CXL Devices Attached to an RCH
[2] CXL 3.0 spec, 12.2.1.1 RCH Downstream Port-detected Errors
[3] CXL 3.0 spec, 8.1.3 PCIe DVSEC for CXL Devices
Co-developed-by: Terry Bowman
Signed-off-by: Terry Bowman
Signed-off-by: Robert Richter
Cc: "Oliver O'Halloran"
Cc: Bjorn Helgaas
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Acked-by: Bjorn Helgaas
Reviewed-by: Jonathan Cameron
Reviewed-by: Dave Jiang
---
drivers/pci/pcie/Kconfig | 12 +
drivers/pci/pcie/aer.c | 96 +++-
2 files changed, 106 insertions(+), 2 deletions(-)
diff --git a/drivers/pci/pcie/Kconfig b/drivers/pci/pcie/Kconfig
index 228652a59f27..4f0e70fafe2d 100644
--- a/drivers/pci/pcie/Kconfig
+++ b/drivers/pci/pcie/Kconfig
@@ -49,6 +49,18 @@ config PCIEAER_INJECT
gotten from:
https://git.kernel.org/cgit/linux/kernel/git/gong.chen/aer-inject.git/
+config PCIEAER_CXL
+ bool "PCI Express CXL RAS support for Restricted Hosts (RCH)"
+ default y
+ depends on PCIEAER && CXL_PCI
+ help
+ Enables error handling of downstream ports of a CXL host
+ that is operating in RCD mode (Restricted CXL Host, RCH).
+ The downstream port reports AER errors to a given RCEC.
+ Errors are handled by the CXL memory device driver.
+
+ If unsure, say Y.
+
#
# PCI Express ECRC
#
diff --git a/drivers/pci/pcie/aer.c b/drivers/pci/pcie/aer.c
index d3344fcf1f79..c354ca5e8f2b 100644
--- a/drivers/pci/pcie/aer.c
+++ b/drivers/pci/pcie/aer.c
@@ -946,14 +946,100 @@ static bool find_source_device(struct pci_dev *parent,
return true;
}
+#ifdef CONFIG_PCIEAER_CXL
+
+static bool is_cxl_mem_dev(struct pci_dev *dev)
+{
+ /*
+* The capability, status, and control fields in Device 0,
+* Function 0 DVSEC control the CXL functionality of the
+* entire device (CXL 3.0, 8.1.3).
+*/
+ if (dev->devfn != PCI_DEVFN(0, 0))
+ return false;
+
+ /*
+* CXL Memory Devices must have the 502h class code set (CXL
+* 3.0, 8.1.12.1).
+*/
+ if ((dev->class >> 8) != PCI_CLASS_MEMORY_CXL)
+ return false;
+
+ return true;
+}
+
+static bool cxl_error_is_native(struct pci_dev *dev)
+{
+ struct pci_host_bridge *host = pci_find_host_bridge(dev->bus);
+
+ if (pcie_ports_native)
+ return true;
+
+ return host->native_aer && host->native_cxl_error;
+}
+
+static bool is_internal_error(struct aer_err_info *info)
+{
+ if
Re: [PATCH RFC 1/2] powerpc/pseries: papr-vpd char driver for VPD retrieval
Michal Suchánek writes:
>
> thanks for working on this.
Thanks for reviewing!
> On Tue, Aug 22, 2023 at 04:33:39PM -0500, Nathan Lynch via B4 Relay wrote:
>> From: Nathan Lynch
>>
>> PowerVM LPARs may retrieve Vital Product Data (VPD) for system
>> components using the ibm,get-vpd RTAS function.
>>
>> We can expose this to user space with a /dev/papr-vpd character
>> device, where the programming model is:
>>
>> struct papr_location_code plc = { .str = "", }; /* obtain all VPD */
>> int devfd = open("/dev/papr-vpd", O_WRONLY);
>> int vpdfd = ioctl(devfd, PAPR_VPD_CREATE_HANDLE, );
>> size_t size = lseek(vpdfd, 0, SEEK_END);
>> char *buf = malloc(size);
>> pread(devfd, buf, size, 0);
>>
>> When a file descriptor is obtained from ioctl(PAPR_VPD_CREATE_HANDLE),
>> the file contains the result of a complete ibm,get-vpd sequence. The
>
> Could this be somewhat less obfuscated?
>
> What the caller wants is the result of "ibm,get-vpd", which is a
> well-known string identifier of the rtas call.
>
> Yet this identifier is never passed in. Instead we have this new
> PAPR_VPD_CREATE_HANDLE. This is a completely new identifier, specific to
> this call only as is the /dev/papr-vpd device name, another new
> identifier.
>
> Maybe the interface could provide a way to specify the service name?
>
>> file contents are immutable from the POV of user space. To get a new
>> view of VPD, clients must create a new handle.
>
> Which is basically the same as creating a file descriptor with open().
>
> Maybe creating a directory in sysfs or procfs with filenames
> corresponding to rtas services would do the same job without extra
> obfuscation?
Michael has already said most of what I would have on these points. I'll
add that my experience with user space software that interacts closely
with RTAS leads me to believe that the kernel can and should expose
these platform features in higher-level ways that address fundamental
needs while encapsulating complexities such as caller serialization and
the mechanism (RTAS vs hcall vs DT). In this case, the fact that the
ibm,get-vpd RTAS function is the PAPR-specified interface for the OS to
retrieve VPD is much less essential to vpdupdate/libvpd than the format
of the VPD returned.
>> * The only way to discover the size of a VPD buffer is
>> lseek(SEEK_END). fstat() doesn't work for anonymous fds like
>> this. Is this OK, or should the buffer length be discoverable some
>> other way?
>
> So long as users have /rtas/ibm,vpd-size as the top bound of the data
> they can receive I don't think it's critical to know the current VPD
> size.
OK, well I want to be transparent that the spec language says it's the
"estimated" max size, so I would hesitate to use it to size buffers
without some fallback for when it's wrong.
Re: [PATCH v2 0/2] kbuild: Show Kconfig fragments in "help"
On Thu, Aug 31, 2023 at 9:03 AM Kees Cook wrote: > > On Tue, Aug 29, 2023 at 11:57:19PM +0900, Masahiro Yamada wrote: > > The attached patch will work too. > > > > I dropped the "in the first line" restriction > > because SPDX might be placed in the first line > > of config fragments. > > Good call. Yes, this looks excellent; thank you! Do you want to send a > formal patch? Please consider it: > > Reviewed-by: Kees Cook > > -- > Kees Cook You can send it with Co-developed-by: Masahiro Yamada You can add help messages to more *.config files if you like, and add SPDX tags while you are here. -- Best Regards Masahiro Yamada
Re: [PATCH] macintosh: Explicitly include correct DT includes
On 8/31/23 07:04, Guenter Roeck wrote: > On Fri, Jul 14, 2023 at 11:46:54AM -0600, Rob Herring wrote: >> The DT of_device.h and of_platform.h date back to the separate >> of_platform_bus_type before it as merged into the regular platform bus. >> As part of that merge prepping Arm DT support 13 years ago, they >> "temporarily" include each other. They also include platform_device.h >> and of.h. As a result, there's a pretty much random mix of those include >> files used throughout the tree. In order to detangle these headers and >> replace the implicit includes with struct declarations, users need to >> explicitly include the correct includes. >> >> Signed-off-by: Rob Herring > > This patch results in the following build error. > > Building powerpc:ppc32_allmodconfig ... failed > -- > Error log: > drivers/macintosh/ams/ams-input.c: In function 'ams_input_enable': > drivers/macintosh/ams/ams-input.c:68:45: error: invalid use of undefined type > 'struct platform_device' >68 | input->dev.parent = _info.of_dev->dev; > | ^~ > drivers/macintosh/ams/ams-input.c: In function 'ams_input_init': > drivers/macintosh/ams/ams-input.c:146:51: error: invalid use of undefined > type 'struct platform_device' > 146 | return device_create_file(_info.of_dev->dev, > _attr_joystick); > | ^~ > drivers/macintosh/ams/ams-input.c: In function 'ams_input_exit': > drivers/macintosh/ams/ams-input.c:151:44: error: invalid use of undefined > type 'struct platform_device' > 151 | device_remove_file(_info.of_dev->dev, _attr_joystick); > |^~ > drivers/macintosh/ams/ams-input.c: In function 'ams_input_init': > drivers/macintosh/ams/ams-input.c:147:1: error: control reaches end of > non-void function > > Bisect log attached. Hi Guenter, I posted a patch for this 2 days ago and Michael Ellerman just did a pull request to Linus with the fix. -- ~Randy
Re: [PATCH] macintosh: Explicitly include correct DT includes
On Fri, Jul 14, 2023 at 11:46:54AM -0600, Rob Herring wrote: > The DT of_device.h and of_platform.h date back to the separate > of_platform_bus_type before it as merged into the regular platform bus. > As part of that merge prepping Arm DT support 13 years ago, they > "temporarily" include each other. They also include platform_device.h > and of.h. As a result, there's a pretty much random mix of those include > files used throughout the tree. In order to detangle these headers and > replace the implicit includes with struct declarations, users need to > explicitly include the correct includes. > > Signed-off-by: Rob Herring This patch results in the following build error. Building powerpc:ppc32_allmodconfig ... failed -- Error log: drivers/macintosh/ams/ams-input.c: In function 'ams_input_enable': drivers/macintosh/ams/ams-input.c:68:45: error: invalid use of undefined type 'struct platform_device' 68 | input->dev.parent = _info.of_dev->dev; | ^~ drivers/macintosh/ams/ams-input.c: In function 'ams_input_init': drivers/macintosh/ams/ams-input.c:146:51: error: invalid use of undefined type 'struct platform_device' 146 | return device_create_file(_info.of_dev->dev, _attr_joystick); | ^~ drivers/macintosh/ams/ams-input.c: In function 'ams_input_exit': drivers/macintosh/ams/ams-input.c:151:44: error: invalid use of undefined type 'struct platform_device' 151 | device_remove_file(_info.of_dev->dev, _attr_joystick); |^~ drivers/macintosh/ams/ams-input.c: In function 'ams_input_init': drivers/macintosh/ams/ams-input.c:147:1: error: control reaches end of non-void function Bisect log attached. Guenter --- # bad: [b97d64c722598ffed42ece814a2cb791336c6679] Merge tag '6.6-rc-smb3-client-fixes-part1' of git://git.samba.org/sfrench/cifs-2.6 # good: [1c59d383390f970b891b503b7f79b63a02db2ec5] Merge tag 'linux-kselftest-nolibc-6.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest git bisect start 'HEAD' '1c59d383390f' # good: [53ea7f624fb91074c2f9458832ed74975ee5d64c] Merge tag 'xfs-6.6-merge-1' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux git bisect good 53ea7f624fb91074c2f9458832ed74975ee5d64c # good: [4fb0dacb78c6a041bbd38ddd998df806af5c2c69] Merge tag 'sound-6.6-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound git bisect good 4fb0dacb78c6a041bbd38ddd998df806af5c2c69 # good: [05c618f39089d977b0c3dc1105cb6cd5fc53cd01] arm64: dts: use capital "OR" for multiple licenses in SPDX git bisect good 05c618f39089d977b0c3dc1105cb6cd5fc53cd01 # bad: [4a3b1007eeb26b2bb7ae4d734cc8577463325165] Merge tag 'pinctrl-v6.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl git bisect bad 4a3b1007eeb26b2bb7ae4d734cc8577463325165 # good: [47ca50600efcf994adb62a9a4e75c77d91bd0781] Merge tag 'soc-defconfig-6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc git bisect good 47ca50600efcf994adb62a9a4e75c77d91bd0781 # good: [8f447694c23a432b2e9cfe67fb2651f8f6655bfd] Merge tag 'devicetree-for-6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux git bisect good 8f447694c23a432b2e9cfe67fb2651f8f6655bfd # good: [cd40a1ffddc963e69884a713d8704edd98035861] Merge tag 'qcom-pinctrl-6.6' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-dt into devel git bisect good cd40a1ffddc963e69884a713d8704edd98035861 # good: [82a65f0844852cec6a70ac05c7d8edb0586c851c] Merge tag 'intel-pinctrl-v6.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pinctrl/intel into devel git bisect good 82a65f0844852cec6a70ac05c7d8edb0586c851c # bad: [ef2a0b7cdbc5b84f7b3f6573b7687e72bede0964] Merge tag 'devicetree-header-cleanups-for-6.6' of git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux git bisect bad ef2a0b7cdbc5b84f7b3f6573b7687e72bede0964 # bad: [233d687d1b78080ee79f67356327e0e0e50ef6f5] macintosh: Explicitly include correct DT includes git bisect bad 233d687d1b78080ee79f67356327e0e0e50ef6f5 # good: [6303d0693f7d6c44bb6eb0b29c906ee28156dd28] clocksource: Explicitly include correct DT includes git bisect good 6303d0693f7d6c44bb6eb0b29c906ee28156dd28 # good: [32bc7297d855608fcb13af62a95739a079b4f8e2] hte: Explicitly include correct DT includes git bisect good 32bc7297d855608fcb13af62a95739a079b4f8e2 # first bad commit: [233d687d1b78080ee79f67356327e0e0e50ef6f5] macintosh: Explicitly include correct DT includes
[GIT PULL] Please pull powerpc/linux.git powerpc-6.6-1 tag
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Linus, Please pull powerpc updates for 6.6. There's a conflict in drivers/net/ethernet/freescale/fs_enet/fs_enet.h, where the correct resolution is to drop the include of both linux/fs_enet_pd.h and asm/fs_pd.h. There's a trivial conflict in arch/powerpc/Kconfig. There will be a conflict when you merge the tty tree, in arch/powerpc/include/asm/fs_pd.h, the resolution is just to take the union of all the removals leaving the file almost empty and unused, we will remove it in a follow-up patch. Notable out of area changes: include/linux/hw_breakpoint.h # 53834a0c0925 perf/hw_breakpoint: Remove arch breakpoint hooks kernel/events/hw_breakpoint.c # 53834a0c0925 perf/hw_breakpoint: Remove arch breakpoint hooks drivers/net/ethernet/freescale/fs_enet/fs_enet.h # 60bc069c433f powerpc/include: Remove unneeded #include drivers/net/ethernet/freescale/fs_enet/mac-fcc.c # fecc436a97af powerpc/include: Remove mpc8260.h and m82xx_pci.h cheers The following changes since commit 6eaae198076080886b9e7d57f4ae06fa782f90ef: Linux 6.5-rc3 (2023-07-23 15:24:10 -0700) are available in the git repository at: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-6.6-1 for you to fetch changes up to 85a616416e9e01db0bfa92f26457e92642e2236b: macintosh/ams: linux/platform_device.h is needed (2023-08-31 21:23:13 +1000) - -- powerpc updates for 6.6 - Add HOTPLUG_SMT support (/sys/devices/system/cpu/smt) and honour the configured SMT state when hotplugging CPUs into the system. - Combine final TLB flush and lazy TLB mm shootdown IPIs when using the Radix MMU to avoid a broadcast TLBIE flush on exit. - Drop the exclusion between ptrace/perf watchpoints, and drop the now unused associated arch hooks. - Add support for the "nohlt" command line option to disable CPU idle. - Add support for -fpatchable-function-entry for ftrace, with GCC >= 13.1. - Rework memory block size determination, and support 256MB size on systems with GPUs that have hotpluggable memory. - Various other small features and fixes. Thanks to: Andrew Donnellan, Aneesh Kumar K.V, Arnd Bergmann, Athira Rajeev, Benjamin Gray, Christophe Leroy, Frederic Barrat, Gautam Menghani, Geoff Levand, Hari Bathini, Immad Mir, Jialin Zhang, Joel Stanley, Jordan Niethe, Justin Stitt, Kajol Jain, Kees Cook, Krzysztof Kozlowski, Laurent Dufour, Liang He, Linus Walleij, Mahesh Salgaonkar, Masahiro Yamada, Michal Suchanek, Nageswara R Sastry, Nathan Chancellor, Nathan Lynch, Naveen N Rao, Nicholas Piggin, Nick Desaulniers, Omar Sandoval, Randy Dunlap, Reza Arbab, Rob Herring, Russell Currey, Sourabh Jain, Thomas Gleixner, Trevor Woerner, Uwe Kleine-König, Vaibhav Jain, Xiongfeng Wang, Yuan Tan, Zhang Rui, Zheng Zengkai. - -- Aneesh Kumar K.V (3): powerpc/mm: Cleanup memory block size probing powerpc/mm/book3s64: Fix build error with SPARSEMEM disabled powerpc/mm/book3s64: Use 256M as the upper limit with coherent device memory attached Arnd Bergmann (4): powerpc: address missing-prototypes warnings powerpc: mark more local variables as volatile powerpc: xmon: remove unused variables macintosh/ams: mark ams_init() static Benjamin Gray (11): selftests/powerpc/ptrace: Explain why tests are skipped selftests/powerpc/ptrace: Fix typo in pid_max search error selftests/powerpc/ptrace: Declare test temporary variables as volatile powerpc/watchpoints: Explain thread_change_pc() more powerpc/watchpoints: Don't track info persistently powerpc/watchpoints: Track perf single step directly on the breakpoint powerpc/watchpoints: Simplify watchpoint reinsertion powerpc/watchpoints: Remove ptrace/perf exclusion tracking selftests/powerpc/ptrace: Update ptrace-perf watchpoint selftest perf/hw_breakpoint: Remove arch breakpoint hooks Documentation/powerpc: Fix ptrace request names Christophe Leroy (35): powerpc/kuap: Avoid unnecessary reads of MD_AP powerpc/kuap: Avoid useless jump_label on empty function powerpc/kuap: Fold kuep_is_disabled() into its only user powerpc/features: Add capability to update mmu features later powerpc/kuap: MMU_FTR_BOOK3S_KUAP becomes MMU_FTR_KUAP powerpc/kuap: Use MMU_FTR_KUAP on all and refactor disabling kuap powerpc/kuap: Simplify KUAP lock/unlock on BOOK3S/32 powerpc/kuap: KUAP enabling/disabling functions must be __always_inline powerpc/kuap: Use ASM feature fixups instead of static branches powerpc/radix: Move some functions into #ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE powerpc/include: Remove unneeded #include powerpc/include: Declare mpc8xx_immr in 8xx_immap.h powerpc/include: Remove mpc8260.h and m82xx_pci.h
Re: [PATCH] macintosh/ams: linux/platform_device.h is needed
On Tue, 29 Aug 2023 15:58:37 -0700, Randy Dunlap wrote: > ams.h uses struct platform_device, so the header should be used > to prevent build errors: > > drivers/macintosh/ams/ams-input.c: In function 'ams_input_enable': > drivers/macintosh/ams/ams-input.c:68:45: error: invalid use of undefined type > 'struct platform_device' >68 | input->dev.parent = _info.of_dev->dev; > drivers/macintosh/ams/ams-input.c: In function 'ams_input_init': > drivers/macintosh/ams/ams-input.c:146:51: error: invalid use of undefined > type 'struct platform_device' > 146 | return device_create_file(_info.of_dev->dev, > _attr_joystick); > drivers/macintosh/ams/ams-input.c: In function 'ams_input_exit': > drivers/macintosh/ams/ams-input.c:151:44: error: invalid use of undefined > type 'struct platform_device' > 151 | device_remove_file(_info.of_dev->dev, _attr_joystick); > drivers/macintosh/ams/ams-input.c: In function 'ams_input_init': > drivers/macintosh/ams/ams-input.c:147:1: error: control reaches end of > non-void function [-Werror=return-type] > 147 | } > > [...] Applied to powerpc/next. [1/1] macintosh/ams: linux/platform_device.h is needed https://git.kernel.org/powerpc/c/85a616416e9e01db0bfa92f26457e92642e2236b cheers
Re: [PATCH RFC 1/2] powerpc/pseries: papr-vpd char driver for VPD retrieval
On Thu, Aug 31, 2023 at 09:37:12PM +1000, Michael Ellerman wrote:
> Michal Suchánek writes:
> > On Thu, Aug 31, 2023 at 03:34:37PM +1000, Michael Ellerman wrote:
> >> Michal Suchánek writes:
> >> > On Tue, Aug 22, 2023 at 04:33:39PM -0500, Nathan Lynch via B4 Relay
> >> > wrote:
> >> >> From: Nathan Lynch
> >> >>
> >> >> PowerVM LPARs may retrieve Vital Product Data (VPD) for system
> >> >> components using the ibm,get-vpd RTAS function.
> >> >>
> >> >> We can expose this to user space with a /dev/papr-vpd character
> >> >> device, where the programming model is:
> >> >>
> >> >> struct papr_location_code plc = { .str = "", }; /* obtain all VPD */
> >> >> int devfd = open("/dev/papr-vpd", O_WRONLY);
> >> >> int vpdfd = ioctl(devfd, PAPR_VPD_CREATE_HANDLE, );
> >> >> size_t size = lseek(vpdfd, 0, SEEK_END);
> >> >> char *buf = malloc(size);
> >> >> pread(devfd, buf, size, 0);
> >> >>
> >> >> When a file descriptor is obtained from ioctl(PAPR_VPD_CREATE_HANDLE),
> >> >> the file contains the result of a complete ibm,get-vpd sequence. The
> >> >
> >> > Could this be somewhat less obfuscated?
> >> >
> >> > What the caller wants is the result of "ibm,get-vpd", which is a
> >> > well-known string identifier of the rtas call.
> >>
> >> Not really. What the caller wants is *the VPD*. Currently that's done
> >> by calling the RTAS "ibm,get-vpd" function, but that could change in
> >> future. There's RTAS calls that have been replaced with a "version 2" in
> >> the past, that could happen here too. Or the RTAS call could be replaced
> >> by a hypercall (though unlikely).
> >>
> >> But hopefully if the underlying mechanism changed the kernel would be
> >> able to hide that detail behind this new API, and users would not need
> >> to change at all.
> >>
> >> > Yet this identifier is never passed in. Instead we have this new
> >> > PAPR_VPD_CREATE_HANDLE. This is a completely new identifier, specific to
> >> > this call only as is the /dev/papr-vpd device name, another new
> >> > identifier.
> >> >
> >> > Maybe the interface could provide a way to specify the service name?
> >> >
> >> >> file contents are immutable from the POV of user space. To get a new
> >> >> view of VPD, clients must create a new handle.
> >> >
> >> > Which is basically the same as creating a file descriptor with open().
> >>
> >> Sort of. But much cleaner becuase you don't need to create a file in the
> >> filesystem and tell userspace how to find it.
> >
> > You very much do. There is the /dev/papr-vpd and PAPR_VPD_CREATE_HANDLE
> > which userspace has to know about, the PAPR_VPD_CREATE_HANDLE is not
> > even possible to find at all.
>
> Well yeah you need the device itself :)
And as named it's specific to this call, and new devices will be needed
for any additional rtas called implemented.
>
> And yes the ioctl is defined in a header, not in the filesystem, but
> that's entirely normal for an ioctl based API.
Of course, because the ioctl API has no safe way of passing a string
identifier for the function. Then it needs to create these obscure IDs.
Other APIs that don't have this problem exist.
Thanks
Michal
Re: [PATCH RFC 1/2] powerpc/pseries: papr-vpd char driver for VPD retrieval
Michal Suchánek writes:
> On Thu, Aug 31, 2023 at 03:34:37PM +1000, Michael Ellerman wrote:
>> Michal Suchánek writes:
>> > On Tue, Aug 22, 2023 at 04:33:39PM -0500, Nathan Lynch via B4 Relay wrote:
>> >> From: Nathan Lynch
>> >>
>> >> PowerVM LPARs may retrieve Vital Product Data (VPD) for system
>> >> components using the ibm,get-vpd RTAS function.
>> >>
>> >> We can expose this to user space with a /dev/papr-vpd character
>> >> device, where the programming model is:
>> >>
>> >> struct papr_location_code plc = { .str = "", }; /* obtain all VPD */
>> >> int devfd = open("/dev/papr-vpd", O_WRONLY);
>> >> int vpdfd = ioctl(devfd, PAPR_VPD_CREATE_HANDLE, );
>> >> size_t size = lseek(vpdfd, 0, SEEK_END);
>> >> char *buf = malloc(size);
>> >> pread(devfd, buf, size, 0);
>> >>
>> >> When a file descriptor is obtained from ioctl(PAPR_VPD_CREATE_HANDLE),
>> >> the file contains the result of a complete ibm,get-vpd sequence. The
>> >
>> > Could this be somewhat less obfuscated?
>> >
>> > What the caller wants is the result of "ibm,get-vpd", which is a
>> > well-known string identifier of the rtas call.
>>
>> Not really. What the caller wants is *the VPD*. Currently that's done
>> by calling the RTAS "ibm,get-vpd" function, but that could change in
>> future. There's RTAS calls that have been replaced with a "version 2" in
>> the past, that could happen here too. Or the RTAS call could be replaced
>> by a hypercall (though unlikely).
>>
>> But hopefully if the underlying mechanism changed the kernel would be
>> able to hide that detail behind this new API, and users would not need
>> to change at all.
>>
>> > Yet this identifier is never passed in. Instead we have this new
>> > PAPR_VPD_CREATE_HANDLE. This is a completely new identifier, specific to
>> > this call only as is the /dev/papr-vpd device name, another new
>> > identifier.
>> >
>> > Maybe the interface could provide a way to specify the service name?
>> >
>> >> file contents are immutable from the POV of user space. To get a new
>> >> view of VPD, clients must create a new handle.
>> >
>> > Which is basically the same as creating a file descriptor with open().
>>
>> Sort of. But much cleaner becuase you don't need to create a file in the
>> filesystem and tell userspace how to find it.
>
> You very much do. There is the /dev/papr-vpd and PAPR_VPD_CREATE_HANDLE
> which userspace has to know about, the PAPR_VPD_CREATE_HANDLE is not
> even possible to find at all.
Well yeah you need the device itself :)
And yes the ioctl is defined in a header, not in the filesystem, but
that's entirely normal for an ioctl based API.
cheers
Re: [PATCH RFC 1/2] powerpc/pseries: papr-vpd char driver for VPD retrieval
On Thu, Aug 31, 2023 at 03:34:37PM +1000, Michael Ellerman wrote:
> Michal Suchánek writes:
> > Hello,
> >
> > thanks for working on this.
> >
> > On Tue, Aug 22, 2023 at 04:33:39PM -0500, Nathan Lynch via B4 Relay wrote:
> >> From: Nathan Lynch
> >>
> >> PowerVM LPARs may retrieve Vital Product Data (VPD) for system
> >> components using the ibm,get-vpd RTAS function.
> >>
> >> We can expose this to user space with a /dev/papr-vpd character
> >> device, where the programming model is:
> >>
> >> struct papr_location_code plc = { .str = "", }; /* obtain all VPD */
> >> int devfd = open("/dev/papr-vpd", O_WRONLY);
> >> int vpdfd = ioctl(devfd, PAPR_VPD_CREATE_HANDLE, );
> >> size_t size = lseek(vpdfd, 0, SEEK_END);
> >> char *buf = malloc(size);
> >> pread(devfd, buf, size, 0);
> >>
> >> When a file descriptor is obtained from ioctl(PAPR_VPD_CREATE_HANDLE),
> >> the file contains the result of a complete ibm,get-vpd sequence. The
> >
> > Could this be somewhat less obfuscated?
> >
> > What the caller wants is the result of "ibm,get-vpd", which is a
> > well-known string identifier of the rtas call.
>
> Not really. What the caller wants is *the VPD*. Currently that's done
> by calling the RTAS "ibm,get-vpd" function, but that could change in
> future. There's RTAS calls that have been replaced with a "version 2" in
> the past, that could happen here too. Or the RTAS call could be replaced
> by a hypercall (though unlikely).
>
> But hopefully if the underlying mechanism changed the kernel would be
> able to hide that detail behind this new API, and users would not need
> to change at all.
Still the kernel could use the name that is well-known today even if it
uses different implementation internally in the future.
>
> > Yet this identifier is never passed in. Instead we have this new
> > PAPR_VPD_CREATE_HANDLE. This is a completely new identifier, specific to
> > this call only as is the /dev/papr-vpd device name, another new
> > identifier.
> >
> > Maybe the interface could provide a way to specify the service name?
> >
> >> file contents are immutable from the POV of user space. To get a new
> >> view of VPD, clients must create a new handle.
> >
> > Which is basically the same as creating a file descriptor with open().
>
> Sort of. But much cleaner becuase you don't need to create a file in the
> filesystem and tell userspace how to find it.
>
> This pattern of creating file descriptors from existing file descriptors
> to model a hiearachy of objects is well established in eg. the KVM and
> DRM APIs.
>
> >> The memory required for the VPD buffers seems acceptable, around 20KB
> >> for all VPD on one of my systems. And the value of the
> >> /rtas/ibm,vpd-size DT property (the estimated maximum size of VPD) is
> >> consistently 300KB across various systems I've checked.
> >>
> >> I've implemented support for this new ABI in the rtas_get_vpd()
> >> function in librtas, which the vpdupdate command currently uses to
> >> populate its VPD database. I've verified that an unmodified vpdupdate
> >> binary generates an identical database when using a librtas.so that
> >> prefers the new ABI.
> >>
> >> Likely remaining work:
> >>
> >> * Handle RTAS call status -4 (VPD changed) during ibm,get-vpd call
> >> sequence.
> >> * Prevent ibm,get-vpd calls via rtas(2) from disrupting ibm,get-vpd
> >> call sequences in this driver.
> >> * (Maybe) implement a poll method for delivering notifications of
> >> potential changes to VPD, e.g. after a partition migration.
> >
> > That sounds like something for netlink. If that is desired maybe it
> > should be used in the first place?
>
> I don't see why that is related to netlink. It's entirely normal for
> file descriptor based APIs to implement poll.
>
> netlink adds a lot of complexity for zero gain IMO.
It kind of solves the problem with shoehorning something that's not
really a file into file descriptors. You don't have to when not using
them. It also solves how to access multiple services without creating a
large number of files and large number of obscure constants.
Thanks
Michal
Re: [PATCH RFC 1/2] powerpc/pseries: papr-vpd char driver for VPD retrieval
On Thu, Aug 31, 2023 at 03:34:37PM +1000, Michael Ellerman wrote:
> Michal Suchánek writes:
> > Hello,
> >
> > thanks for working on this.
> >
> > On Tue, Aug 22, 2023 at 04:33:39PM -0500, Nathan Lynch via B4 Relay wrote:
> >> From: Nathan Lynch
> >>
> >> PowerVM LPARs may retrieve Vital Product Data (VPD) for system
> >> components using the ibm,get-vpd RTAS function.
> >>
> >> We can expose this to user space with a /dev/papr-vpd character
> >> device, where the programming model is:
> >>
> >> struct papr_location_code plc = { .str = "", }; /* obtain all VPD */
> >> int devfd = open("/dev/papr-vpd", O_WRONLY);
> >> int vpdfd = ioctl(devfd, PAPR_VPD_CREATE_HANDLE, );
> >> size_t size = lseek(vpdfd, 0, SEEK_END);
> >> char *buf = malloc(size);
> >> pread(devfd, buf, size, 0);
> >>
> >> When a file descriptor is obtained from ioctl(PAPR_VPD_CREATE_HANDLE),
> >> the file contains the result of a complete ibm,get-vpd sequence. The
> >
> > Could this be somewhat less obfuscated?
> >
> > What the caller wants is the result of "ibm,get-vpd", which is a
> > well-known string identifier of the rtas call.
>
> Not really. What the caller wants is *the VPD*. Currently that's done
> by calling the RTAS "ibm,get-vpd" function, but that could change in
> future. There's RTAS calls that have been replaced with a "version 2" in
> the past, that could happen here too. Or the RTAS call could be replaced
> by a hypercall (though unlikely).
>
> But hopefully if the underlying mechanism changed the kernel would be
> able to hide that detail behind this new API, and users would not need
> to change at all.
>
> > Yet this identifier is never passed in. Instead we have this new
> > PAPR_VPD_CREATE_HANDLE. This is a completely new identifier, specific to
> > this call only as is the /dev/papr-vpd device name, another new
> > identifier.
> >
> > Maybe the interface could provide a way to specify the service name?
> >
> >> file contents are immutable from the POV of user space. To get a new
> >> view of VPD, clients must create a new handle.
> >
> > Which is basically the same as creating a file descriptor with open().
>
> Sort of. But much cleaner becuase you don't need to create a file in the
> filesystem and tell userspace how to find it.
You very much do. There is the /dev/papr-vpd and PAPR_VPD_CREATE_HANDLE
which userspace has to know about, the PAPR_VPD_CREATE_HANDLE is not
even possible to find at all.
Thanks
Michal
