Re: [PATCH v1 3/9] hw/intc/gic: use MxTxAttrs to divine accessing CPU

["Alex Bennée" <alex.bennee@linaro.org>]

mads@ynddal.dk writes:

>> On 22 Sep 2022, at 16.58, Alex Bennée <alex.bennee@linaro.org> 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.
>> 
>> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>> 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..b58d3c4a95 100644
>> --- a/hw/intc/arm_gic.c
>> +++ b/hw/intc/arm_gic.c
>> @@ -56,17 +56,22 @@ static const uint8_t gic_id_gicv2[] = {
>>     0x04, 0x00, 0x00, 0x00, 0x90, 0xb4, 0x2b, 0x00, 0x0d, 0xf0, 0x05, 0xb1
>> };
>> 
>> -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_is_cpu);
>> +    g_assert(attrs.cpu_index < s->num_cpu);
>> +
>> +    return attrs.requester_id;
>> }
>
> The asserts here abort on macOS, with HVF accelerator:
>
> ERROR:../hw/intc/arm_gic.c:66:gic_get_current_cpu: assertion failed: (attrs.requester_is_cpu)
> Bail out! ERROR:../hw/intc/arm_gic.c:66:gic_get_current_cpu: assertion failed: (attrs.requester_is_cpu)
>
> If I revert the changes inside this function, it seemingly works
> again.

Thanks for testing.

I guess this is because the we have a soft GIC for HVF. Somewhere in the
hvf code path we must encode up an MemTxAttrs when the gic is accessed.

Could you try in the EC_DATAABORT path in
target/arm/hvf/hvf.c:hvf_vcpu_exec:

        if (iswrite) {
            val = hvf_get_reg(cpu, srt);
            address_space_write(&address_space_memory,
                                hvf_exit->exception.physical_address,
                                MEMTXATTRS_CPU(cpu->cpu_index), &val, len);
        } else {
            address_space_read(&address_space_memory,
                               hvf_exit->exception.physical_address,
                               MEMTXATTRS_CPU(cpu->cpu_index), &val, len);
            hvf_set_reg(cpu, srt, val);
        }

if that works I'll cook up a proper patch.

-- 
Alex Bennée