Linux v6.15 - #4
Open
joaopeixoto13 wants to merge 8 commits into
Open
joaopeixoto13 wants to merge 8 commits into
joaopeixoto13 wants to merge 8 commits into
Conversation
joaopeixoto13
force-pushed
the
linux-v6.15
branch
2 times, most recently
from
February 21, 2026 09:07
cf98b3a to
778b19c
Compare
Signed-off-by: João Peixoto <joaopeixotooficial@gmail.com>
Update I/O dispatcher module with the latest refactor changes due to the ongoing Linux upstream efforts. Signed-off-by: João Peixoto <joaopeixotooficial@gmail.com>
Update IPC shared memory module with the latest refactor changes due to the ongoing Linux upstream efforts. Signed-off-by: João Peixoto <joaopeixotooficial@gmail.com>
…percall inline asm
The inline assembly block for the `ecall` in bao_remio_hypercall()
specified registers a0–a7 as both input ("r") and read-write ("+r")
operands.
Since "+r" already marks the operands as input-output, the additional
input-only constraints are redundant and unnecessary. Removing them
simplifies the constraint list without changing semantics and avoids
potential confusion for future maintainers.
No functional changes intended.
Signed-off-by: João Peixoto <joaopeixotooficial@gmail.com>
…ext fields Initialize client->virtio_requests_lock in bao_io_client_create(). Without explicitly initializing this mutex, the first lock operation can trigger a breakpoint (BKP) exception on RISC-V due to operating on an uninitialized lock structure. Also explicitly initialize ctx.access_width and ctx.npend_req in bao_dispatch_io() before issuing the hypercall. This avoids passing uninitialized stack data to the hypervisor and makes the hypercall context state fully defined. These changes improve robustness and prevent runtime exceptions on RISC-V systems. Signed-off-by: João Peixoto <joaopeixotooficial@gmail.com>
Drop the explicit loop calling bao_dispatch_io() when creating a control client. There is no need to proactively check and drain pending requests at this point. Bao guarantees that the backend VM is notified via an interrupt whenever there are requests to process, even if the frontend initiates the interaction first. As a result, the backend will naturally enter the dispatch path when work is available. Removing this loop simplifies the initialization path and avoids redundant polling without changing behavior. Signed-off-by: João Peixoto <joaopeixotooficial@gmail.com>
joaopeixoto13
force-pushed
the
linux-v6.15
branch
from
February 21, 2026 13:31
778b19c to
2c57c23
Compare
josecm
reviewed
Feb 21, 2026
josecm
left a comment
josecm
left a comment
Member
There was a problem hiding this comment.
Should we also allow for ipc-shmems where there is only a read-channel?
A good idea would be to write the device tree bindings for these modules also.
Comment on lines
+154
to
+164
| ret = of_property_read_u32_index(np, "read-channel", 0, &read_offset); | ||
| if (ret) { | ||
| dev_err(dev, "failed to read 'read-channel' offset: %d\n", ret); | ||
| return ret; | ||
| } | ||
|
|
||
| ret = of_property_read_u32_index(np, "read-channel", 1, &read_size); | ||
| if (ret) { | ||
| dev_err(dev, "failed to read 'read-channel' size: %d\n", ret); | ||
| return ret; | ||
| } |
Member
There was a problem hiding this comment.
Do these consider the case where #address-cells or #size-cells are greater than 1?
| register u32 r5 asm("r5") = ctx->request_id; | ||
| register u32 r6 asm("r6") = 0; | ||
|
|
||
| asm volatile("hvc 0\n\t" |
Member
There was a problem hiding this comment.
Why can't we use arm_smccc_hvc here also?
bao_remio_hypercall() on RISC-V returned a0 -- the SBI error register -- which Bao's SBI extension handler always sets to SBI_SUCCESS. The actual hypercall return code is passed back in the SBI value register (a1). Because the driver returned a0, every hypercall appeared to succeed, so bao_dispatch_io() could never observe a failed ASK. On the ASK failure path (no pending request) the hypervisor returns without writing the output registers, so the driver reads back stale input values -- including a non-zero npend_req. The `while (bao_dispatch_io(dm) > 0)` loop in io_dispatcher() then never terminates, spinning and repeatedly handing the device model a bogus request (addr=2, request_id=2, ...). Interestingly this only manifests with an SMP frontend: the dispatch work item is queued once per frontend notification interrupt, but a single invocation drains *all* currently pending requests via its npend_req loop. With one frontend vCPU, MMIO accesses are strictly serialized (at most one request outstanding), so every dispatch run finds exactly the request it was notified for and an ASK is never issued on an empty queue. With multiple vCPUs, requests and notifications interleave: one invocation can drain a request that a later, already-queued invocation was scheduled for, so that later invocation issues an ASK with nothing pending. With correct error handling this empty ASK is harmless (the loop simply exits); with the a0/a1 bug the failure is invisible and the loop spins forever. Return a1 so callers observe the real HC_E_* code and bail out on failure. The ARM SMCCC path is unaffected: it already returns the value register (x0). Signed-off-by: Kostas Damaskinakis <kostas.damaskinakis@gmail.com>
If a frontend issues an I/O request before the backend's device model is up (e.g. while the backend is still booting), the request stays queued in the hypervisor, but the new-request notification may have been lost if the dispatcher's interrupt source was not configured yet. This happens on interrupt controllers that do not latch pending interrupts for unconfigured sources, such as the RISC-V APLIC, and leads to a deadlock: the frontend stays blocked on the access and the backend is never notified again. Kick a dispatch pass when an io client attaches so any requests that were already queued get drained, mirroring what the io dispatcher resume path already does on client destruction. On controllers that do latch the notification, quash the pending interrupt before asking so the drained requests are not dispatched a second time; requests arriving concurrently re-assert it. Note this relies on a failing ask being visible to the caller, as the queue may well be empty at this point. Signed-off-by: Jose Martins <josemartins90@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.