Second VirtIO access cause vm fault

After the first access (read or write) to a VirtIO device, the following failure appears after new retyping of memory and further (read or write) e.g., while accessing the second VirtIo device.

vm fault on data at address 0x207800 with status 0x92000010
in thread 0x807fe49400 "rootserver" at address 0x350104

How to identify the failure and/ or resolve it? Many thanks in advance for the support.

Seems that address 0x207800 is not pointing to mapped memory. Can you confirm that page 0x207000 is properly mapped in the rootserver’s address space?

You can run gdb on the rootserver binary and disassemble address 0x350104 to see what instruction triggers the fault, but it’s probably the first access to that page.

@Indan many thanks for your feedback. I belief yes. I added my small code in the following issue https://sel4.discourse.group/t/rust-call-cause-vm-fault-on-data-at-address/865/13

I’d suggest adding more debug prints to show what device memory regions you actually map and compare that to what you’re expected.

Output dump added

https://sel4.discourse.group/t/rust-call-cause-vm-fault-on-data-at-address/865/13

Which further info could support/

I don’t see any print saying that memory region is being mapped, so look into that first.

@Indan Maybe i got it.

The following trace:

ALLOC Page 4 2125824 
Caught cap fault in send phase at address 0
while trying to handle:
vm fault on data at address 0x207800 with status 0x92000010
in thread 0x807fe49400 "rootserver" at address 0x35048c
With stack:
0x39ec20: 0x39ebd0

results in:

0x207800 is 2127872

The page starts at 2125824 with size of 512. The end is 2126336. This is below 2127872.

This would mean, that the given device tree is wrong. It tells me, that the size is 512.

I am right?

@Indan I tried 4096 instead of 512, but it does not work as expected :frowning:

Depends on what that region is whether device tree is wrong or not.

You can only map 4k aligned memory addresses with at least 4k size.

But if it’s random device memory you are accessing, then the hardware itself may not be happy with reading random parts of it, that can fault for e.g. write-only registers.