On Thu, 16 Jun 2022 15:55:26 +0100, Andre Przywara <andre.przywara@xxxxxxx> wrote: > > The GICv2 DT binding describes the third cell in each interrupt > descriptor as holding the trigger type, but also the CPU mask that this > IRQ applies to, in bits [15:8]. However this is not the case for GICv3, > where we don't use a CPU mask in the third cell: a simple mask wouldn't > fit for the many more supported cores anyway. > > At the moment we fill this CPU mask field regardless of the GIC type, > for the PMU and arch timer DT nodes. This is not only the wrong thing to > do in case of a GICv3, but also triggers UBSAN splats when using more > than 30 cores, as we do shifting beyond what a u32 can hold: > $ lkvm run -k Image -c 31 --pmu > arm/timer.c:13:22: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' > arm/timer.c:13:38: runtime error: signed integer overflow: -2147483648 - 1 cannot be represented in type 'int' > arm/timer.c:13:43: runtime error: left shift of 2147483647 by 8 places cannot be represented in type 'int' > arm/aarch64/pmu.c:202:22: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' > arm/aarch64/pmu.c:202:38: runtime error: signed integer overflow: -2147483648 - 1 cannot be represented in type 'int' > arm/aarch64/pmu.c:202:43: runtime error: left shift of 2147483647 by 8 places cannot be represented in type 'int' > > Fix that by adding a function that creates the mask by looking at the > GIC type first, and returning zero when a GICv3 is used. Also we > explicitly check for the CPU limit again, even though this would be > done before already, when we try to create a GICv2 VM with more than 8 > cores. > > Signed-off-by: Andre Przywara <andre.przywara@xxxxxxx> Acked-by: Marc Zyngier <maz@xxxxxxxxxx> M. -- Without deviation from the norm, progress is not possible. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
