starred/qemu
1
0
Fork 0
mirror of https://github.com/qemu/qemu.git synced 2026-02-04 05:35:39 +00:00
Code Issues 380 Packages Projects Releases Wiki Activity

[PR #290] Ivshmem cxl #395

New Issue
Open
opened 2026-01-31 21:31:05 +00:00 by claunia · 0 comments
claunia commented 2026-01-31 21:31:05 +00:00
Owner
Copy Link

Original Pull Request: https://github.com/qemu/qemu/pull/290

State: closed
Merged: No

A functioning server/client which can concurrently service (read/write) from shared memory. We also have memory allocation, freeing of said memory.

An abstraction for the CXL SHM -> QEMU Emulation -> Server/Client on top of the QEMU connection. A next step is preparing for the actual CXL interface.

Our components are:

CXL Switch Device

This is a QEMU device which is in charge of intercepting memory ops from the userspace on the mapped memory (BAR) from the exposed device. It also maintains a mapping of channels. (This is the undesirable part, as we are leaking abstraction. Ideally in the actual interface, we might have this done elsewhere)

CXL Device Driver

The kernel device driver is in charge of exposing the device to the VM and letting it open, mmap and provides the ISR for the polling of events.

Fabric Manager

Essentially the software that shud run on the actual CXL Switch, acting as a fabric manager which allocates from its memory devices, servicing read/write requests (replication/read from healthy replica).

Server and Client

Abstractions over the CXL Connection. Currently do not support the RPC functionality, but shud have sufficient functionality to handle generic read/writes operations. They properly handle their resources and account for closures/disconnects.

**Original Pull Request:** https://github.com/qemu/qemu/pull/290 **State:** closed **Merged:** No --- A functioning server/client which can concurrently service (read/write) from shared memory. We also have memory allocation, freeing of said memory. An abstraction for the CXL SHM -> QEMU Emulation -> Server/Client on top of the QEMU connection. A next step is preparing for the actual CXL interface. Our components are: ## CXL Switch Device This is a QEMU device which is in charge of intercepting memory ops from the userspace on the mapped memory (BAR) from the exposed device. It also maintains a mapping of channels. (This is the undesirable part, as we are leaking abstraction. Ideally in the actual interface, we might have this done elsewhere) ## CXL Device Driver The kernel device driver is in charge of exposing the device to the VM and letting it open, mmap and provides the ISR for the polling of events. ## Fabric Manager Essentially the software that shud run on the actual CXL Switch, acting as a fabric manager which allocates from its memory devices, servicing read/write requests (replication/read from healthy replica). ## Server and Client Abstractions over the CXL Connection. Currently do not support the RPC functionality, but shud have sufficient functionality to handle generic read/writes operations. They properly handle their resources and account for closures/disconnects.
claunia added the pull-request label 2026-01-31 21:31:05 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
pull-request
Mirrored from GitHub Pull Request
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/qemu#395
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?