On Thu, 4 Jan 2024 at 17:17, Michael Tokarev <m...@tls.msk.ru> wrote: > > 04.01.2024 19:25, Michael Tokarev wrote: > ... > > this archive contains kernel+initrd. I run it this way: > > > > qemu-system-arm -append root=LABEL=debvm -nographic -machine type=virt \ > > -drive media=disk,format=raw,file=vmlinuz,if=virtio,snapshot=on \ > > -no-user-config -m 1G -kernel vmlinuz -initrd initrd.img > > This is actually even more fishy. > > The reproducer needs -cpu max to "work." Without -cpu max, it > fails to recognize virtio pci devices in both cases - in 8.2.0 > with or without the commit in question (b8f7959f28c4f36496). > Only with -cpu max it works after reverting b8f7959f28c. > > Additional kernel message in case when it doesn't work: > > [ 1.372841] pci-host-generic 4010000000.pcie: \ > can't claim ECAM area [mem 0x10000000-0x1fffffff]: \ > address conflict with pcie@10000000 [mem 0x10000000-0x3efeffff] > > which isn't generated in case everything's ok.
This looks in fact like commit b8f7959f28c fixed a bug which was masking problems with booting newer kernels. What happens is: * arm_pamax() is a function for finding out the maximum physical address space size supported by the CPU * it is called by the virt board on a CPU object which has been inited but not realized * before b8f7959f28c the implications like "V7VE implies LPAE" were only done at realize, and so arm_pamax() has some manual workarounds to do the same logic * but those workarounds were missing the case "v8 implies v7ve implies lpae", so for a v8 CPU we incorrectly reported that it could only do 32 bit addressing (affecting only "max" on qemu-system-arm) b8f7959f28c moves where we do the "v8 implies v7ve etc" logic, which means that * the workarounds in arm_pamax() aren't needed any more * we now correctly report 40 bits as the pa size for 'max' (That is, '-cpu max' then behaves the same as '-cpu cortex-a15', as intended.) Unfortunately it seems like these kernels don't correctly handle how we report the PCI controller when we're using a 40-bit address space. This seems like it's probably a kernel bug, but it might be that we're getting the DTB wrong. In any case it seems a bit awkward to actively require the guest kernel to be LPAE in order to boot on an LPAE CPU, so maybe we should tweak the logic to not put the ECAM in high memory for a 32-bit CPU. thanks -- PMM
