On 27/05/20 8:18 pm, Jan Kiszka wrote:
On 27.05.20 16:16, Nikhil Devshatwar wrote:
On 27/05/20 7:38 pm, Jan Kiszka wrote:
On 27.05.20 15:53, Nikhil Devshatwar wrote:
On 27/05/20 7:18 pm, Jan Kiszka wrote:
On 27.05.20 15:28, Nikhil Devshatwar wrote:
On 27/05/20 6:41 pm, Jan Kiszka wrote:
On 27.05.20 14:32, [email protected] wrote:
From: Nikhil Devshatwar <[email protected]>
Number of peers available on a platform is different.
Do not hard code the target peer_id used for interrupt.
Parse this from the command line argument.
This de-couples the dependency between number of peers.
ivshmem-demo can be run to communicate with desired target
No command line, please. We can do (<ID> + 1) % <Maximum Peers> as
target. All that is accessible via the register interface. But
then all
I believe, as of now, only root cell can communicate with peer1,
peer2,
etc. Non root cells cannot communicate with each other.
Please correct me if I am wrong.
Not all targets have been enabled for the "triangle" setup, but if you
look at qemu-arm64, e.g., you can see that pattern.
(id + 1)% max_num_peers logic won't work for a 3peer scenario
where
root cell app(id=0) wants to communicate with baremetal(id=2)
e.g. qemu-arm64 has these ids.
Then we need to adjust that. It doesn't matter who sends whom, just
everyone should send something and everyone should receive something in
the end.
In QEMU, root (id = 0) linux-demo(id = 1) and baremetal(id = 2)
0 should be able to to 1 and 2
Here you should choose if you want to communicate with baremetal or
linux-demo. There is no way this can be automatically figured out.
That's why I added an argument.
Every peer can talk to every other peer in those setups.
Oh, that's new to know. Sorry about confusion.
It's just that
the demos are built in a way that each peer has a single notification
target, by convention, not by cell configuration.
But if you can pass the id and communicate with any peer, that seems
better than the limitation that root cell can communicate with only a
certain peer that is described by how the ids are alloted in configs.
Not sure if I get the point already:
In the current qemu-arm64 configuration, It is not possible for root
cell to verify communication with linux-demo and baremetal-demo both.
That's because "the demos are built in a way that each peer has a single
notification"
This is the limitation I am trying to get rid of, by passing an
argument. e.g.
ivshmem-demo /dev/uio0 1 #This will communicate with linux-demo
ivshmem-demo /dev/uio0 2 #This will communicate with baremetal-demo
If you link ivshmem devices by
using the same BDF, there will be no communication restrictions. The ID
allocation is static, to make it stable, but there is no semantic behind
the number. The only constraints: IDs must be unique (obviously) and
must be < than the configured maximum peers.
Jan
--
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/5a7a1e18-93dd-6bb1-8fba-ccfd91f2c8d5%40ti.com.
