On 22/08/2019 14:42, Andre Przywara wrote:
> On Thu, 22 Aug 2019 01:13:32 +0800
> Zenghui Yu wrote:
>
> Hi,
>
>> On 2019/8/22 1:00, Andre Przywara wrote:
>>> At the moment we initialise the target *mask* of a virtual IRQ to the
>>> VCPU it belongs to, even though this mask is only defined for
On Thu, 22 Aug 2019 01:13:32 +0800
Zenghui Yu wrote:
Hi,
> On 2019/8/22 1:00, Andre Przywara wrote:
> > At the moment we initialise the target *mask* of a virtual IRQ to the
> > VCPU it belongs to, even though this mask is only defined for GICv2 and
> > quickly runs out of bits for many GICv3
On 2019/8/22 1:00, Andre Przywara wrote:
At the moment we initialise the target *mask* of a virtual IRQ to the
VCPU it belongs to, even though this mask is only defined for GICv2 and
quickly runs out of bits for many GICv3 guests.
This behaviour triggers an UBSAN complaint for more than 32
On 21/08/2019 18:01, Julien Grall wrote:
> Hi Andre,
>
> On 21/08/2019 18:00, Andre Przywara wrote:
>> At the moment we initialise the target *mask* of a virtual IRQ to the
>> VCPU it belongs to, even though this mask is only defined for GICv2 and
>> quickly runs out of bits for many GICv3
Hi Andre,
On 21/08/2019 18:00, Andre Przywara wrote:
At the moment we initialise the target *mask* of a virtual IRQ to the
VCPU it belongs to, even though this mask is only defined for GICv2 and
quickly runs out of bits for many GICv3 guests.
This behaviour triggers an UBSAN complaint for more
At the moment we initialise the target *mask* of a virtual IRQ to the
VCPU it belongs to, even though this mask is only defined for GICv2 and
quickly runs out of bits for many GICv3 guests.
This behaviour triggers an UBSAN complaint for more than 32 VCPUs:
--
[ 5659.462377] UBSAN: Undefined
