On Thu, Aug 07, 2025 at 04:13:00PM +0200, Paolo Bonzini wrote: > Date: Thu, 7 Aug 2025 16:13:00 +0200 > From: Paolo Bonzini <[email protected]> > Subject: Re: [RFC 00/26] rust/memory: Integrate the vm-memory API from > rust-vmm > > [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.
About Endianness, I have more thoughts in the reply of patch 24. > 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? with iommu support, the downstream patches are not necessary :-). > > 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. Thank you for your quick feedback. > 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...) Yes! For such a single function, there're lots of changes. Thanks, Zhao
