Re: [PATCH v4 18/18] tests/functional/hexagon: enable more arch_tests cases

On 8/3/2026 8:43 AM, Brian Cain wrote:
> 
> On 7/31/2026 12:42 PM, Pierrick Bouvier wrote:
>> On 7/29/2026 6:28 PM, Brian Cain wrote:
>>> Add more tests from hexagon-arch-tests, enabled by QTimer device.
>>>
>>> These exercise cache maintenance ops, l2vic, thread start/stop, tlb/mmu
>>> operations, and user-mode transitions.
>>>
>>> Signed-off-by: Brian Cain <[email protected]>
>>> ---
>>>   tests/functional/hexagon/test_arch_tests.py | 32 +++++++++++++++++++++
>>>   1 file changed, 32 insertions(+)
>>>
>>> diff --git a/tests/functional/hexagon/test_arch_tests.py b/tests/
>>> functional/hexagon/test_arch_tests.py
>>> index 2bb34f9b8dc..0834398c3b1 100755
>>> --- a/tests/functional/hexagon/test_arch_tests.py
>>> +++ b/tests/functional/hexagon/test_arch_tests.py
>>> @@ -58,6 +58,38 @@ def test_int_steering(self) -> None:
>>>           """
>>>           self.run_uart_test("test_int_steering")
>>>   +    def test_cache(self) -> None:
>>> +        """Tests cache operations: dckill/ickill, l2kill, dczeroa,
>>> +        dccleaninva, cache disable/enable, barriers, and dcinva/
>>> dccleana.
>>> +        """
>>> +        self.run_uart_test("test_cache")
>>> +
>>> +    def test_l2vic(self) -> None:
>>> +        """Tests the L2VIC interrupt controller: enable readback,
>>> +        interrupt type readback, VID capture, and the fast interface.
>>> +        """
>>> +        self.run_uart_test("test_l2vic")
>>> +
>>> +    def test_threads(self) -> None:
>>> +        """Tests hardware thread management: start/stop, MODECTL state,
>>> +        per-thread HTID, shared memory, wait/resume, STID priority, and
>>> +        SCHEDCFG/BESTWAIT readback.
>>> +        """
>>> +        self.run_uart_test("test_threads")
>>> +
>>> +    def test_tlb_mmu(self) -> None:
>>> +        """Tests TLB/MMU operations: write/read/probe/invalidate,
>>> +        global entries, multiple entries, overwrite, ASID matching,
>>> +        and permission checks.
>>> +        """
>>> +        self.run_uart_test("test_tlb_mmu")
>>> +
>>> +    def test_user_mode(self) -> None:
>>> +        """Tests user mode / privilege transitions: supervisor mode,
>>> +        SSR UM/IE/XE/CE/PE bits, and the trap0 user-mode exit handler.
>>> +        """
>>> +        self.run_uart_test("test_user_mode")
>>> +
>>>     if __name__ == "__main__":
>>>       QemuSystemTest.main()
>> A general question on the pattern we have here.
>>
>> If those tests can be compiled with hexagon-cross container, would it
>> make sense to add them to tcg/tests/hexagon/system directly in the
>> future?
>> Hopefully will be more easy once we have meson tcg-tests, so you don't
>> need to add all dependencies by hand.
> 
> 
> Glad you asked -- in a downstream fork, we originally did have several
> tests like these (not these particular ones but ~similar scope) running
> in check-tcg.  But we pivoted away from that because:
> 
> 1. they're not testing merely translation: they depend on several sysemu
> devices.  More like integration/functional testing.
>

That's a fair point. I'm not sure where is the exact border of what we
should/should not exercise through tcg tests.

@Alex: As tcg tests maintainer, do you have on opinion on this?
@Richard: as tcg maintainer, would you consider it as part of tcg test
suite for system mode?

> 2. sometimes it's useful to verify not merely the exit code but also
> some output text to semihost/uart console.  This *can* be done with
> shell programs in make/meson, but it feels like "coloring outside of the
> lines."
>

We can add the necessary wrappers for that. Functional tests are such
programs in some way.

> 3. most other architectures seem to have fairly ~light system emu check-
> tcg tests, perhaps because of #1/2?
> 
> 
> We did this change with the assumption that these sysemu check-tcg tests
> wouldn't be welcomed by community because it diverges from what other
> targets do.  But maybe that was an overreaction?
> 
> It's certainly convenient to have test cases in-project so that changes
> to the tests don't require an indirect step to update a test code repo. 
> So, we can do whatever best conforms to the project idioms in this
> regard.  Note that these particular tests in this patch are written in
> Rust and would introduce a new dependency (in the existing container, I
> suppose) beyond the C/C++ toolchain.  Fine w/me but food for thought.
>

For now, having it outside of QEMU is totally fine, and it doesn't seem
we should move it. We can revisit this in the future.

> 
>>
>> Regards,
>> Pierrick