Il mer 21 mag 2025, 10:21 Zhao Liu <zhao1....@intel.com> ha scritto:
> I also realize that once FlatRange/FlatView is associated with
> GuestMemoryRegion/
> GuestMemory, it changes the usual practice in QEMU, where most memory
> operations
> are built around MemoryRegion/AddressSpace.
>
That shouldn't be a problem. In QEMU and vm-memory DMA always starts from
Address space/GuestAddressSpace, not from MemoryRegion, so if QEMU
implements GuestAddressSpace in qemu_api::AddressSpace everything matches
well. The only difference is that Rust code will do something like
AddressSpace::MEMORY::memory().read(...)
(which retrieves the FlatView) instead of
address_space_read(&address_space_memory, ...)
But that's just how the API is defined. It seems good to me. The mismatch
between MemoryRegion and GuestMemoryRegion is confusing, but will be mostly
hidden behind the prelude because Guest* are traits not structs.
> So... not sure what to do there. It seems like vm-memory is very close to
> > being usable by QEMU, but maybe not completely. :(
>
> Is it possible or necessary for vm-memory to support overlap? Because I
> feel that if it is possible, the problem might be simplified. (As a
> beginner, I have yet to understand exactly how difficult it is.)
>
I don't think that's necessary. Just like in QEMU C code we have
AddressSpace for DMA and MemoryRegion for hierarchy, in Rust code you have
qemu_api::{AddressSpace,MemoryRegion}. FlatView, FlatRange,
MemoryRegionSection are hidden in both cases, and users don't care much
about which type implements GuestMemoryRegion because all they see is
AddressSpace. Again, it's all hidden behind the prelude.
The real problem is how hard it is to remove the references from the
vm-memory API... Maybe not much.
Paolo
> Thanks,
> Zhao
>
>
>
