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.
2. Enable the rootcell.
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
5. boot linux-inmate
6. virtio-ivshmem 0000:00:0f.0: backend not ready
7. kernel panic
If I redo the sets 4 and 5 the inmates starts as expected and I can
access the disk.image via /dev/vda.
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?
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/8823c273-a3b9-4719-caa9-6791dd6a01a7%40siemens.com.
