Question about gdb expectations on SME ZA storage

Hi,

I am developing a patch for QEMU which would allow QEMU to expose
SME registers, such as the ZA storage, via is gdbstub to a remote
gdb client session.

The change that I have suggested and the discussion regarding it
can be found here:

https://lists.gnu.org/archive/html/qemu-devel/2025-08/msg00716.html
https://lists.gnu.org/archive/html/qemu-devel/2025-08/msg00733.html
https://lists.gnu.org/archive/html/qemu-devel/2025-08/msg00748.html
https://lists.gnu.org/archive/html/qemu-devel/2025-08/msg00749.html

The main issue I was facing was that when we attempt to set the
value of the za register, and the gdb client sends out a P packet
as large as the entire za register, the gdb client gets stuck and
doesn't return a prompt, until the timeout is hit.

My understanding is that the current implementation of QEMU, which is
similar to the sample stub code provided in sparc-stub.c, has too small
a value for MAX_PACKET_LENGTH (analogous to BUFMAX from sparc-stub.c).
Due to this, when the stub has read MAX_PACKET_LENGTH bytes without
having hit a checksum, it resets the state machine and begins waiting
for the beginning of a command again, as is the case in the sparc
example provided in gdb. Thus, I have found that appropriately increasing
the value of MAX_PACKET_LENGTH to encompass the full size of the za storage
resolves this issue.

However, there is discussion as to whether there is an underlying issue
of something like not indicating to the gdb client that there is more data
and it must be requested. This discussion can be found at the link provided
above.

So, I was hoping to get some guidance on how gdb expects the SME ZA storage
to be handled and if any of the above mentioned approaches would be
appropriate for a gdbstub to handle the SME ZA storage.

Thank you!


-Vacha