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