Hi Stephen, not sure my understanding is right, you want a small piece of the guest's memory to be shared with another L4Re program? One way to do this is to give the VM multiple dataspaces as its memory and share one of those dataspaces with the application. uvmm supports giving multiple dataspaces to a VM. Inside the VM the device tree tells where the memory is. The driver inside the VM needs to be aware of that split and act accordingly. Sharing just a part of a dataspace is indeed not possible as no such functionality exists. BR, Adam On Sun Apr 26, 2026 at 13:18:05 +0800, stephen.yang wrote:
Hi Adam, Your point is well taken. It is not feasible to disable forced mapping simply based on this example. First, this address offset cannot be obtained directly, as no relevant interface is provided. The same physical memory region perceived by the guest and the host actually corresponds to different addresses on each side. Second, even if this offset were accessible, it would allow the virtual device to access the entire system memory space, which poses significant security risks to the system. Therefore, the approach shown in this example is not viable in practice. Nevertheless, this discussion has deepened my understanding of the L4Re framework and virtualization technologies. Thank you again for your reply.
BR，Stephen
At 2026-04-22 12:59:29, "Adam Lackorzynski" <adam@l4re.org> wrote:
Hi Stephen,
great it is working for you now. All the addresses in a virtualization setup can be indeed confusing. With a virtual device using memory of the VM, the virtual device needs to know about the guest physical mapping, or better the mapping of the dataspace into the VMs guest physical space. -i can make this a bit easier but it's really just a workaround.
Adam
On Sat Apr 18, 2026 at 14:22:16 +0800, stephen.yang wrote:
Hi Adam, Thank you very much for your reply and suggestions. I have tried making changes according to your recommendations, but they did not seem to take effect. However, I have discovered something interesting: when disabling forced mapping and using the method I mentioned in my previous email, the virtual device is able to read the content that the kernel writes to that address range. As described in the documentation£º -i, --ram-identity-mapping When set, the option forces the guest RAM to be mapped to its corresponding host-physical addresses. Flag. True if provided.
Additionally, I found that even with forced mapping enabled, the physical address seen by the guest is different from that seen by the host, with an offset between them.The host sees the address as 0x66200000, while the guest sees it as 0x66400000.Based on the code mentioned earlier, this issue can be resolved simply by accounting for this offset during the mapping process. BR, Stephen