On Wed, Apr 20, 2022 at 01:07:03PM +0100, Mark Brown wrote:
> On Wed, Apr 20, 2022 at 12:18:04PM +0300, Mike Rapoport wrote:
>
> > I don't know how exactly kernel-ci runs qemu with UEFI, I've tried this:
>
> > $QEMU -serial stdio -M virt-2.11,gic-version=2 -cpu cortex-a15 -m 1G \
> > -drive file=$QEMU_EFI,if=pflash,format=raw,unit=0,readonly=on \
> > -drive file=flash1.img,if=pflash,format=raw,unit=1,readonly=off \
> > -kernel $kernel \
> > -append "console=ttyAMA0"
>
> > with stable-rc/linux-5.4.y and I've got as far as to failure to mount
> > rootfs and the crash in dmu_setup() didn't reproduce for me.
>
> The command should be something to the effect of:
>
> qemu-system-aarch64 -cpu max -machine virt,gic-version=3,mte=on,accel=tcg -nographic -net nic,model=virtio,macaddr=52:54:00:12:34:58 -net user -m 512 -monitor none -bios /var/lib/lava/dispatcher/tmp/75061/deployimages-ptln1wlp/bios/QEMU_EFI.fd -kernel /var/lib/lava/dispatcher/tmp/75061/deployimages-ptln1wlp/kernel/Image -append "console=ttyAMA0,115200 root=/dev/ram0 debug verbose console_msg_format=syslog earlycon" -initrd /var/lib/lava/dispatcher/tmp/75061/deployimages-ptln1wlp/ramdisk/rootfs.cpio.gz -drive format=qcow2,file=/var/lib/lava/dispatcher/tmp/75061/apply-overlay-guest-6hyfr8ki/lava-guest.qcow2,media=disk,if=virtio,id=lavatest
I could reproduce with this, thanks!
The problem is that memremap() uses pfn_valid() to check if RAM resource can
be accessed via linear mapping and this check is wrong.
The problem does not manifest on more recent kernels because the way ARM
registers "System RAM" resources was updated so that it skipped NOMAP
memory.
Can you please give a whirl to the patch below? If it's Ok I'll extend it
to include arm64 and will send a formal patch.
diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 7a0596fcb2e7..2df7454be649 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -144,6 +144,10 @@ extern void __iomem * (*arch_ioremap_caller)(phys_addr_t, size_t,
unsigned int, void *);
extern void (*arch_iounmap)(volatile void __iomem *);
+extern bool arch_memremap_can_ram_remap(resource_size_t offset, size_t size,
+ unsigned long flags);
+#define arch_memremap_can_ram_remap arch_memremap_can_ram_remap
+
/*
* Bad read/write accesses...
*/
diff --git a/arch/arm/mm/ioremap.c b/arch/arm/mm/ioremap.c
index 513c26b46db3..98f90cd5a948 100644
--- a/arch/arm/mm/ioremap.c
+++ b/arch/arm/mm/ioremap.c
@@ -42,6 +42,13 @@
#include <asm/mach/pci.h>
#include "mm.h"
+bool arch_memremap_can_ram_remap(resource_size_t offset, size_t size,
+ unsigned long flags)
+{
+ unsigned long pfn = PHYS_PFN(offset);
+
+ return memblock_is_map_memory(pfn);
+}
LIST_HEAD(static_vmlist);
diff --git a/kernel/iomem.c b/kernel/iomem.c
index 62c92e43aa0d..e85bed24c0a9 100644
--- a/kernel/iomem.c
+++ b/kernel/iomem.c
@@ -33,7 +33,7 @@ static void *try_ram_remap(resource_size_t offset, size_t size,
unsigned long pfn = PHYS_PFN(offset);
/* In the simple case just return the existing linear address */
- if (pfn_valid(pfn) && !PageHighMem(pfn_to_page(pfn)) &&
+ if (!PageHighMem(pfn_to_page(pfn)) &&
arch_memremap_can_ram_remap(offset, size, flags))
return __va(offset);
> (with different paths) where QEMU_EFI.fd is:
>
> http://storage.kernelci.org/images/uefi/edk2-stable202005/arm64/QEMU_EFI.fd
>
> I didn't pull an exact job, sorry. A full job showing the expected flow
> (for GICv3 which shows the same thing) is at:
>
> https://lava.sirena.org.uk/scheduler/job/75061
--
Sincerely yours,
Mike.
