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: 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 -- 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/e75c66bb-048e-15d3-1a74-075829c9b2d4%40siemens.com.
