Re: [PATCH v5] memblock: make memblock_find_in_range method private
On 8/16/21 5:26 AM, Mike Rapoport wrote:
From: Mike Rapoport
There are a lot of uses of memblock_find_in_range() along with
memblock_reserve() from the times memblock allocation APIs did not exist.
memblock_find_in_range() is the very core of memblock allocations, so any
future changes to its internal behaviour would mandate updates of all the
users outside memblock.
Replace the calls to memblock_find_in_range() with an equivalent calls to
memblock_phys_alloc() and memblock_phys_alloc_range() and make
memblock_find_in_range() private method of memblock.
This simplifies the callers, ensures that (unlikely) errors in
memblock_reserve() are handled and improves maintainability of
memblock_find_in_range().
Signed-off-by: Mike Rapoport
Acked-by: Kirill A. Shutemov
Acked-by: Rafael J. Wysocki # ACPI
Acked-by: Russell King (Oracle)
Acked-by: Nick Kossifidis # riscv
Reviewed-by: Catalin Marinas # arm64
This version passes all my x86/x86_64 boot tests.
Tested-by: Guenter Roeck
Guenter
---
v5:
* restore the original behaviour on x86 with addition of more elaborate
comment; I will address the issue in memory_map_top_down() in a separate
series.
v4: https://lore.kernel.org/lkml/20210812065907.20046-1-r...@kernel.org
* Add patch that prevents the crashes reported by Guenter Roeck on x86/i386
on QEMU with 256M or 512M of memory and EFI boot enabled.
* Add Acked-by and Reviewed-by, thanks everybidy!
v3: https://lore.kernel.org/lkml/20210803064218.6611-1-r...@kernel.org
* simplify check for exact crash kerenl allocation on arm, per Rob
* make crash_max unsigned long long on arm64, per Rob
v2: https://lore.kernel.org/lkml/20210802063737.22733-1-r...@kernel.org
* don't change error message in arm::reserve_crashkernel(), per Russell
v1: https://lore.kernel.org/lkml/20210730104039.7047-1-r...@kernel.org
arch/arm/kernel/setup.c | 20 +-
arch/arm64/kvm/hyp/reserved_mem.c | 9 +++
arch/arm64/mm/init.c | 36 -
arch/mips/kernel/setup.c | 14 +-
arch/riscv/mm/init.c | 44 ++-
arch/s390/kernel/setup.c | 10 ---
arch/x86/kernel/aperture_64.c | 5 ++--
arch/x86/mm/init.c| 23 ++--
arch/x86/mm/numa.c| 5 ++--
arch/x86/mm/numa_emulation.c | 5 ++--
arch/x86/realmode/init.c | 2 +-
drivers/acpi/tables.c | 5 ++--
drivers/base/arch_numa.c | 5 +---
drivers/of/of_reserved_mem.c | 12 ++---
include/linux/memblock.h | 2 --
mm/memblock.c | 2 +-
16 files changed, 81 insertions(+), 118 deletions(-)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index f97eb2371672..284a80c0b6e1 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -1012,31 +1012,25 @@ static void __init reserve_crashkernel(void)
unsigned long long lowmem_max = __pa(high_memory - 1) + 1;
if (crash_max > lowmem_max)
crash_max = lowmem_max;
- crash_base = memblock_find_in_range(CRASH_ALIGN, crash_max,
- crash_size, CRASH_ALIGN);
+
+ crash_base = memblock_phys_alloc_range(crash_size, CRASH_ALIGN,
+ CRASH_ALIGN, crash_max);
if (!crash_base) {
pr_err("crashkernel reservation failed - No suitable area
found.\n");
return;
}
} else {
+ unsigned long long crash_max = crash_base + crash_size;
unsigned long long start;
- start = memblock_find_in_range(crash_base,
- crash_base + crash_size,
- crash_size, SECTION_SIZE);
- if (start != crash_base) {
+ start = memblock_phys_alloc_range(crash_size, SECTION_SIZE,
+ crash_base, crash_max);
+ if (!start) {
pr_err("crashkernel reservation failed - memory is in
use.\n");
return;
}
}
- ret = memblock_reserve(crash_base, crash_size);
- if (ret < 0) {
- pr_warn("crashkernel reservation failed - memory is in use
(0x%lx)\n",
- (unsigned long)crash_base);
- return;
- }
-
pr_info("Reserving %ldMB of memory at %ldMB for crashkernel (System RAM:
%ldMB)\n",
(unsigned long)(crash_size >> 20),
(unsigned long)(crash_base >> 20),
diff --git a/arch/arm64/kvm/hyp/reserved_mem.c
b/arch/arm64/kvm/hyp/reserved_mem.c
index d654921dd09b..578670e3f608 100644
--- a/
Re: [PATCH v4 0/2] memblock: make memblock_find_in_range method private
Mike, On Thu, Aug 12, 2021 at 09:59:05AM +0300, Mike Rapoport wrote: > From: Mike Rapoport > > Hi, > > This is v4 of "memblock: make memblock_find_in_range method private" patch > that essentially replaces memblock_find_in_range() + memblock_reserve() > calls with equivalent calls to memblock_phys_alloc() and prevents usage of > memblock_find_in_range() outside memblock itself. > > The patch uncovered an issue with top down memory mapping on x86 and this > version has a preparation patch that addresses this issue. > > Guenter, I didn't add your Tested-by because the patch that addresses the > crashes differs from the one you've tested. > Unfortunately I am still seeing crashes. 1G of memory, x86_64: [0.00] efi: EFI v2.70 by EDK II [0.00] efi: SMBIOS=0x3fbcc000 ACPI=0x3fbfa000 ACPI 2.0=0x3fbfa014 MEMATTR=0x3f229018 [0.00] SMBIOS 2.8 present. [0.00] DMI: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 [0.00] tsc: Fast TSC calibration using PIT [0.00] tsc: Detected 3792.807 MHz processor [0.001816] last_pfn = 0x3ff50 max_arch_pfn = 0x4 [0.002595] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT [0.022989] Using GB pages for direct mapping [0.025601] Kernel panic - not syncing: alloc_low_pages: can not alloc memory [0.025910] CPU: 0 PID: 0 Comm: swapper Not tainted 5.14.0-rc5+ #1 [0.026133] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 [0.026462] Call Trace: [0.026942] ? dump_stack_lvl+0x57/0x7d [0.027475] ? panic+0x10a/0x2de [0.027600] ? alloc_low_pages+0x117/0x156 [0.027704] ? phys_pmd_init+0x234/0x342 [0.027817] ? phys_pud_init+0x171/0x337 [0.027926] ? __kernel_physical_mapping_init+0xec/0x276 [0.028062] ? init_memory_mapping+0x1ea/0x2ca [0.028199] ? init_range_memory_mapping+0xdf/0x12e [0.028326] ? init_mem_mapping+0x1e9/0x261 [0.028432] ? setup_arch+0x5ff/0xb6d [0.028535] ? start_kernel+0x71/0x6b4 [0.028636] ? secondary_startup_64_no_verify+0xc2/0xcb [0.029479] ---[ end Kernel panic - not syncing: alloc_low_pages: can not alloc memory ]--- Complete log: https://kerneltests.org/builders/qemu-x86_64-testing/builds/67/steps/qemubuildcommand/logs/stdio x86, default memory size, all efi boots affected: [0.025676] BUG: unable to handle page fault for address: cf3c1000 [0.025932] #PF: supervisor write access in kernel mode [0.026022] #PF: error_code(0x0002) - not-present page [0.026122] *pde = [0.026308] Oops: 0002 [#1] SMP [0.026468] CPU: 0 PID: 0 Comm: swapper Not tainted 5.14.0-rc5+ #1 [0.026616] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 [0.026848] EIP: alloc_low_pages+0xa0/0x13f [0.027355] Code: 00 74 77 a3 cc ba 62 ca 8b 45 f0 8d 90 00 00 0c 00 31 c0 c1 e2 0c 85 f6 74 16 89 d7 b9 00 04 00 00 83 c3 01 81 c2 00 10 00 00 ab 39 f3 75 ea 8b 45 f0 8d 65 f4 5b 5e c1 e0 0c 5f 5d 2d 00 00 [0.027802] EAX: EBX: 0001 ECX: 0400 EDX: cf3c2000 [0.027903] ESI: 0001 EDI: cf3c1000 EBP: ca389e28 ESP: ca389e18 [0.028006] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 EFLAGS: 00200086 [0.028125] CR0: 80050033 CR2: cf3c1000 CR3: 0a69f000 CR4: 00040690 [0.028287] Call Trace: [0.028603] one_page_table_init+0x15/0x6d [0.028751] kernel_physical_mapping_init+0xdd/0x19b [0.028839] init_memory_mapping+0x146/0x1f1 [0.028921] init_range_memory_mapping+0xfe/0x144 [0.029001] init_mem_mapping+0x145/0x185 [0.029066] setup_arch+0x5ff/0xa75 [0.029128] ? vprintk+0x4c/0x100 [0.029187] start_kernel+0x66/0x5ba [0.029246] ? set_intr_gate+0x42/0x55 [0.029306] ? early_idt_handler_common+0x44/0x44 [0.029380] i386_start_kernel+0x43/0x45 [0.029441] startup_32_smp+0x161/0x164 [0.029567] Modules linked in: [0.029776] CR2: cf3c1000 [0.030406] random: get_random_bytes called from oops_exit+0x35/0x60 with crng_init=0 [0.031121] ---[ end trace 544692cd05e387e2 ]--- [0.031357] EIP: alloc_low_pages+0xa0/0x13f [0.031427] Code: 00 74 77 a3 cc ba 62 ca 8b 45 f0 8d 90 00 00 0c 00 31 c0 c1 e2 0c 85 f6 74 16 89 d7 b9 00 04 00 00 83 c3 01 81 c2 00 10 00 00 ab 39 f3 75 ea 8b 45 f0 8d 65 f4 5b 5e c1 e0 0c 5f 5d 2d 00 00 [0.031698] EAX: EBX: 0001 ECX: 0400 EDX: cf3c2000 [0.031787] ESI: 0001 EDI: cf3c1000 EBP: ca389e28 ESP: ca389e18 [0.031876] DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 EFLAGS: 00200086 [0.031972] CR0: 80050033 CR2: cf3c1000 CR3: 0a69f000 CR4: 00040690 [0.032198] Kernel panic - not syncing: Attempted to kill the idle task! [0.032521] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]-- Complete log: https://kerneltests.org/builders/qemu-x86-testing/builds/65/steps/qemubuildcommand/logs/stdio Guenter ___ kvmarm
Re: [PATCH v3] memblock: make memblock_find_in_range method private
On 8/10/21 11:55 AM, Mike Rapoport wrote: On Mon, Aug 09, 2021 at 12:06:41PM -0700, Guenter Roeck wrote: On Tue, Aug 03, 2021 at 09:42:18AM +0300, Mike Rapoport wrote: From: Mike Rapoport There are a lot of uses of memblock_find_in_range() along with memblock_reserve() from the times memblock allocation APIs did not exist. memblock_find_in_range() is the very core of memblock allocations, so any future changes to its internal behaviour would mandate updates of all the users outside memblock. Replace the calls to memblock_find_in_range() with an equivalent calls to memblock_phys_alloc() and memblock_phys_alloc_range() and make memblock_find_in_range() private method of memblock. This simplifies the callers, ensures that (unlikely) errors in memblock_reserve() are handled and improves maintainability of memblock_find_in_range(). Signed-off-by: Mike Rapoport I see a number of crashes in next-20210806 when booting x86 images from efi. [0.00] efi: EFI v2.70 by EDK II [0.00] efi: SMBIOS=0x1fbcc000 ACPI=0x1fbfa000 ACPI 2.0=0x1fbfa014 MEMATTR=0x1f25f018 [0.00] SMBIOS 2.8 present. [0.00] DMI: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 [0.00] last_pfn = 0x1ff50 max_arch_pfn = 0x4 [0.00] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT [0.00] Kernel panic - not syncing: alloc_low_pages: can not alloc memory [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 5.14.0-rc4-next-20210806 #1 [0.00] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 [0.00] Call Trace: [0.00] ? dump_stack_lvl+0x57/0x7d [0.00] ? panic+0xfc/0x2c6 [0.00] ? alloc_low_pages+0x117/0x156 [0.00] ? phys_pmd_init+0x234/0x342 [0.00] ? phys_pud_init+0x171/0x337 [0.00] ? __kernel_physical_mapping_init+0xec/0x276 [0.00] ? init_memory_mapping+0x1ea/0x2aa [0.00] ? init_range_memory_mapping+0xdf/0x12e [0.00] ? init_mem_mapping+0x1e9/0x26f [0.00] ? setup_arch+0x5ff/0xb6d [0.00] ? start_kernel+0x71/0x6b4 [0.00] ? secondary_startup_64_no_verify+0xc2/0xcb Bisect points to this patch. Reverting it fixes the problem. Key seems to be the amount of memory configured in qemu; the problem is not seen if there is 1G or more of memory, but it is seen with all test boots with 512M or 256M of memory. It is also seen with almost all 32-bit efi boots. The problem is not seen when booting without efi. It looks like this change uncovered a problem in x86::memory_map_top_down(). The allocation in alloc_low_pages() is limited by min_pfn_mapped and max_pfn_mapped. The min_pfn_mapped is updated at every iteration of the loop in memory_map_top_down, but there is another loop in init_range_memory_mapping() that maps several regions below the current min_pfn_mapped without updating this variable. The memory layout in qemu with 256M of RAM and EFI enabled, causes exhaustion of the memory limited by min_pfn_mapped and max_pfn_mapped before min_pfn_mapped is updated. Before this commit there was unconditional "reservation" of 2M in the end of the memory that moved the initial min_pfn_mapped below the memory reserved by EFI. The addition of check for xen_domain() removed this reservation for !XEN and made alloc_low_pages() use the range already busy with EFI data. The patch below moves the update of min_pfn_mapped near the update of max_pfn_mapped so that every time a new range is mapped both limits will be updated accordingly. diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c index 1152a29ce109..be279f6e5a0a 100644 --- a/arch/x86/mm/init.c +++ b/arch/x86/mm/init.c @@ -1,3 +1,4 @@ +#define DEBUG #include #include #include @@ -485,6 +486,7 @@ static void add_pfn_range_mapped(unsigned long start_pfn, unsigned long end_pfn) nr_pfn_mapped = clean_sort_range(pfn_mapped, E820_MAX_ENTRIES); max_pfn_mapped = max(max_pfn_mapped, end_pfn); + min_pfn_mapped = min(min_pfn_mapped, start_pfn); if (start_pfn < (1UL<<(32-PAGE_SHIFT))) max_low_pfn_mapped = max(max_low_pfn_mapped, @@ -643,7 +645,6 @@ static void __init memory_map_top_down(unsigned long map_start, mapped_ram_size += init_range_memory_mapping(start, last_start); last_start = start; - min_pfn_mapped = last_start >> PAGE_SHIFT; if (mapped_ram_size >= step_size) step_size = get_new_step_size(step_size); } The offending patch was removed from next-20210810, but I applied the above change to next-20210809 and it does indeed fix the problem. If it is added as separate patch, please feel free to add Tested-by: Guenter Roeck Thanks, Guenter ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu h
Re: [PATCH v3] memblock: make memblock_find_in_range method private
On Tue, Aug 03, 2021 at 09:42:18AM +0300, Mike Rapoport wrote: > From: Mike Rapoport > > There are a lot of uses of memblock_find_in_range() along with > memblock_reserve() from the times memblock allocation APIs did not exist. > > memblock_find_in_range() is the very core of memblock allocations, so any > future changes to its internal behaviour would mandate updates of all the > users outside memblock. > > Replace the calls to memblock_find_in_range() with an equivalent calls to > memblock_phys_alloc() and memblock_phys_alloc_range() and make > memblock_find_in_range() private method of memblock. > > This simplifies the callers, ensures that (unlikely) errors in > memblock_reserve() are handled and improves maintainability of > memblock_find_in_range(). > > Signed-off-by: Mike Rapoport I see a number of crashes in next-20210806 when booting x86 images from efi. [0.00] efi: EFI v2.70 by EDK II [0.00] efi: SMBIOS=0x1fbcc000 ACPI=0x1fbfa000 ACPI 2.0=0x1fbfa014 MEMATTR=0x1f25f018 [0.00] SMBIOS 2.8 present. [0.00] DMI: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 [0.00] last_pfn = 0x1ff50 max_arch_pfn = 0x4 [0.00] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT [0.00] Kernel panic - not syncing: alloc_low_pages: can not alloc memory [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 5.14.0-rc4-next-20210806 #1 [0.00] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 [0.00] Call Trace: [0.00] ? dump_stack_lvl+0x57/0x7d [0.00] ? panic+0xfc/0x2c6 [0.00] ? alloc_low_pages+0x117/0x156 [0.00] ? phys_pmd_init+0x234/0x342 [0.00] ? phys_pud_init+0x171/0x337 [0.00] ? __kernel_physical_mapping_init+0xec/0x276 [0.00] ? init_memory_mapping+0x1ea/0x2aa [0.00] ? init_range_memory_mapping+0xdf/0x12e [0.00] ? init_mem_mapping+0x1e9/0x26f [0.00] ? setup_arch+0x5ff/0xb6d [0.00] ? start_kernel+0x71/0x6b4 [0.00] ? secondary_startup_64_no_verify+0xc2/0xcb Bisect points to this patch. Reverting it fixes the problem. Key seems to be the amount of memory configured in qemu; the problem is not seen if there is 1G or more of memory, but it is seen with all test boots with 512M or 256M of memory. It is also seen with almost all 32-bit efi boots. The problem is not seen when booting without efi. Guenter --- Bisect log: # bad: [da454ebf578f6c542ba9f5b3ddb98db3ede109c1] Add linux-next specific files for 20210809 # good: [36a21d51725af2ce0700c6ebcb6b9594aac658a6] Linux 5.14-rc5 git bisect start 'HEAD' 'v5.14-rc5' # good: [d22fda64bea5f33000e31e5b7e4ba876bca37436] Merge remote-tracking branch 'crypto/master' git bisect good d22fda64bea5f33000e31e5b7e4ba876bca37436 # good: [b084da3a98fad27a39ed5ca64106b86df0417851] Merge remote-tracking branch 'irqchip/irq/irqchip-next' git bisect good b084da3a98fad27a39ed5ca64106b86df0417851 # good: [a5383d1f57190a33c6afc25c62b9907d84ba2bc6] Merge remote-tracking branch 'staging/staging-next' git bisect good a5383d1f57190a33c6afc25c62b9907d84ba2bc6 # good: [a439da3e6abeb054f4e6b0d37814e762b7340196] Merge remote-tracking branch 'seccomp/for-next/seccomp' git bisect good a439da3e6abeb054f4e6b0d37814e762b7340196 # bad: [9801f3c0890c7b992b45a5c2afcb16c5cdc8388e] mm/idle_page_tracking: Make PG_idle reusable git bisect bad 9801f3c0890c7b992b45a5c2afcb16c5cdc8388e # good: [b4f7f4a9b542836683308d48ffdd18471c6f3e76] lazy-tlb-allow-lazy-tlb-mm-refcounting-to-be-configurable-fix git bisect good b4f7f4a9b542836683308d48ffdd18471c6f3e76 # good: [e30842a48c36f094271eea0984bb861b49c49c87] mm/vmscan: add 'else' to remove check_pending label git bisect good e30842a48c36f094271eea0984bb861b49c49c87 # bad: [65300b20a21214fb2043419d4e5da1d9947c6e15] mm/madvise: add MADV_WILLNEED to process_madvise() git bisect bad 65300b20a21214fb2043419d4e5da1d9947c6e15 # bad: [7348da7a8c244d1a755bc5838b04cb9b1b6ee06c] memblock: make memblock_find_in_range method private git bisect bad 7348da7a8c244d1a755bc5838b04cb9b1b6ee06c # good: [98f8c467fe2ba8e553b450b2a3294d69f1f2027f] mm-mempolicy-convert-from-atomic_t-to-refcount_t-on-mempolicy-refcnt-fix git bisect good 98f8c467fe2ba8e553b450b2a3294d69f1f2027f # good: [760ded422ebe4f8899905b752d8378c44f2a78f3] mm/memplicy: add page allocation function for MPOL_PREFERRED_MANY policy git bisect good 760ded422ebe4f8899905b752d8378c44f2a78f3 # good: [fbfa0492d9639b67119d3d94b7a6a3f85e064260] mm/mempolicy: advertise new MPOL_PREFERRED_MANY git bisect good fbfa0492d9639b67119d3d94b7a6a3f85e064260 # good: [ff6d5759a871883aeea38309fb16d91666179328] mm/mempolicy: unify the create() func for bind/interleave/prefer-many policies git bisect good ff6d5759a871883aeea38309fb16d91666179328 # first bad commit: [7348da7a8c244d1a755bc5838b04cb9b1b6ee06c] memblock: make memblock_find_in_range method private
Re: [PATCH 5.4 000/244] 5.4.119-rc1 review
On Wed, May 12, 2021 at 06:00:16PM +0100, Alexandru Elisei wrote:
> Hi Naresh,
>
> Thank you for the report!
>
> On 5/12/21 5:47 PM, Naresh Kamboju wrote:
> > On Wed, 12 May 2021 at 20:22, Greg Kroah-Hartman
> > wrote:
> >> This is the start of the stable review cycle for the 5.4.119 release.
> >> There are 244 patches in this series, all will be posted as a response
> >> to this one. If anyone has any issues with these being applied, please
> >> let me know.
> >>
> >> Responses should be made by Fri, 14 May 2021 14:47:09 +.
> >> Anything received after that time might be too late.
> >>
> >> The whole patch series can be found in one patch at:
> >>
> >> https://www.kernel.org/pub/linux/kernel/v5.x/stable-review/patch-5.4.119-rc1.gz
> >> or in the git tree and branch at:
> >>
> >> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
> >> linux-5.4.y
> >> and the diffstat can be found below.
> >>
> >> thanks,
> >>
> >> greg k-h
> > Build regression detected.
> >
> >> Alexandru Elisei
> >> KVM: arm64: Initialize VCPU mdcr_el2 before loading it
> > stable rc 5.4 arm axm55xx_defconfig builds failed due to these
> > warnings / errors.
> > - arm (axm55xx_defconfig) with gcc-8,9 and 10 failed
> >
> > arch/arm/kvm/../../../virt/kvm/arm/arm.c: In function
> > 'kvm_vcpu_first_run_init':
> > arch/arm/kvm/../../../virt/kvm/arm/arm.c:582:2: error: implicit
> > declaration of function 'kvm_arm_vcpu_init_debug'; did you mean
> > 'kvm_arm_init_debug'? [-Werror=implicit-function-declaration]
> > kvm_arm_vcpu_init_debug(vcpu);
> > ^~~
> > kvm_arm_init_debug
> > cc1: some warnings being treated as errors
>
> This is my fault, in Linux v5.4 KVM for arm is still around, and there's no
> prototype for the function when compiling for arm. I suspect that's also the
> case
> for v4.19.
>
Correct.
Guenter
> I made this change to get it to build:
>
> $ git diff
> diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
> index dd03d5e01a94..32564b017ba0 100644
> --- a/arch/arm/include/asm/kvm_host.h
> +++ b/arch/arm/include/asm/kvm_host.h
> @@ -335,6 +335,7 @@ static inline void kvm_arch_sched_in(struct kvm_vcpu
> *vcpu,
> int cpu) {}
> static inline void kvm_arch_vcpu_block_finish(struct kvm_vcpu *vcpu) {}
>
> static inline void kvm_arm_init_debug(void) {}
> +static inline void kvm_arm_vcpu_init_debug(struct kvm_vcpu *vcpu) {}
> static inline void kvm_arm_setup_debug(struct kvm_vcpu *vcpu) {}
> static inline void kvm_arm_clear_debug(struct kvm_vcpu *vcpu) {}
> static inline void kvm_arm_reset_debug_ptr(struct kvm_vcpu *vcpu) {}
>
> which matches the stub for kvm_arm_init_debug(). I can spin a patch out of it
> and
> send it for 5.4 and 4.19. Marc, what do you think?
>
> Thanks,
>
> Alex
>
> >
> >
> > steps to reproduce:
> >
> > #!/bin/sh
> >
> > # TuxMake is a command line tool and Python library that provides
> > # portable and repeatable Linux kernel builds across a variety of
> > # architectures, toolchains, kernel configurations, and make targets.
> > #
> > # TuxMake supports the concept of runtimes.
> > # See https://docs.tuxmake.org/runtimes/, for that to work it requires
> > # that you install podman or docker on your system.
> > #
> > # To install tuxmake on your system globally:
> > # sudo pip3 install -U tuxmake
> > #
> > # See https://docs.tuxmake.org/ for complete documentation.
> >
> >
> > tuxmake --runtime podman --target-arch arm --toolchain gcc-8 --kconfig
> > axm55xx_defconfig
> >
> > ref:
> > https://builds.tuxbuild.com/1sRT0HOyHnZ8N5ktJmaEcMIQZL0/
> >
> >
> > --
> > Linaro LKFT
> > https://lkft.linaro.org
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v2 4/8] KVM: arm64: Generate hyp relocation data
On Sat, Jan 30, 2021 at 01:44:15PM +, Marc Zyngier wrote:
> On Fri, 29 Jan 2021 21:43:25 +,
> Guenter Roeck wrote:
> >
> > Hi,
> >
> > On Tue, Jan 05, 2021 at 06:05:37PM +, David Brazdil wrote:
> > > Add a post-processing step to compilation of KVM nVHE hyp code which
> > > calls a custom host tool (gen-hyprel) on the partially linked object
> > > file (hyp sections' names prefixed).
> > >
> > > The tool lists all R_AARCH64_ABS64 data relocations targeting hyp
> > > sections and generates an assembly file that will form a new section
> > > .hyp.reloc in the kernel binary. The new section contains an array of
> > > 32-bit offsets to the positions targeted by these relocations.
> > >
> > > Since these addresses of those positions will not be determined until
> > > linking of `vmlinux`, each 32-bit entry carries a R_AARCH64_PREL32
> > > relocation with addend + . The linker of
> > > `vmlinux` will therefore fill the slot accordingly.
> > >
> > > This relocation data will be used at runtime to convert the kernel VAs
> > > at those positions to hyp VAs.
> > >
> > > Signed-off-by: David Brazdil
> >
> > This patch results in the following error for me.
> >
> > error: arch/arm64/kvm/hyp/nvhe/kvm_nvhe.tmp.o: assertion
> > elf.ehdr->e_ident[5] == 1 failed (lhs=2, rhs=1, line=250)
> >
> > The problem is seen when trying to build aarch64 images in big endian
> > mode.
> >
> > Te script used to reproduce the problem as well as bisect results are
> > attached.
>
> I came up with the following patch, which allows the kernel to link
> and boot. I don't have any BE userspace, so I didn't verify that I
> could boot a guest (the hypervisor does correctly initialise though).
>
> It's not exactly pretty, but it does the job...
>
> Thanks,
>
> M.
>
> From d80ca05b2ed90fc30d328041692fa80f525c8d12 Mon Sep 17 00:00:00 2001
> From: Marc Zyngier
> Date: Sat, 30 Jan 2021 13:07:51 +
> Subject: [PATCH] KVM: arm64: Make gen-hyprel endianness agnostic
>
> gen-hyprel is, for better or worse, a native-endian program:
> it assumes that the ELF data structures are in the host's
> endianness, and even assumes that the compiled kernel is
> little-endian in one particular case.
>
> None of these assumptions hold true though: people actually build
> (use?) BE arm64 kernels, and seem to avoid doing so on BE hosts.
> Madness!
>
> In order to solve this, wrap each access to the ELF data structures
> with the required byte-swapping magic. This requires to obtain
> the kernel data structure, and provide per-endianess wrappers.
>
> This result in a kernel that links and even boots in a model.
>
> Fixes: 8c49b5d43d4c ("KVM: arm64: Generate hyp relocation data")
> Reported-by: Guenter Roeck
> Signed-off-by: Marc Zyngier
Tested-by: Guenter Roeck
Compiles and boots both big- and little-endian systems in qemu.
Guenter
> ---
> arch/arm64/kvm/hyp/nvhe/Makefile | 1 +
> arch/arm64/kvm/hyp/nvhe/gen-hyprel.c | 57
> 2 files changed, 42 insertions(+), 16 deletions(-)
>
> diff --git a/arch/arm64/kvm/hyp/nvhe/Makefile
> b/arch/arm64/kvm/hyp/nvhe/Makefile
> index 268be1376f74..09d04dd50eb8 100644
> --- a/arch/arm64/kvm/hyp/nvhe/Makefile
> +++ b/arch/arm64/kvm/hyp/nvhe/Makefile
> @@ -7,6 +7,7 @@ asflags-y := -D__KVM_NVHE_HYPERVISOR__
> ccflags-y := -D__KVM_NVHE_HYPERVISOR__
>
> hostprogs := gen-hyprel
> +HOST_EXTRACFLAGS += -I$(srctree)/include
>
> obj-y := timer-sr.o sysreg-sr.o debug-sr.o switch.o tlb.o hyp-init.o host.o \
>hyp-main.o hyp-smp.o psci-relay.o
> diff --git a/arch/arm64/kvm/hyp/nvhe/gen-hyprel.c
> b/arch/arm64/kvm/hyp/nvhe/gen-hyprel.c
> index 58fe31fdba8e..ead02c6a7628 100644
> --- a/arch/arm64/kvm/hyp/nvhe/gen-hyprel.c
> +++ b/arch/arm64/kvm/hyp/nvhe/gen-hyprel.c
> @@ -25,6 +25,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -36,6 +37,8 @@
> #include
> #include
>
> +#include
> +
> #define HYP_SECTION_PREFIX ".hyp"
> #define HYP_RELOC_SECTION".hyp.reloc"
> #define HYP_SECTION_SYMBOL_PREFIX"__hyp_section_"
> @@ -121,6 +124,28 @@ static struct {
> const char *sh_string;
> } elf;
>
> +#if defined(CONFIG_CPU_LITTLE_ENDIAN)
> +
> +#define elf16toh(x) le16toh(x)
> +#define elf32toh(x) le32toh(x)
> +#define elf64toh(x) le64toh(x)
> +
> +#define ELFENDIANELFDATA2LSB
> +
> +#elif defined(CONFIG_CPU_BIG_ENDIAN
Re: [PATCH v2 4/8] KVM: arm64: Generate hyp relocation data
Hi, On Tue, Jan 05, 2021 at 06:05:37PM +, David Brazdil wrote: > Add a post-processing step to compilation of KVM nVHE hyp code which > calls a custom host tool (gen-hyprel) on the partially linked object > file (hyp sections' names prefixed). > > The tool lists all R_AARCH64_ABS64 data relocations targeting hyp > sections and generates an assembly file that will form a new section > .hyp.reloc in the kernel binary. The new section contains an array of > 32-bit offsets to the positions targeted by these relocations. > > Since these addresses of those positions will not be determined until > linking of `vmlinux`, each 32-bit entry carries a R_AARCH64_PREL32 > relocation with addend + . The linker of > `vmlinux` will therefore fill the slot accordingly. > > This relocation data will be used at runtime to convert the kernel VAs > at those positions to hyp VAs. > > Signed-off-by: David Brazdil This patch results in the following error for me. error: arch/arm64/kvm/hyp/nvhe/kvm_nvhe.tmp.o: assertion elf.ehdr->e_ident[5] == 1 failed (lhs=2, rhs=1, line=250) The problem is seen when trying to build aarch64 images in big endian mode. Te script used to reproduce the problem as well as bisect results are attached. Guenter --- Script used to reproduce the problem: make-arm64 allmodconfig echo "CONFIG_CPU_BIG_ENDIAN=y" >> .config make-arm64 olddefconfig rm -f arch/arm64/kvm/hyp/nvhe/kvm_nvhe.o make-arm64 -j arch/arm64/kvm/hyp/nvhe/kvm_nvhe.o where make-arm64 is: make -j32 ARCH=arm64 CROSS_COMPILE=aarch64-linux- $* --- # bad: [b01f250d83f6c3af5c77699dd14e7b48ee0b5383] Add linux-next specific files for 20210129 # good: [6ee1d745b7c9fd573fba142a2efdad76a9f1cb04] Linux 5.11-rc5 git bisect start 'HEAD' 'v5.11-rc5' # good: [7b7f6e418b7121fd3f05029f843ff1eb76e4cc4d] Merge remote-tracking branch 'crypto/master' git bisect good 7b7f6e418b7121fd3f05029f843ff1eb76e4cc4d # good: [4a8b64f4e85b5f2d8e68641ce26af8cf9d9a66af] Merge remote-tracking branch 'keys/keys-next' git bisect good 4a8b64f4e85b5f2d8e68641ce26af8cf9d9a66af # bad: [79a914d7f707c1aa5ede7ce38588b32093b2abbe] Merge remote-tracking branch 'thunderbolt/next' git bisect bad 79a914d7f707c1aa5ede7ce38588b32093b2abbe # good: [f22712067d6f3d1884186509a942da26d2d52166] Merge remote-tracking branch 'rcu/rcu/next' git bisect good f22712067d6f3d1884186509a942da26d2d52166 # bad: [4a42e6b0a53bcc4b58a35b8d5df50581e94b1daa] Merge remote-tracking branch 'usb/usb-next' git bisect bad 4a42e6b0a53bcc4b58a35b8d5df50581e94b1daa # good: [1a9e38cabd80356ffb98c2c88fec528ea9644fd5] usb: dwc2: Make "trimming xfer length" a debug message git bisect good 1a9e38cabd80356ffb98c2c88fec528ea9644fd5 # bad: [589e25c6dfdd535e8eba052f7314054f6d75be4a] Merge remote-tracking branch 'drivers-x86/for-next' git bisect bad 589e25c6dfdd535e8eba052f7314054f6d75be4a # bad: [08c11d16ca91e770de81e5959e22eb34541f8af9] Merge remote-tracking branch 'percpu/for-next' git bisect bad 08c11d16ca91e770de81e5959e22eb34541f8af9 # bad: [cc6d8fa3667aa5513dc2bbca896a4c287aa956f3] Merge branch 'kvm-arm64/misc-5.12' into kvmarm-master/next git bisect bad cc6d8fa3667aa5513dc2bbca896a4c287aa956f3 # bad: [247bc166e6b3b1e4068f120f55582a3aa210cc2d] KVM: arm64: Remove hyp_symbol_addr git bisect bad 247bc166e6b3b1e4068f120f55582a3aa210cc2d # bad: [8c49b5d43d4c45ca0bb0d1faa23feef2e76e89fa] KVM: arm64: Generate hyp relocation data git bisect bad 8c49b5d43d4c45ca0bb0d1faa23feef2e76e89fa # good: [16174eea2e4fe8247e04c17da682f2034fec0369] KVM: arm64: Set up .hyp.rodata ELF section git bisect good 16174eea2e4fe8247e04c17da682f2034fec0369 # good: [f7a4825d9569593b9a81f0768313b86175691ef1] KVM: arm64: Add symbol at the beginning of each hyp section git bisect good f7a4825d9569593b9a81f0768313b86175691ef1 # first bad commit: [8c49b5d43d4c45ca0bb0d1faa23feef2e76e89fa] KVM: arm64: Generate hyp relocation data ___ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
Re: [PATCH v2 30/45] KVM: Move vcpu alloc and init invocation to common code
On Wed, Dec 18, 2019 at 01:55:15PM -0800, Sean Christopherson wrote:
> Now that all architectures tightly couple vcpu allocation/free with the
> mandatory calls to kvm_{un}init_vcpu(), move the sequences verbatim to
> common KVM code.
>
> Move both allocation and initialization in a single patch to eliminate
> thrash in arch specific code. The bisection benefits of moving the two
> pieces in separate patches is marginal at best, whereas the odds of
> introducing a transient arch specific bug are non-zero.
>
> Acked-by: Christoffer Dall
> Signed-off-by: Sean Christopherson
> Reviewed-by: Cornelia Huck
[ ... ]
> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index 8543d338a06a..2ed76584ebd9 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
>
[ ... ]
> -struct kvm_vcpu *kvm_arch_vcpu_create(struct kvm *kvm,
> - unsigned int id)
^^^
> +int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu)
> {
> - struct kvm_vcpu *vcpu;
> struct sie_page *sie_page;
> int rc;
>
> - rc = -ENOMEM;
> -
> - vcpu = kmem_cache_zalloc(kvm_vcpu_cache, GFP_KERNEL);
> - if (!vcpu)
> - goto out;
> -
> - rc = kvm_vcpu_init(vcpu, kvm, id);
> - if (rc)
> - goto out_free_cpu;
> -
> - rc = -ENOMEM;
> -
> BUILD_BUG_ON(sizeof(struct sie_page) != 4096);
> sie_page = (struct sie_page *) get_zeroed_page(GFP_KERNEL);
> if (!sie_page)
> - goto out_uninit_vcpu;
> + return -ENOMEM;
>
> vcpu->arch.sie_block = _page->sie_block;
> vcpu->arch.sie_block->itdba = (unsigned long) _page->itdb;
> @@ -3087,15 +3070,11 @@ struct kvm_vcpu *kvm_arch_vcpu_create(struct kvm *kvm,
>vcpu->arch.sie_block);
> trace_kvm_s390_create_vcpu(id, vcpu, vcpu->arch.sie_block);
^^^
For extensive changes like this, wouldn't it be desirable to at least
compile test it ?
Guenter
___
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
