All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Andre Przywara <andre.przywara@arm.com>
Cc: Will Deacon <will@kernel.org>,
	kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org
Subject: Re: [PATCH kvmtool] arm: gic: fdt: fix PPI CPU mask calculation
Date: Fri, 01 Jul 2022 16:05:11 +0100	[thread overview]
Message-ID: <87k08w27rs.wl-maz@kernel.org> (raw)
In-Reply-To: <20220616145526.3337196-1-andre.przywara@arm.com>

On Thu, 16 Jun 2022 15:55:26 +0100,
Andre Przywara <andre.przywara@arm.com> 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@arm.com>

Acked-by: Marc Zyngier <maz@kernel.org>

	M.

-- 
Without deviation from the norm, progress is not possible.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Andre Przywara <andre.przywara@arm.com>
Cc: Will Deacon <will@kernel.org>,
	Julien Thierry <julien.thierry.kdev@gmail.com>,
	Alexandru Elisei <alexandru.elisei@arm.com>,
	kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org
Subject: Re: [PATCH kvmtool] arm: gic: fdt: fix PPI CPU mask calculation
Date: Fri, 01 Jul 2022 16:05:11 +0100	[thread overview]
Message-ID: <87k08w27rs.wl-maz@kernel.org> (raw)
In-Reply-To: <20220616145526.3337196-1-andre.przywara@arm.com>

On Thu, 16 Jun 2022 15:55:26 +0100,
Andre Przywara <andre.przywara@arm.com> 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@arm.com>

Acked-by: Marc Zyngier <maz@kernel.org>

	M.

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2022-07-01 15:05 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-16 14:55 [PATCH kvmtool] arm: gic: fdt: fix PPI CPU mask calculation Andre Przywara
2022-06-16 14:55 ` Andre Przywara
2022-07-01 15:05 ` Marc Zyngier [this message]
2022-07-01 15:05   ` Marc Zyngier
2022-07-01 15:41 ` Will Deacon
2022-07-01 15:41   ` Will Deacon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87k08w27rs.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=andre.przywara@arm.com \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.