On Thu, Jan 05, 2023 at 11:09:58PM +0000, Colton Lewis wrote: > Andrew Jones <andrew.jones@xxxxxxxxx> writes: > > On Tue, Dec 20, 2022 at 04:32:00PM +0000, Colton Lewis wrote: > > > Alexandru Elisei <alexandru.elisei@xxxxxxx> writes: > > Ah, I think I understand now. Were you running 32-bit arm tests? If so, > > it'd be good to point that out explicitly in the commit message (the > > 'arm:' prefix in the summary is ambiguous). > > No, this was happening on arm64. Since it had been a while since I noted > this issue, I reviewed it and realized the issue was only happening > using -accel tcg. That was automatically being used on my problem test > machine without me noticing. That's where the limit of 8 seems to be > coming from and why the loop is triggered. > > qemu-system-aarch64: Number of SMP CPUs requested (152) exceeds max CPUs > supported by machine 'mach-virt' (8) > > Since this case doesn't directly involve KVM, I doubt anyone cares about > a fix. > > > Assuming the loop body was running because it needed to reduce MAX_SMP to > > 8 or lower for 32-bit arm tests, then we should be replacing the loop with > > something that caps MAX_SMP at 8 for 32-bit arm tests instead. > > We could cap at 8 for ACCEL=tcg. Even if no one cares, I'm tempted to do > it so no one hits the same little landmine as me in the future. TCG supports up to 255 CPUs. The only reason it'd have a max of 8 is if you were configuring a GICv2 instead of a GICv3. Using gic-version=3 or gic-version=max should allow the 152 CPUs to work. Actually, I should have asked about your gic version instead of whether or not the VM was AArch32 in the first place. I was incorrectly associating the gicv2 limits with arm32 since my memories of these things have started to blur together... Thanks, drew _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
