Displaying 20 results from an estimated 27 matches for "vhost_rpmsg_ns_announc".
Did you mean:
vhost_rpmsg_ns_announce
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.