From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from zen.linaroharston ([185.81.254.11]) by smtp.gmail.com with ESMTPSA id l18-20020a05600c27d200b003b4868eb6bbsm13450608wmb.23.2022.09.26.08.08.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Sep 2022 08:08:10 -0700 (PDT) Received: from zen (localhost [127.0.0.1]) by zen.linaroharston (Postfix) with ESMTP id 3939E1FFB7; Mon, 26 Sep 2022 16:08:10 +0100 (BST) References: <20220926133904.3297263-1-alex.bennee@linaro.org> <20220926133904.3297263-6-alex.bennee@linaro.org> User-agent: mu4e 1.9.0; emacs 28.2.50 From: Alex =?utf-8?Q?Benn=C3=A9e?= To: Peter Maydell Cc: qemu-devel@nongnu.org, f4bug@amsat.org, mads@ynddal.dk, qemu-arm@nongnu.org, Richard Henderson Subject: Re: [PATCH v2 05/11] hw/intc/gic: use MxTxAttrs to divine accessing CPU Date: Mon, 26 Sep 2022 16:06:34 +0100 In-reply-to: Message-ID: <87leq641id.fsf@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-TUID: zSB1RbAtIJ25 Peter Maydell writes: > On Mon, 26 Sept 2022 at 14:39, Alex Benn=C3=A9e = wrote: >> >> Now that MxTxAttrs encodes a CPU we should use that to figure it out. >> This solves edge cases like accessing via gdbstub or qtest. >> >> Reviewed-by: Richard Henderson >> Signed-off-by: Alex Benn=C3=A9e >> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/124 >> >> --- >> v2 >> - update for new field >> - bool asserts >> --- >> hw/intc/arm_gic.c | 39 ++++++++++++++++++++++----------------- >> 1 file changed, 22 insertions(+), 17 deletions(-) >> >> diff --git a/hw/intc/arm_gic.c b/hw/intc/arm_gic.c >> index 492b2421ab..d907df3884 100644 >> --- a/hw/intc/arm_gic.c >> +++ b/hw/intc/arm_gic.c >> @@ -56,17 +56,22 @@ static const uint8_t gic_id_gicv2[] =3D { >> 0x04, 0x00, 0x00, 0x00, 0x90, 0xb4, 0x2b, 0x00, 0x0d, 0xf0, 0x05, 0= xb1 >> }; >> >> -static inline int gic_get_current_cpu(GICState *s) >> +static inline int gic_get_current_cpu(GICState *s, MemTxAttrs attrs) >> { >> - if (!qtest_enabled() && s->num_cpu > 1) { >> - return current_cpu->cpu_index; >> - } >> - return 0; >> + /* >> + * Something other than a CPU accessing the GIC would be a bug as >> + * would a CPU index higher than the GICState expects to be >> + * handling >> + */ >> + g_assert(attrs.requester_type =3D=3D MEMTXATTRS_CPU); >> + g_assert(attrs.requester_id < s->num_cpu); > > Would it be a QEMU bug, or a guest code bug ? If it's possible > for the guest to mis-program a DMA controller to do a read that > goes through this function, we shouldn't assert. (Whether that > can happen will depend on how the board/SoC code puts together > the MemoryRegion hierarchy, I think.) Most likely a QEMU bug - how would a DMA master even access the GIC? > > thanks > -- PMM --=20 Alex Benn=C3=A9e