search for: vhost_rpmsg_ns_announc

Displaying 20 results from an estimated 27 matches for "vhost_rpmsg_ns_announc".

2020 May 27
0
[PATCH v2 5/5] vhost: add an RPMsg API
...++++++++++++++++++++++++++++++++ > > drivers/vhost/vhost_rpmsg.h | 74 +++++++++ > > 4 files changed, 456 insertions(+) > > create mode 100644 drivers/vhost/rpmsg.c > > create mode 100644 drivers/vhost/vhost_rpmsg.h [snip] > > +/* send namespace */ > > +int vhost_rpmsg_ns_announce(struct vhost_rpmsg *vr, const char *name, > > + unsigned int src) > > +{ > > + struct vhost_rpmsg_iter iter = { > > + .rhdr = { > > + .src = 0, > > + .dst = RPMSG_NS_ADDR, > > + .flags = RPMSG_NS_CREATE, /* rpmsg_recv_single() */ > > +...
2020 May 25
6
[PATCH v2 0/5] Add a vhost RPMsg API
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
2020 Sep 18
0
[PATCH v7 3/3] vhost: add an RPMsg API
...mp;iter->iov_iter); > > + if (tmp != sizeof(iter->rhdr)) { > > + ret = -EIO; > > + goto return_buf; > > + } > > + > > + /* Let the endpoint write the payload */ > > I would specifically mention that namespace payloads are taken care of by > vhost_rpmsg_ns_announce(). That makes it easier for people to connect the dots. Ok > > + if (iter->ept && iter->ept->write) { > > + ret = iter->ept->write(vr, iter); > > + if (ret < 0) > > + goto return_buf; > > + } > > + > > + break; >...
2020 Sep 10
0
[PATCH v7 3/3] vhost: add an RPMsg API
..._GPL(vhost_rpmsg_init); + +void vhost_rpmsg_destroy(struct vhost_rpmsg *vr) +{ + if (vhost_dev_has_owner(&vr->dev)) + vhost_poll_flush(&vr->vq[VIRTIO_RPMSG_REQUEST].poll); + + vhost_dev_cleanup(&vr->dev); +} +EXPORT_SYMBOL_GPL(vhost_rpmsg_destroy); + +/* send namespace */ +int vhost_rpmsg_ns_announce(struct vhost_rpmsg *vr, const char *name, unsigned int src) +{ + struct vhost_virtqueue *vq = &vr->vq[VIRTIO_RPMSG_RESPONSE]; + struct vhost_rpmsg_iter iter = { + .rhdr = { + .src = 0, + .dst = cpu_to_vhost32(vq, RPMSG_NS_ADDR), + }, + }; + struct rpmsg_ns_msg ns = { + .addr = cpu_to...
2020 May 27
0
[PATCH v3 5/5] vhost: add an RPMsg API
..._GPL(vhost_rpmsg_init); + +void vhost_rpmsg_destroy(struct vhost_rpmsg *vr) +{ + if (vhost_dev_has_owner(&vr->dev)) + vhost_poll_flush(&vr->vq[VIRTIO_RPMSG_REQUEST].poll); + + vhost_dev_cleanup(&vr->dev); +} +EXPORT_SYMBOL_GPL(vhost_rpmsg_destroy); + +/* send namespace */ +int vhost_rpmsg_ns_announce(struct vhost_rpmsg *vr, const char *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...
2020 Jul 22
0
[PATCH v4 4/4] vhost: add an RPMsg API
..._GPL(vhost_rpmsg_init); + +void vhost_rpmsg_destroy(struct vhost_rpmsg *vr) +{ + if (vhost_dev_has_owner(&vr->dev)) + vhost_poll_flush(&vr->vq[VIRTIO_RPMSG_REQUEST].poll); + + vhost_dev_cleanup(&vr->dev); +} +EXPORT_SYMBOL_GPL(vhost_rpmsg_destroy); + +/* send namespace */ +int vhost_rpmsg_ns_announce(struct vhost_rpmsg *vr, const char *name, unsigned int src) +{ + struct vhost_virtqueue *vq = &vr->vq[VIRTIO_RPMSG_RESPONSE]; + struct vhost_rpmsg_iter iter = { + .rhdr = { + .src = 0, + .dst = cpu_to_vhost32(vq, RPMSG_NS_ADDR), + .flags = cpu_to_vhost16(vq, RPMSG_NS_CREATE), /* rpms...
2020 Sep 10
6
[PATCH v7 0/3] Add a vhost RPMsg API
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:
2020 Sep 10
6
[PATCH v7 0/3] Add a vhost RPMsg API
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:
2020 Sep 10
0
[PATCH v5 4/4] vhost: add an RPMsg API
...if (vhost_dev_has_owner(&vr->dev)) > > + vhost_poll_flush(&vr->vq[VIRTIO_RPMSG_REQUEST].poll); > > + > > + vhost_dev_cleanup(&vr->dev); > > +} > > +EXPORT_SYMBOL_GPL(vhost_rpmsg_destroy); > > + > > +/* send namespace */ > > +int vhost_rpmsg_ns_announce(struct vhost_rpmsg *vr, const char *name, unsigned int src) > > +{ > > + struct vhost_virtqueue *vq = &vr->vq[VIRTIO_RPMSG_RESPONSE]; > > + struct vhost_rpmsg_iter iter = { > > + .rhdr = { > > + .src = 0, > > + .dst = cpu_to_vhost32(vq, RPMSG_NS_ADDR...
2020 Aug 26
12
[PATCH v5 0/4] Add a vhost RPMsg API
Hi, Next update: 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 patch, that is currently an RFC - address comments from Pierre-Louis Bossart:
2020 Aug 26
12
[PATCH v5 0/4] Add a vhost RPMsg API
Hi, Next update: 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 patch, that is currently an RFC - address comments from Pierre-Louis Bossart:
2020 Sep 11
0
[PATCH v5 4/4] vhost: add an RPMsg API
...; connections to any rpmsg "devices," those send their namespace announcements > > back. But I think this can be regarded as server identification: you connect > > to a server and it replies with its identification and capabilities. > > Based on the above can I assume vhost_rpmsg_ns_announce() is sent from the > guest? No, it's "vhost_..." so it's running on the host. The host (the server, an analogue of the application processor, IIUC) sends NS announcements to guests. > I saw your V7, something I will look into. In the mean time I need to bring > your...
2020 Sep 15
0
[PATCH v5 4/4] vhost: add an RPMsg API
...," those send their namespace announcements > > > > back. But I think this can be regarded as server identification: you connect > > > > to a server and it replies with its identification and capabilities. > > > > > > Based on the above can I assume vhost_rpmsg_ns_announce() is sent from the > > > guest? > > > > No, it's "vhost_..." so it's running on the host. > > Ok, that's better and confirms the usage of the VIRTIO_RPMSG_RESPONSE queue. > When reading your explanation above, I thought the term "those&quo...
2020 Aug 04
2
[PATCH v4 4/4] vhost: add an RPMsg API
...y(struct vhost_rpmsg *vr) > +{ > + if (vhost_dev_has_owner(&vr->dev)) > + vhost_poll_flush(&vr->vq[VIRTIO_RPMSG_REQUEST].poll); > + > + vhost_dev_cleanup(&vr->dev); > +} > +EXPORT_SYMBOL_GPL(vhost_rpmsg_destroy); > + > +/* send namespace */ > +int vhost_rpmsg_ns_announce(struct vhost_rpmsg *vr, const char *name, unsigned int src) > +{ > + struct vhost_virtqueue *vq = &vr->vq[VIRTIO_RPMSG_RESPONSE]; > + struct vhost_rpmsg_iter iter = { > + .rhdr = { > + .src = 0, > + .dst = cpu_to_vhost32(vq, RPMSG_NS_ADDR), > + .flags = cpu_to_vh...
2020 Aug 04
2
[PATCH v4 4/4] vhost: add an RPMsg API
...y(struct vhost_rpmsg *vr) > +{ > + if (vhost_dev_has_owner(&vr->dev)) > + vhost_poll_flush(&vr->vq[VIRTIO_RPMSG_REQUEST].poll); > + > + vhost_dev_cleanup(&vr->dev); > +} > +EXPORT_SYMBOL_GPL(vhost_rpmsg_destroy); > + > +/* send namespace */ > +int vhost_rpmsg_ns_announce(struct vhost_rpmsg *vr, const char *name, unsigned int src) > +{ > + struct vhost_virtqueue *vq = &vr->vq[VIRTIO_RPMSG_RESPONSE]; > + struct vhost_rpmsg_iter iter = { > + .rhdr = { > + .src = 0, > + .dst = cpu_to_vhost32(vq, RPMSG_NS_ADDR), > + .flags = cpu_to_vh...
2020 Jul 22
13
[PATCH v4 0/4] Add a vhost RPMsg API
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 -
2020 Jul 22
13
[PATCH v4 0/4] Add a vhost RPMsg API
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 -
2020 May 16
9
[PATCH 0/6] Add a vhost RPMsg API
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,
2020 May 16
9
[PATCH 0/6] Add a vhost RPMsg API
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,
2020 May 27
10
[PATCH v3 0/5] Add a vhost RPMsg API
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.