On 27/05/20 8:45 pm, Jan Kiszka wrote:
On 27.05.20 16:55, Nikhil Devshatwar wrote:
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
Still not sure if we are on the page, but maybe we are thinking about
different scenarios.
Is your desire to allow a full demo (interrupts seen on both ends) with
only two of 3 peers running?
Yes, exactly. The 2nd peer can be either linux-demo or baremetal.
Depending on which one it is, you will have to pass separate ID for
sending interrupt.
Or is it about permitting > 3 peers? The
No
demo setup is currently like that:
- root cell running with ivshmemo-demo app
- non-root cell running with baremetal ivshmemo-demo
- non-root linux cell running with ivshmemo-demo app
If one is missing, one signalling stimulus is missing and one signalling
reporter. But if you run them all, you can see that everything is fine.
Regards,
Nikhil D
> 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/880c56be-a9cc-8afa-c1e7-1ecefbe99694%40ti.com.
