[Adding Hanna who's been working on vm-memory]
On 8/7/25 14:30, Zhao Liu wrote:
Hi,
This RFC series explores integrating the vm-memory API into QEMU's
rust/memory bindings.
Thanks to Paolo and Manos's many suggestions and feedback, I have
resolved many issues over the past few months, but there are still
some open issues that I would like to discuss.
This series finally provides the following safe interfaces in Rust:
* AddressSpace::write in Rust <=> address_space_write in C
- **but only** supports MEMTXATTRS_UNSPECIFIED
* AddressSpace::read in Rust <=> address_space_read_full in C
- **but only** supports MEMTXATTRS_UNSPECIFIED.
* AddressSpace::store in Rust <=> address_space_st{size} in C
- **but only** supports MEMTXATTRS_UNSPECIFIED and native endian.
* AddressSpace::load in Rust <=> address_space_ld{size} in C
- **but only** supports MEMTXATTRS_UNSPECIFIED and native endian.
Endianness can be handled by BeNN and LeNN. For MemTxAttrs we can use
Bytes<(GuestAddress, MemTxAttrs)> (a variant on something you mention
below).
Thinking out loud: maybe if we do our implementation in
Bytes<(GuestAddress, MemTxAttrs)>, and Bytes<GuestAddress>::try_access
wraps Bytes<(GuestAddress, MemTxAttrs)>, your downstream-only changes
are not needed anymore?
And this series involves changes mainly to these three parts:
* NEW QEMU memory APIs wrapper at C side.
* Extra changes for vm-memory (downstream for now).
* NEW QEMU memory bindings/APIs based on vm-memory at Rust side.
Although the number of line changes appears to be significant, more
than half of them are documentation and comments.
Yep, thanks for writing them.
This is a good RFC, it's complete enough to show the challenges and the
things that are missing stand up easily.
I'll look into what vm-memory is missing so that we can simplify QEMU's
code further, but the basic traits match which is nice. And the final
outcome, which is essentially:
let (addr, value) = (GuestAddress(self.fsb >> 32),
Le32(self.fsb as u32));
ADDRESS_SPACE_MEMORY.memory().store(addr, value);
is as clean as it can be, if anything a bit wordy due to the
GuestAddress "newtype" wrapper. (If we decide it's too bad, the
convenience methods in AddressSpace can automatically do the
GuestAddress conversion...)
Paolo
