[Openamp-rp] Re: [OpenAMP-RP][RFC] Enable RPMsg endpoint recovery on existing RPMsg channel

Hi Ben,

Thanks for your description! Please find in line few questions /comments based on my first understanding.

ST Restricted

-----Original Message----- From: ben levinsky via Openamp-rp <openamp- rp@lists.openampproject.org> Sent: jeudi 21 avril 2022 00:29 To: openamp-rp@lists.openampproject.org Subject: [Openamp-rp] [OpenAMP-RP][RFC] Enable RPMsg endpoint recovery on existing RPMsg channel

Hi All,

As stated in a previous OpenAMP meeting, there was the use case of either the remote or host attempting to re-establish connection if one side goes down.

A proposal for this is as follows:

Changes to existing structures:

1.Add a new feature to the bitmap for VirtIO RPMsg with a name like "VIRTIO_RPMSG_F_RECOVERY" and an extra bit here

2. Add a 2 bit field to struct rpmsg_device and struct fw_rsc_vdev to

denote if recovery functionality is supported and/or active that can have the following

Changing fw_rsc_vdev struct probably means resource table Version 2

3 values:

• 0 - recovery not supported

• 1 - recovery supported but RPMsg endpoint reconnection is not yet

allowed.

• 2 - recovery supported and RPMsg endpoint reconnection is allowed.

Changes to host's resource table parsing:

When a host parses the resource table of the remote processor, check if recovery feature is set and update the vdev's features accordingly.

Changes to host's endpoint creation:

1. First setup, set struct fw_rsc_vdev reovery flag to "recovery

supported but reconnection is not yet allowed"

2. After initial endpoint creation is successful, set recovery flag in

resource table's instance of the struct fw_rsc_vdev to "reconnection allowed" and set resource table's copy of the rpmsg_vdev so that the recovery field denotes reconnection is allowed

3. If recovery is fully setup then upon subsequent host endpoint

creation

            a. host will not re-initialize virtqueues

Virtqueue is a local structure that can be dynamically allocated, how to preserve it? you also need to reparse the resources table to remap the shared resource and the rpmsg buffers, Right?

            b. if rpmsg address is already set, do not error out

No clear, could you detail this point? Which layer oversees storing local endpoint before the crash and where to store them?

            c. unlock rdev virtqueue lock so that messages can 

send again

- When virtqueue lock occurs ? - How do you differentiate channels that will need to be reinitialized with ones that can re-connect? - how do you manage queued RPMSg buffers for reinitialization vs re-connection - how to handle Linux mechanism based on NS announcement to probe the rpmsg device? - how to release RPMsg buffer gotten from the vring used or available list just before the crash.

Regarding your description I also wonder if there is a synergy with the flow control signaling [1].

[1] https://lkml.org/lkml/2022/1/18/867

Thanks, Arnaud

Changes to remote's endpoint creation:

2. If recovery is fully setup then the following changes apply:

            a. remote will not wait for virtqueues' initialization 
   

by host

            b. if rpmsg address is already set, do not error out

            c. unlock rdev virtqueue lock so that messages can 

send again

Changes to rpmsg-send:

None. The virtqueue lock is opened upon endpoint re-connection.

Kind Regards,

Ben