08:46 <milkylainen> Is there a guide to what kernel options I need when building an ARM guest for qemu/kvm? I tried with what I thought would be sane, but the kernel doesn't seem to start? I've tried the same for x86_64 and aarch64 without any issues.

08:47 <milkylainen> Probably forgot something mundane.

08:47 <milkylainen> -m virt -cpu cortex-a7 or similar was the idea. Or do I need to target a specific board in the arm case?

09:08 <arnd> milkylainen: 'make kvm_guest.config' pulls in the options from kernel/configs/kvm_guest.config, that is normally enough

09:10 <arnd> most of the time when it doesn't appear to boot, the problem is just the console, e.g. you forgot the '-append console=ttyAMA0' , or qemu doesn't connect the console to your terminal

09:11 <milkylainen> arnd: Ok. Will check the config. Didn't forget the console though. :)

09:32 <milkylainen> .config:4184:warning: trying to assign nonexistent symbol VIRTUALIZATION

09:32 <milkylainen> .config:4188:warning: trying to assign nonexistent symbol S390_GUEST

09:37 <milkylainen> arm doesn't have kvm anymore. So what use is kvm_guest?

09:41 <milkylainen> So arm without kvm, under tcg I guess?

09:43 <j`ey> arm32 doesn't support kvm, but you can still run an arm32 guest under arm64

09:43 <j`ey> so those options could be useful for that?

