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
_______________________________________________
l4-hackers mailing list -- l4-hackers@os.inf.tu-dresden.de
To unsubscribe send an email to l4-hackers-leave@os.inf.tu-dresden.de