search for: rpmsg_ns_msg

...^~~~~~~~~ > In file included from drivers/rpmsg/virtio_rpmsg_bus.c:28: > ./include/linux/virtio_rpmsg.h:21:8: note: originally defined here > 21 | struct rpmsg_hdr { > | ^~~~~~~~~ > drivers/rpmsg/virtio_rpmsg_bus.c:109:8: error: redefinition of 'struct > rpmsg_ns_msg' > 109 | struct rpmsg_ns_msg { > | ^~~~~~~~~~~~ > In file included from drivers/rpmsg/virtio_rpmsg_bus.c:28: > ./include/linux/virtio_rpmsg.h:42:8: note: originally defined here > 42 | struct rpmsg_ns_msg { > | ^~~~~~~~~~~~ > Hmm more confli...

...this header. > > - */ > > -struct rpmsg_hdr { > > - __virtio32 src; > > - __virtio32 dst; > > - __virtio32 reserved; > > - __virtio16 len; > > - __virtio16 flags; > > - u8 data[]; > > -} __packed; > > - > > -/** > > - * struct rpmsg_ns_msg - dynamic name service announcement message > > - * @name: name of remote service that is published > > - * @addr: address of remote service that is published > > - * @flags: indicates whether service is created or destroyed > > - * > > - * This message is sent across...

Hi, Next update: v6: - rename include/linux/virtio_rpmsg.h -> include/linux/rpmsg/virtio.h v5: - don't hard-code message layout v4: - add endianness conversions to comply with the VirtIO standard v3: - address several checkpatch warnings - address comments from Mathieu Poirier v2: - update patch #5 with a correct vhost_dev_init() prototype - drop patch #6 - it depends on a different

Hi, Next update: v6: - rename include/linux/virtio_rpmsg.h -> include/linux/rpmsg/virtio.h v5: - don't hard-code message layout v4: - add endianness conversions to comply with the VirtIO standard v3: - address several checkpatch warnings - address comments from Mathieu Poirier v2: - update patch #5 with a correct vhost_dev_init() prototype - drop patch #6 - it depends on a different

...; > > > - __virtio32 dst; > > > > - __virtio32 reserved; > > > > - __virtio16 len; > > > > - __virtio16 flags; > > > > - u8 data[]; > > > > -} __packed; > > > > - > > > > -/** > > > > - * struct rpmsg_ns_msg - dynamic name service announcement message > > > > - * @name: name of remote service that is published > > > > - * @addr: address of remote service that is published > > > > - * @flags: indicates whether service is created or destroyed > > > > - * &g...

v2: - remove "default n" from Kconfig - drop patch #6 - it depends on a different patch, that is currently an RFC - update patch #5 with a correct vhost_dev_init() prototype Linux supports RPMsg over VirtIO for "remote processor" /AMP use cases. It can however also be used for virtualisation scenarios, e.g. when using KVM to run Linux on both the host and the guests. This

Linux supports RPMsg over VirtIO for "remote processor" /AMP use cases. It can however also be used for virtualisation scenarios, e.g. when using KVM to run Linux on both the host and the guests. This patch set adds a wrapper API to facilitate writing vhost drivers for such RPMsg-based solutions. The first use case is an audio DSP virtualisation project, currently under development,

Linux supports RPMsg over VirtIO for "remote processor" /AMP use cases. It can however also be used for virtualisation scenarios, e.g. when using KVM to run Linux on both the host and the guests. This patch set adds a wrapper API to facilitate writing vhost drivers for such RPMsg-based solutions. The first use case is an audio DSP virtualisation project, currently under development,

v3: - address several checkpatch warnings - address comments from Mathieu Poirier v2: - update patch #5 with a correct vhost_dev_init() prototype - drop patch #6 - it depends on a different patch, that is currently an RFC - address comments from Pierre-Louis Bossart: * remove "default n" from Kconfig Linux supports RPMsg over VirtIO for "remote processor" /AMP use cases.

v3: - address several checkpatch warnings - address comments from Mathieu Poirier v2: - update patch #5 with a correct vhost_dev_init() prototype - drop patch #6 - it depends on a different patch, that is currently an RFC - address comments from Pierre-Louis Bossart: * remove "default n" from Kconfig Linux supports RPMsg over VirtIO for "remote processor" /AMP use cases.

Hi, Next update: v7: - remove documentation update to be send separately - address comments from Mathieu Poirier (thanks) v6: - rename include/linux/virtio_rpmsg.h -> include/linux/rpmsg/virtio.h v5: - don't hard-code message layout v4: - add endianness conversions to comply with the VirtIO standard v3: - address several checkpatch warnings - address comments from Mathieu Poirier v2:

Hi, Next update: v7: - remove documentation update to be send separately - address comments from Mathieu Poirier (thanks) v6: - rename include/linux/virtio_rpmsg.h -> include/linux/rpmsg/virtio.h v5: - don't hard-code message layout v4: - add endianness conversions to comply with the VirtIO standard v3: - address several checkpatch warnings - address comments from Mathieu Poirier v2:

...olutions. The first use case is an > > audio DSP virtualisation project, currently under development, ready > > for review and submission, available at > > https://github.com/thesofproject/linux/pull/1501/commits > > Mathieu pointed me your series. On my side i proposed the rpmsg_ns_msg > service[1] that does not match with your implementation. > As i come late, i hope that i did not miss something in the history... > Don't hesitate to point me the discussions, if it is the case. Well, as you see, this is a v6 only of this patch set, and apart from it there have bee...

...olutions. The first use case is an > > audio DSP virtualisation project, currently under development, ready > > for review and submission, available at > > https://github.com/thesofproject/linux/pull/1501/commits > > Mathieu pointed me your series. On my side i proposed the rpmsg_ns_msg > service[1] that does not match with your implementation. > As i come late, i hope that i did not miss something in the history... > Don't hesitate to point me the discussions, if it is the case. Well, as you see, this is a v6 only of this patch set, and apart from it there have bee...

...rs for such RPMsg-based solutions. The first use case is an > audio DSP virtualisation project, currently under development, ready > for review and submission, available at > https://github.com/thesofproject/linux/pull/1501/commits Mathieu pointed me your series. On my side i proposed the rpmsg_ns_msg service[1] that does not match with your implementation. As i come late, i hope that i did not miss something in the history... Don't hesitate to point me the discussions, if it is the case. Regarding your patchset, it is quite confusing for me. It seems that you implement your own protocol on...

...> audio DSP virtualisation project, currently under development, ready > > > > for review and submission, available at > > > > https://github.com/thesofproject/linux/pull/1501/commits > > > > > > Mathieu pointed me your series. On my side i proposed the rpmsg_ns_msg > > > service[1] that does not match with your implementation. > > > As i come late, i hope that i did not miss something in the history... > > > Don't hesitate to point me the discussions, if it is the case. > > > > Well, as you see, this is a v6 only of...

...> audio DSP virtualisation project, currently under development, ready > > > > for review and submission, available at > > > > https://github.com/thesofproject/linux/pull/1501/commits > > > > > > Mathieu pointed me your series. On my side i proposed the rpmsg_ns_msg > > > service[1] that does not match with your implementation. > > > As i come late, i hope that i did not miss something in the history... > > > Don't hesitate to point me the discussions, if it is the case. > > > > Well, as you see, this is a v6 only of...

...*name, > > + unsigned int src) > > +{ > > + struct vhost_rpmsg_iter iter = { > > + .rhdr = { > > + .src = 0, > > + .dst = RPMSG_NS_ADDR, > > + .flags = RPMSG_NS_CREATE, /* rpmsg_recv_single() */ > > + }, > > + }; > > + struct rpmsg_ns_msg ns = { > > + .addr = src, > > + .flags = RPMSG_NS_CREATE, /* for rpmsg_ns_cb() */ > > + }; > > I think it would be worth mentioning that someone on the guest side needs to > call register_virtio_device() with a vdev->id->device == VIRTIO_ID_RPMSG, > something...

Hi, Now that virtio-rpmsg endianness fixes have been merged we can proceed with the next step. v4: - add endianness conversions to comply with the VirtIO standard v3: - address several checkpatch warnings - address comments from Mathieu Poirier v2: - update patch #5 with a correct vhost_dev_init() prototype - drop patch #6 - it depends on a different patch, that is currently an RFC -

Hi, Now that virtio-rpmsg endianness fixes have been merged we can proceed with the next step. v4: - add endianness conversions to comply with the VirtIO standard v3: - address several checkpatch warnings - address comments from Mathieu Poirier v2: - update patch #5 with a correct vhost_dev_init() prototype - drop patch #6 - it depends on a different patch, that is currently an RFC -