Skip to content

More cherry picks#295

Merged
arichardson merged 13 commits intoCTSRD-CHERI:devfrom
arichardson:more-cherry-picks
Nov 10, 2025
Merged

More cherry picks#295
arichardson merged 13 commits intoCTSRD-CHERI:devfrom
arichardson:more-cherry-picks

Conversation

@arichardson
Copy link
Member

No description provided.

martin-kaiser and others added 13 commits November 8, 2025 11:31
Add the cbo instructions to the risc-v disassembly code. Distinguish
between cheri and non-cheri versions.

The cbo instructions do not use of the standard R, I, S or U-type
formats. They have a single input register and no outputs.

Define a new codec to parse the input register number. It can be used for
integer and capability registers.

Define two formats to display the register name. We need different
formats for integer and capability register names.
Move the capability print macros inside the big #ifdef TARGET_CHERI.

The macros for printing capability fields will be used only when cheri is
enabled. If they're defined under #ifdef TARGET_CHERI, the macros can use
cheri-specific functions and constants.
When the guest system's pc/pcc points to arbitrary memory, it's unlikely
that it contains a valid instruction. Qemu will then raise an "illegal
instruction" exception. If no exception handler is installed, jumping
into the handler causes yet another exception. This cannot be handled
either, we're stuck in an endless loop of exceptions.

If instruction logging is enabled, csr changes are logged for each
exception. Eventually, this will consume all available memory and qemu
will crash.

This patch tries to detect an endless exception loop. In this case, we
show a one-time error message and stop the csr logging to prevent the
crash.

The criteria for an endless exception loop is that the pc/pcc of the
exception handler is identical to the current one. In other words: The
exception handler is the exact same place that caused the exception we're
trying to handle. Additionally, the reason for the exception must be
related to instruction loading. Then we know up front that this will fail
again for the same reason.

We do the endless loop detection only for M-mode. It aims at simple
assembler snippets that are loaded at the wrong address or jump into the
wild. If the guest software delegates traps to S-mode, it's likely that
it configured proper handlers.
`info registers` now shows the extendex CSRs (with a c suffix for now).
The trap handlers always need to access privileged CSRs so this is a bug.
The vs predicate is aimed at use in the csr read/write functions to
determine if a CSR register can be written based on the presences of the
V extension. If the V extension is present this function returns the
RISCV_EXCP_NONE value.
This is based on an outdated version of the V extension which had the
vector CSR control bits as part of the FCSR register. We fix this in a
way consistent with the vector implementation that is in place knowing
it will be dropped when rebasing
cheri-remergify-drop
Fix a deadlock when qemu updates the clipboard contents for a connected
vnc client but this client is already gone.

The problem can be reproduced as follows:

- Run qemu -serial mon:stdio -vnc :0 with any guest software that outputs
  text on the serial console.

- Connect to qemu's vnc server with a vnc client that supports clipboard
  from server to client.

- Select some text in the serial console.

- Kill the vnc client's window.

- qemu hangs

The problem is that qemu clears the clipboard selection and sends an
update (empty clipboard) to the client. It waits until the client is
ready to receive data. This causes a deadlock as the client has already
been killed.

Fix this by not sending the clipboard update if the vnc client is being
disconnected.
The J extension (pointer masking) seems to be in conflict with cheri, at
least with capability pointer mode.

As we do not need the J extension for Codasip CPUs, the easiest option is
to fail if both J and cheri are selected.
Add the properties to the A730 configuration for the extensions
currently supported in qemu.
Whilst debugging some PTE issues we found that using the MMU log was quite useful. So here we add a log message where it was missing and implement a PTE decode logging function.
@arichardson arichardson merged commit df256e4 into CTSRD-CHERI:dev Nov 10, 2025
50 of 51 checks passed
@arichardson arichardson deleted the more-cherry-picks branch November 10, 2025 16:25
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants