search for: return_buf

...r\n", + __func__, head); + return head; + } + + /* Nothing new? */ + if (head == vq->num) + return head; + + if (vq == &vr->vq[VIRTIO_RPMSG_RESPONSE]) { + if (out) { + vq_err(vq, "%s(): invalid %d output in response queue\n", + __func__, out); + goto return_buf; + } + + *cnt = in; + } + + if (vq == &vr->vq[VIRTIO_RPMSG_REQUEST]) { + if (in) { + vq_err(vq, "%s(): invalid %d input in request queue\n", + __func__, in); + goto return_buf; + } + + *cnt = out; + } + + return head; + +return_buf: + vhost_add_used(vq, head, 0); +...

...+ return head; + } + + /* Nothing new? */ + if (head == vq->num) + return head; + + if (vq == &vr->vq[VIRTIO_RPMSG_RESPONSE] && (out || in != 1)) { + vq_err(vq, + "%s(): invalid %d input and %d output in response queue\n", + __func__, in, out); + goto return_buf; + } + + if (vq == &vr->vq[VIRTIO_RPMSG_REQUEST] && (in || out != 1)) { + vq_err(vq, + "%s(): invalid %d input and %d output in request queue\n", + __func__, in, out); + goto return_buf; + } + + return head; + +return_buf: + /* + * FIXME: might need to re...

...+ return head; + } + + /* Nothing new? */ + if (head == vq->num) + return head; + + if (vq == &vr->vq[VIRTIO_RPMSG_RESPONSE] && (out || in != 1)) { + vq_err(vq, + "%s(): invalid %d input and %d output in response queue\n", + __func__, in, out); + goto return_buf; + } + + if (vq == &vr->vq[VIRTIO_RPMSG_REQUEST] && (in || out != 1)) { + vq_err(vq, + "%s(): invalid %d input and %d output in request queue\n", + __func__, in, out); + goto return_buf; + } + + return head; + +return_buf: + /* + * FIXME: might need to re...

...is in != 1 looks like a dependency on a specific message layout. virtio spec says to avoid these. Using iov iters it's not too hard to do ... > + vq_err(vq, > + "%s(): invalid %d input and %d output in response queue\n", > + __func__, in, out); > + goto return_buf; > + } > + > + if (vq == &vr->vq[VIRTIO_RPMSG_REQUEST] && (in || out != 1)) { > + vq_err(vq, > + "%s(): invalid %d input and %d output in request queue\n", > + __func__, in, out); > + goto return_buf; > + } > + > + return head...

...is in != 1 looks like a dependency on a specific message layout. virtio spec says to avoid these. Using iov iters it's not too hard to do ... > + vq_err(vq, > + "%s(): invalid %d input and %d output in response queue\n", > + __func__, in, out); > + goto return_buf; > + } > + > + if (vq == &vr->vq[VIRTIO_RPMSG_REQUEST] && (in || out != 1)) { > + vq_err(vq, > + "%s(): invalid %d input and %d output in request queue\n", > + __func__, in, out); > + goto return_buf; > + } > + > + return head...

...> > + if (head == vq->num) > > + return head; > > + > > + if (vq == &vr->vq[VIRTIO_RPMSG_RESPONSE]) { > > + if (out) { > > + vq_err(vq, "%s(): invalid %d output in response queue\n", > > + __func__, out); > > + goto return_buf; > > + } > > + > > + *cnt = in; > > + } > > + > > + if (vq == &vr->vq[VIRTIO_RPMSG_REQUEST]) { > > + if (in) { > > + vq_err(vq, "%s(): invalid %d input in request queue\n", > > + __func__, in); > > + goto re...

...> > + if (head == vq->num) > > + return head; > > + > > + if (vq == &vr->vq[VIRTIO_RPMSG_RESPONSE]) { > > + if (out) { > > + vq_err(vq, "%s(): invalid %d output in response queue\n", > > + __func__, out); > > + goto return_buf; > > + } > > + > > + *cnt = in; > > + } > > + > > + if (vq == &vr->vq[VIRTIO_RPMSG_REQUEST]) { > > + if (in) { > > + vq_err(vq, "%s(): invalid %d input in request queue\n", > > + __func__, in); > > + goto re...

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:

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 -

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,

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

...cy virtio, but now you are claiming support for virtio 1, so need to fix these assumptions in the device. > > > + vq_err(vq, > > > + "%s(): invalid %d input and %d output in response queue\n", > > > + __func__, in, out); > > > + goto return_buf; > > > + } > > > + > > > + if (vq == &vr->vq[VIRTIO_RPMSG_REQUEST] && (in || out != 1)) { > > > + vq_err(vq, > > > + "%s(): invalid %d input and %d output in request queue\n", > > > + __func__, in, out);...

...cy virtio, but now you are claiming support for virtio 1, so need to fix these assumptions in the device. > > > + vq_err(vq, > > > + "%s(): invalid %d input and %d output in response queue\n", > > > + __func__, in, out); > > > + goto return_buf; > > > + } > > > + > > > + if (vq == &vr->vq[VIRTIO_RPMSG_REQUEST] && (in || out != 1)) { > > > + vq_err(vq, > > > + "%s(): invalid %d input and %d output in request queue\n", > > > + __func__, in, out);...

...tation, and it has to match the virtio_rpmsg_bus.c driver, and that one has specific VirtIO queue and message usage patterns. > > + vq_err(vq, > > + "%s(): invalid %d input and %d output in response queue\n", > > + __func__, in, out); > > + goto return_buf; > > + } > > + > > + if (vq == &vr->vq[VIRTIO_RPMSG_REQUEST] && (in || out != 1)) { > > + vq_err(vq, > > + "%s(): invalid %d input and %d output in request queue\n", > > + __func__, in, out); > > + goto return_buf;...

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:

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:

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.