On 10.03.20 16:45, Philipp Rosenberger wrote:
Hi Jan,
On 10.03.20 16:08, Jan Kiszka wrote:
On 10.03.20 15:41, Philipp Rosenberger wrote:
Hi,
I have managed to get virtio-ivshmem console and block running. But I
observed a strange behavior. I do the following:
1. Boot up the board.
devmemdump 0x16f300000 0x1000 | hexdump -C | head
00000000 07 26 8b 17 4d 0f 2e 83 06 26 8a 17 4c 0f 2f a3
00000010 16 ae 9a 97 5c 8f 3f 03 36 97 bc 97 1c 8e 3f 82
2. Enable the rootcell.
devmemdump 0x16f300000 0x1000 | hexdump -C | head -n 2
00000000 00 00 00 00 4d 0f 2e 83 06 26 8a 17 4c 0f 2f a3
00000010 16 ae 9a 97 5c 8f 3f 03 36 97 bc 97 1c 8e 3f 82
3. echo "110a 4106 110a 4106 ffc002 ffffff" > \
/sys/bus/pci/drivers/uio_ivshmem/new_id
4. virtio-ivshmem-block /dev/uio0 /path/to/disk.image
devmemdump 0x16f300000 0x1000 | hexdump -C | head -n 2
00000000 00 00 00 00 4d 0f 2e 83 06 26 8a 17 4c 0f 2f a3
00000010 16 ae 9a 97 5c 8f 3f 03 36 97 bc 97 1c 8e 3f 82
5. boot linux-inmate
6. virtio-ivshmem 0000:00:0f.0: backend not ready
7. kernel panic
devmemdump 0x16f300000 0x1000 | hexdump -C | head -n 2
00000000 00 00 00 00 00 00 00 00 06 26 8a 17 4c 0f 2f a3
00000010 16 ae 9a 97 5c 8f 3f 03 36 97 bc 97 1c 8e 3f 82
If I redo the sets 4 and 5 the inmates starts as expected and I can
access the disk.image via /dev/vda.
repeated step 4:
devmemdump 0x16f300000 0x1000 | hexdump -C | head -n 2
00000000 01 00 00 00 00 00 00 00 06 26 8a 17 4c 0f 2f a3
00000010 16 ae 9a 97 5c 8f 3f 03 36 97 bc 97 1c 8e 3f 82
repeated step 5:
devmemdump 0x16f300000 0x1000 | hexdump -C | head -n 2
00000000 01 00 00 00 01 00 00 00 06 26 8a 17 4c 0f 2f a3
00000010 16 ae 9a 97 5c 8f 3f 03 36 97 bc 97 1c 8e 3f 82
I found, the the virtio-ivshmem-block tool waits for an interrupt if
'state[peer_id] != VIRTIO_STATE_RESET'. But there is no interrupt.
The state memory should be zeroed, provided the peer is not running. You
will only get an interrupt during the peer setup when it switches it
state from (expected) RESET to READY. Maybe we miss some proper
initialization of the shared state memory in Jailhouse.
Can you confirm that the state memory is in a random state on first
startup? And that it changes as expected for the peer to READY once the
non-root Linux boots?
I hope I have done this right. The 'state' is stored in the first
region. In my case '.phys_start = 0x16f300000'.
You can see how the first two 32 bit words change. The devmemdump tool
just maps /dev/mem at the given address and writes it to stdout.
I've tested the following after step 1 and it also worked:
# devmemdump 0x16f300000 0x1000 | hexdump -C | head -n 2
00000000 07 26 8b 17 4d 0f 2e 83 06 26 8a 17 4c 0f 2f 83
00000010 16 a6 9a 97 5c 8f 3f 03 16 a7 9a 96 5c 8e 3f 02
# busybox devmem 0x16f300000 32 0
# busybox devmem 0x16f300004 32 0
# devmemdump 0x16f300000 0x1000 | hexdump -C | head -n 2
00000000 00 00 00 00 00 00 00 00 06 26 8a 17 4c 0f 2f 83
00000010 16 a6 9a 97 5c 8f 3f 03 16 a7 9a 96 5c 8e 3f 02
Yes, your logs look consistent with my theory, and my patch should fix it.
I suppose I tested too often in friendly virtual environments...
Thanks for reporting!
Jan
--
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux
--
You received this message because you are subscribed to the Google Groups
"Jailhouse" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jailhouse-dev/4f564fe0-2d1e-391d-6365-9fe3d1a3221b%40siemens.com.
