Re: [RFC PATCH] tests/qtest/stm32l4x5_usart: Avoid accessing NVIC via MMIO

[Peter Maydell]

On Tue, 7 Jan 2025 at 19:26, Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
>
> The STM32L4x5 SoC family use a ARM Cortex-M core. Such
> core is architecturally tied with a NVIC (interrupt controller),
> having the NVIC MMIO mapped in the core address space.
>
> When using the QTest accelerator, we don't emulate vCPU, only
> a dummy is created. For now, QTest is only supposed to access
> MMIO devices mapped on the main 'SysBus'. Thus it shouldn't
> be able to access a NVIC MMIO region, because such region is
> specific to a vCPU address space, which isn't available under
> QTest.

This doesn't seem quite right. We create vCPUs which should
have all their usual address spaces (e.g. in the arm code
the calls to cpu_address_space_init() are not guarded by
anything that says "don't do this if qtest"). They just
don't *execute* anything.

qtest's model of operation is "the qtest is doing accesses
as-if it was guest code running on the first CPU in the system".
So it should be fine for it to do accesses which access the
NVIC. (Indeed if we wanted a qtest of the NVIC itself that
should also be OK.)

In a more interesting heterogenous system you probably want
the qtest to be able to select the CPU that it is acting
as-if-it-were (though even then the first one in the system
is usually going to be sensible enough, assuming the
heterogenous board model did the usual thing of creating
the main application CPUs first and the BSP or other
minor processor last). Then you could have a qtest which is
"I'm testing a device that's accessible to the main
application processor" and also one which is "I'm testing
this device which is only accessible to the BSP".

> This patch is to fix the problem reported by Fabiano when
> removing the &first_cpu global in qtest, see analysis in:
> 05820c9b-a683-4eb4-a836-e97aa708d5e5@linaro.org/">https://lore.kernel.org/qemu-devel/05820c9b-a683-4eb4-a836-e97aa708d5e5@linaro.org/

Hmm, OK, so my idea of having qtest use address_space_memory
as a shortcut for getting rid of first_cpu doesn't work.

I'm not super-enthusiastic about this patch, since it's
basically adding an artificial restriction to what you can
do in a qtest. But maybe it's OK as a temporary thing to
avoid going too far down a rabbit hole in refactoring?

If we were going to have the qtest select "this is the
CPU I want to act like", what would it do? Pass a
QOM path to the relevant CPU? I feel like you would
still want to default to "pick the first CPU", because
99% of tests will be fine with that. But maybe we need
to locate the first CPU by some runtime thing rather
than by using the global. IDK...

-- PMM