On Tue, 7 Jan 2025 at 19:26, Philippe Mathieu-Daudé <phi...@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: > https://lore.kernel.org/qemu-devel/05820c9b-a683-4eb4-a836-e97aa708d...@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