09:58 <milkylainen> j`ey: Yes you're right. It's a config merge for your base / defconfig. Obviously. :)

10:08 <arnd> enabling VIRTUALIZATION in kvm_guest.config is probably a (harmless) mistake, as the only thing that depends on it is CONFIG_KVM, and that is not enabled

10:09 <arnd> CONFIG_S390_GUEST is part of the fragment to make it work on arch/s390, and not having it has no effect on other architectures, but there is no easy way to avoid the warning

10:10 <arnd> milkylainen: fwiw, if you want to actually run a 32-bit distro in a KVM guest on a 64-bit machine, using a 64-bit kernel in the guest is almost always better

10:10 <arnd> of course if your goal is to debug the arch/arm/ kernel in kvm, then using a guest 64-bit kernel won't help you

10:11 <milkylainen> arnd: Agreed. I intentionally want to run a 32-bit arm guest. :)

10:14 <milkylainen> I wonder how the arm future is going to look btw. Are they going to drop 32-bit from ARMv9 implementations altogether going forward? The 710 seems to run 32-bit in EL0 iiuc, but other than that?

10:30 <arnd> milkylainen: Arm have announced that the "big" cores for mobile use drop 32-bit EL0 after Cortex-A710

10:31 <milkylainen> Oh. So gone.

10:31 <milkylainen> ?

10:31 <arnd> Cortex-A510 doesn't support it at all, but the wording of the announcement suggests that there are plans for future "little" cores, or non-mobile cores, that support 32-bit EL0 again

10:33 <arnd> I think there was also an announcement that there would be no further cores that can do 32-bit EL1, not sure what the last cores are that have it

10:36 <arnd> milkylainen: apparently Cortex-A75/A55 still have aarch32 EL1, but A76 and later only do EL0, meaning that you can still run 32-bit distros but have to use a 64-bit kernel

10:38 <milkylainen> arnd: Hmm. Sounds like a dead end to me. But I don't see much uptake on new cores beside mobile phones and high end servers? A-510 embedded implementations? I tried to find anything to play with. Do you have access to armv9 hardware beside something going to the mobile phone market?

10:38 <milkylainen> brb

10:39 <arnd> milkylainen: embedded hardware is usually a few years behind the latest mobile SoCs because of their product lifecycles, I wouldn't expect it anytime soon.

10:40 <arnd> but a new "little" core with 32-bit EL0 would be the obvious replacement for today's Cortex-A7/A53/A55/A73 based products

11:17 <milkylainen> arnd: I still see a lot of new A7 designs. Very little uptake of A35 etc?

11:51 <maz> arnd: can you please have a look at this 20220310200920.qtsw6c277yxvdinb@skbuf ? it's been broken since 5.16.

11:52 <ajb-lina-> milkylainen: FWIW https://transfer.sh/HsBkDg/armhf.config is a 5.16 config which boots my Debian image with "console=ttyAMA0 root=/dev/sda2 vmalloc=512M" and virtio-net-pci and virtio-scsi-pci devices

11:57 <arnd> milkylainen: it takes a while to trickle down: A7 is usually done in 28nm, which also tends to be the cheapest process. A53 is what you get when you need something "better" and/or the next smaller process (22/16/14/12nm), or A55 for another step in the same direction. I think the A35 has only made it into chips that care a lot about power consumption but not as much about the wide pipeline of the more common A53

11:58 <arnd> maz: I shawnguo is ok with the patch, I can queue that as a last-minute fix for 5.17, the explanation certainly makes sense to me

11:59 <arnd> I don't have any other fixes queued at the moment

12:00 <arnd> robher: any last comments on the revert of your patch?

12:03 <shawnguo> arnd: I'm fine with the revert (I was hoping we can get some comment from Rob)

12:06 <arnd> thanks shawnguo

12:07 <milkylainen> ajb-lina-: I see my mistake now. D'oh. I don't know how I missed it. But thanks.

12:07 <arnd> I see robher is listed as idle for six days here, so we probably won't get a reply from him today either

12:07 <milkylainen> and ardb was right. (I did screw up my console) :D

12:09 <mort> Does Linux have some way to get some persistent label associated with a SPI device? Is /sys/class/spidev/spidevX.Y/dev the closest thing to the GPIO system's .../gpiochipN/label?

12:09 <milkylainen> arnd, even.

12:09 <mort> or is there some ioctl to get the name or something?

12:10 <mort> or are you expected to use spidevX.Y itself as the stable name for that SPI device

12:16 <arnd> milkylainen: if you have it working now, is there anything that you needed to enable in multi_v7_defconfig fron kvm_guest.config? I'd like to get to the point of being able to run all the important defconfig builds.

12:17 <arnd> It should normally just work though, and I just merged a patch from roxell to also allow running multi_v5_defconfig in qemu with -M versatilepb

12:47 <geertu> mort: There are SPI aliases in DT, to refer to (labeled!) SPI ports.

12:47 <mort> geertu: But how do you get the alias names from userspace?

12:49 <geertu> mort: /sys/class/firmware/device-tree/aliases?

12:51 <milkylainen> arnd: multi_v7_defconfig is ok. I think what confused me was the explicit ARCH_VIRT in arm, but not in arm64? ARCH_VIRT -> AMBA -> console on pl011. So when I did my own config I missed ARCH_VIRT and didn't pay enough attention in the serial drivers. An obvious facepalm.

12:54 <milkylainen> "didn't forget the console" :P

13:14 <ajb-lina-> arnd: add so can we update https://qemu.readthedocs.io/en/latest/system/arm/versatile.html?

13:20 <ajb-linaro> arnd: we are trying to expand out board model documentation to have better examples because config tweaking and questions about it happens a lot with QEMUs myriad of models

13:21 <arnd> ajb-linaro: the patch from roxell added virtio-blk, not SYM53C8XX_2

13:23 <ajb-linaro> arnd: are the virtio devices not in by default on multi_ configs?

13:23 <arnd> ajb-linaro: now they are ;-)

13:24 <arnd> ajb-linaro: it may be better to use realview-eb-mpcore as the default pre-v7 target instead of versatilepb, because its memory configuration is not quite as crippled, but I couldn't get that to work when I last tried

13:38 <arnd> ajb-linaro: do you think there is a chance of adding a qemu target for armv4/v5/v6 that can be used for testing Linux kernels like we have on armv7/v8 and the other architectures?

13:41 <robher> arnd: reverting will throw a dtc warning I think, but I don't have a better suggestion ATM.

13:45 <ajb-linaro> arnd: it depends on what really exists out there and how complex the SoC might be... can the virt model be used?

13:45 <arnd> robher: right, I see. I'll apply the revert for now then and hope we can come up with a way to avoid the warning for in 5.18 or later

13:46 <ajb-linaro> hmm -M virt only has a7 and a15

13:46 <arnd> ajb-linaro: I asked about -M virt before, but I think the answer I got was that it was only meant for emulating machines that exist as KVM guests, so it only supports cortex-A7/A15 and up

13:47 <arnd> and there are probably some internals in qemu that don't quite work when replacing the A7 with an arm926, e.g. the GIC probably expects a modern CPU

13:49 <ajb-linaro> arnd: you can always do the reverse and grep the strings in target/arm/cpu_tcg.c and see which models use them... the arm926 is widely used

13:50 <ajb-linaro> arnd: but as you go further back its QEMU's random selection of weird PDAs and cameras as boards

13:50 <arnd> ajb-linaro: I know which models have an arm926, the problem is that they are all bad because they reflect what hardware looked like 15 years ago, and they all either don't let you pick PCI or they are limited to a tiny amount of RAM

13:51 <ajb-linaro> arnd: well what real systems exist with these old chips that do have what you need for a modern kernel?

13:52 <ajb-linaro> arnd: otherwise you might as well drop support for these things...

13:52 <ajb-linaro> arnd: given you are the destroyer of old architectures and SoCs ;-)

13:56 <arnd> ajb-linaro: in terms of appropriate real hardware, there would be ast2400 (the newer ARM11 AST2500 is supported), but what I really want is a way to quickly test that the kernel still works on ARMv5 hardware with a normal Debian user space, instead of having to run a minimal user space that one would deploy on actual systems

13:58 <ajb-linaro> arnd: we've been slowly gaining various BMC models although I suspect they are all running super stripped down OSes

13:58 <ajb-linaro> aspeed is actively maintained

14:00 <arnd> ajb-linaro: ah, I see palmetto-bmc and supermicrox11-bmc, which seems to allow 512MB each

14:01 <arnd> maybe I can find a working dtb file for that somewhere

14:02 <arnd> ah, they do ship with the kernel, just not with the name I was looking for

14:03 <arnd> no, doesn't have PCIe host, only endpoint...

15:30 <ardb> arnd: mach-virt exposes PSCI, which needs the virt extensions to do HVC hypercalls

15:30 <ardb> i think that is the primary reason for only supporting A15 in 32-bit mode

15:31 <arnd> ardb: why couldn't it just leave out the PSCI nodes? There is no SMP support anyway, and the virtual machine does not need fancy idle states

15:32 <ardb> arnd: i'm sure it could, but nobody bothered

15:32 <arnd> ardb: I've tried it out locally with a hacked qemu, the main problem I'm running into is that I don't have a clocksource

15:33 <arnd> the virt machine uses arch timers by default, but those cause an undefined instruction trap, and I could not make it use the MMIO version instead

15:34 <arnd> ardb: for PSCI I suppose even leaving the PSCI nodes in place doesn't cause problems because an ARMv5 kernel won't have the code included either, this is only a problem for armv6