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 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
b. if rpmsg address is already set, do not error out
c. unlock rdev virtqueue lock so that messages can send again
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
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 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
b. if rpmsg address is already set, do not error out
c. unlock rdev virtqueue lock so that messages can send again
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