On 9/11/2026 11:19 PM, Taylor Simpson wrote:
>
>
> On Fri, Sep 11, 2026 at 8:34 PM Brian Cain
> <brian.cain@oss.qualcomm.com> wrote:
>
>
> On 9/11/2026 5:08 PM, Taylor Simpson wrote:
> > Currently, we check for register multiwrites during packet
> decode. The
> > downside of this approach is that it only checks a single
> destination
> > register for each instruction. During analyze_packet, we can check
> > for more than one write per instruction. Further, we can check for
> > different types of registers. This series adds checks for HVX
> > v-registers and q-registers.
> >
> > Note that multiple writes to a predicate register are allowed on
> Hexagon.
> >
> > Changes in v2
> > - Rebase against latest sources, including Hexagon system mode
> > - Add checks for multiple writes to system registers
> >
> > Taylor Simpson (10):
> > Hexagon (target/hexagon) Move code out of gen_start_packet
> > Hexagon (target/hexagon) Check for GPR multiwrite in
> analyze_packet
> > Hexagon (tests/tcg/hexagon) Add tests for multi-destination
> > instructions
> > Hexagon (target/hexagon) Check for vreg multiwrite in
> analyze_packet
> > Hexagon (tests/tcg/hexagon) Add tests for vreg multiple writes
> > Hexagon (target/hexagon) Check for qreg multiwrite in
> analyze_packet
> > Hexagon (tests/tcg/hexagon) Add tests for qreg multiple writes
> > Hexagon (target/hexagon) Check for greg multiwrite in
> analyze_packet
> > Hexagon (target/hexagon) Check for sreg multiwrite in
> analyze_packet
> > Hexagon (target/hexagon) Remove old way of detecting register
> > multiwrites
>
> The greg multiwrite change seems to have an issue here.
> clear_pkt_ctx()
> needs to clear gregs_multi_write?
>
> You can reproduce the test failures locally with `make
> check-functional`.
>
>
> Correct. There are problems with both gregs and sregs. I'll make the
> fixes in V3
>
> Should I add a multi-write test to check-functional? If so, please
> advise on the easiest way to do this.
>
If you like, that's fine. Thankfully the existing tests were able to
catch it. IMO tests that are able to build and run with little or no
dependence on hw device models are suitable/appropriate for check-tcg
tests. In system mode, we can write baremetal tests that fit this
description, and the sreg/guest reg tests seem like they could work
well. But it's a bit inconvenient to write the baremetal tests, so I'll
leave it up to you. If you prefer to have the multiwrite tests come
from downloaded-binary cases that run in check-functional, you can
contribute a PR to https://github.com/qualcomm/qemu-hexagon-testing/ to
add test case(s), we can tag that change once it lands and then we can
refer to them in tests/functional/hexagon/ (probably test_systests.py).
But neither of those options needs to gate this commit series.
BTW here is an example sysemu check-tcg test that focuses on translation
and manages to avoid a hardware dependency -
https://lore.kernel.org/qemu-devel/20260717214534.1203949-3-brian.cain@oss.qualcomm.com/
-- it's not landed yet, unfortunately.
-Brian