Hi Michael,
...back from holidays and still unsure what your preferred solution
for the message layout would be:
On Wed, Aug 12, 2020 at 02:32:43PM +0200, Guennadi Liakhovetski wrote:
> Hi Michael,
>
> Thanks for a review.
>
> On Mon, Aug 10, 2020 at 09:44:15AM -0400, Michael S. Tsirkin wrote:
> > On Tue, Aug 04, 2020 at 05:19:17PM +0200, Guennadi Liakhovetski wrote:
[snip]
> > > > > +static int vhost_rpmsg_get_single(struct vhost_virtqueue *vq)
> > > > > +{
> > > > > + struct vhost_rpmsg *vr = container_of(vq->dev, struct vhost_rpmsg, dev);
> > > > > + unsigned int out, in;
> > > > > + int head = vhost_get_vq_desc(vq, vq->iov, ARRAY_SIZE(vq->iov), &out, &in,
> > > > > + NULL, NULL);
> > > > > + if (head < 0) {
> > > > > + vq_err(vq, "%s(): error %d getting buffer\n",
> > > > > + __func__, head);
> > > > > + return head;
> > > > > + }
> > > > > +
> > > > > + /* Nothing new? */
> > > > > + if (head == vq->num)
> > > > > + return head;
> > > > > +
> > > > > + if (vq == &vr->vq[VIRTIO_RPMSG_RESPONSE] && (out || in != 1)) {
> > > >
> > > > This 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
> > > > ...
> > >
> > > This is an RPMsg VirtIO implementation, and it has to match the virtio_rpmsg_bus.c
> > > driver, and that one has specific VirtIO queue and message usage patterns.
> >
> > That could be fine for legacy virtio, but now you are claiming support
> > for virtio 1, so need to fix these assumptions in the device.
>
> I can just deop these checks without changing anything else, that still would work.
> I could also make this work with "any" layout - either ignoring any left-over
> buffers or maybe even getting them one by one. But I wouldn't even be able to test
> those modes without modifying / breaking the current virtio-rpmsg driver. What's
> the preferred solution?
Could you elaborate a bit please?
Thanks
Guennadi
