Il mer 21 mag 2025, 11:35 Manos Pitsidianakis < manos.pitsidiana...@linaro.org> ha scritto:
> vm-memory is a very rigid API unfortunately. It's excellent for > rust-vmm purposes. I presume it's possible to figure out a clever > solution to satisfy both rust-vmm and QEMU use needs but I'm not sure > it's worth it. It's really hard to retrofit other projects into > vm-memory if they don't use rust-vmm crates API design and it might > make both rust-vmm code and QEMU code more complex. QEMU would depend > on rust-vmm architectural decisions and vice-versa. The thing I'm > fearing most is needing to refactor memory APIs in QEMU in the future > and turn the vm-memory dependency into technical debt. I agree that changing the memory API for the sake of Rust code is a bad idea. That said, I have some hope. vm-memory's GuestAddressSpace was designed for cloud-hypervisor but with QEMU in mind and I was really happy about it. Of course it's easy to screw up and miss details elsewhere (like the difference between FlatRange * and MemoryRegionSection, and consequently the type of the GuestMemory iterator); I am not even sure what QEMU code for IOMMUs looked like in 2018. But it might be salvageable if the rust-vmm guys accept a couple of small API breaks. Perhaps it's more sensible to not use external dependencies to wrap > over our APIs but we can surely design our Rust bindings inspired by > them. > It would be nice to have crates like linux-loader or vm-virtio available. But even then, even if we can fork the basic vm-memory traits, we can get by with it as long as those handy crates still compile. :) Paolo >
