Re: [PATCH v2 8/9] ALSA: virtio: introduce PCM channel map support

[Guennadi Liakhovetski]

On Sun, 24 Jan 2021, Anton Yakovlev wrote:


Enumerate all available PCM channel maps and create ALSA controls.

Signed-off-by: Anton Yakovlev 
---
sound/virtio/Makefile   |   1 +
sound/virtio/virtio_card.c  |  15 +++
sound/virtio/virtio_card.h  |   8 ++
sound/virtio/virtio_chmap.c | 237 
sound/virtio/virtio_pcm.h   |   4 +
5 files changed, 265 insertions(+)
create mode 100644 sound/virtio/virtio_chmap.c


[snip]


diff --git a/sound/virtio/virtio_chmap.c b/sound/virtio/virtio_chmap.c
new file mode 100644
index ..8a2ddc4dcffb
--- /dev/null
+++ b/sound/virtio/virtio_chmap.c
@@ -0,0 +1,237 @@


[snip]


+/**
+ * virtsnd_chmap_parse_cfg() - Parse the channel map configuration.
+ * @snd: VirtIO sound device.
+ *
+ * This function is called during initial device initialization.
+ *
+ * Context: Any context that permits to sleep.
+ * Return: 0 on success, -errno on failure.
+ */
+int virtsnd_chmap_parse_cfg(struct virtio_snd *snd)
+{
+   struct virtio_device *vdev = snd->vdev;
+   unsigned int i;
+   int rc;
+
+   virtio_cread(vdev, struct virtio_snd_config, chmaps, >nchmaps);
+   if (!snd->nchmaps)
+   return 0;
+
+   snd->chmaps = devm_kcalloc(>dev, snd->nchmaps,
+  sizeof(*snd->chmaps), GFP_KERNEL);
+   if (!snd->chmaps)
+   return -ENOMEM;
+
+   rc = virtsnd_ctl_query_info(snd, VIRTIO_SND_R_CHMAP_INFO, 0,
+   snd->nchmaps, sizeof(*snd->chmaps),
+   snd->chmaps);
+   if (rc)
+   return rc;
+
+   /* Count the number of channel maps per each PCM device/stream. */
+   for (i = 0; i < snd->nchmaps; ++i) {
+   struct virtio_snd_chmap_info *info = >chmaps[i];
+   unsigned int nid = le32_to_cpu(info->hdr.hda_fn_nid);
+   struct virtio_pcm *pcm;
+   struct virtio_pcm_stream *stream;
+
+   pcm = virtsnd_pcm_find_or_create(snd, nid);
+   if (IS_ERR(pcm))
+   return PTR_ERR(pcm);
+
+   switch (info->direction) {
+   case VIRTIO_SND_D_OUTPUT: {
+   stream = >streams[SNDRV_PCM_STREAM_PLAYBACK];
+   break;
+   }
+   case VIRTIO_SND_D_INPUT: {
+   stream = >streams[SNDRV_PCM_STREAM_CAPTURE];
+   break;
+   }
+   default: {
+   dev_err(>dev,
+   "chmap #%u: unknown direction (%u)\n", i,
+   info->direction);
+   return -EINVAL;
+   }
+   }
+
+   stream->nchmaps++;
+   }
+
+   return 0;
+}
+
+/**
+ * virtsnd_chmap_add_ctls() - Create an ALSA control for channel maps.
+ * @pcm: ALSA PCM device.
+ * @direction: PCM stream direction (SNDRV_PCM_STREAM_XXX).
+ * @stream: VirtIO PCM stream.
+ *
+ * Context: Any context.
+ * Return: 0 on success, -errno on failure.
+ */
+static int virtsnd_chmap_add_ctls(struct snd_pcm *pcm, int direction,
+ struct virtio_pcm_stream *stream)
+{
+   unsigned int i;
+   int max_channels = 0;
+
+   for (i = 0; i < stream->nchmaps; i++)
+   if (max_channels < stream->chmaps[i].channels)
+   max_channels = stream->chmaps[i].channels;
+
+   return snd_pcm_add_chmap_ctls(pcm, direction, stream->chmaps,
+ max_channels, 0, NULL);
+}
+
+/**
+ * virtsnd_chmap_build_devs() - Build ALSA controls for channel maps.
+ * @snd: VirtIO sound device.
+ *
+ * Context: Any context.
+ * Return: 0 on success, -errno on failure.
+ */
+int virtsnd_chmap_build_devs(struct virtio_snd *snd)
+{
+   struct virtio_device *vdev = snd->vdev;
+   struct virtio_pcm *pcm;
+   struct virtio_pcm_stream *stream;
+   unsigned int i;
+   int rc;
+
+   /* Allocate channel map elements per each PCM device/stream. */
+   list_for_each_entry(pcm, >pcm_list, list) {
+   for (i = 0; i < ARRAY_SIZE(pcm->streams); ++i) {
+   stream = >streams[i];
+
+   if (!stream->nchmaps)
+   continue;
+
+   stream->chmaps = devm_kcalloc(>dev,
+ stream->nchmaps + 1,
+ sizeof(*stream->chmaps),
+ GFP_KERNEL);
+   if (!stream->chmaps)
+   return -ENOMEM;
+
+   stream->nchmaps = 0;
+   }
+   }
+
+   /* Initialize channel maps per each PCM device/stream. */
+   for (i = 0; i < snd->nchmaps; ++i) {
+   struct virtio_snd_chmap_info *info = >chmaps[i];
+   

Re: [PATCH v2 7/9] ALSA: virtio: introduce jack support

[Guennadi Liakhovetski]

On Sun, 24 Jan 2021, Anton Yakovlev wrote:


Enumerate all available jacks and create ALSA controls.

At the moment jacks have a simple implementation and can only be used
to receive notifications about a plugged in/out device.

Signed-off-by: Anton Yakovlev 
---
sound/virtio/Makefile  |   1 +
sound/virtio/virtio_card.c |  18 +++
sound/virtio/virtio_card.h |  12 ++
sound/virtio/virtio_jack.c | 255 +
4 files changed, 286 insertions(+)
create mode 100644 sound/virtio/virtio_jack.c


[snip]


diff --git a/sound/virtio/virtio_jack.c b/sound/virtio/virtio_jack.c
new file mode 100644
index ..83593c59f6bf
--- /dev/null
+++ b/sound/virtio/virtio_jack.c
@@ -0,0 +1,255 @@


[snip]


+/**
+ * virtsnd_jack_parse_cfg() - Parse the jack configuration.
+ * @snd: VirtIO sound device.
+ *
+ * This function is called during initial device initialization.
+ *
+ * Context: Any context that permits to sleep.
+ * Return: 0 on success, -errno on failure.
+ */
+int virtsnd_jack_parse_cfg(struct virtio_snd *snd)
+{
+   struct virtio_device *vdev = snd->vdev;
+   struct virtio_snd_jack_info *info;
+   unsigned int i;
+   int rc;
+
+   virtio_cread(vdev, struct virtio_snd_config, jacks, >njacks);
+   if (!snd->njacks)
+   return 0;
+
+   snd->jacks = devm_kcalloc(>dev, snd->njacks, sizeof(*snd->jacks),
+ GFP_KERNEL);
+   if (!snd->jacks)
+   return -ENOMEM;
+
+   info = devm_kcalloc(>dev, snd->njacks, sizeof(*info), GFP_KERNEL);


just kcalloc()


+   if (!info)
+   return -ENOMEM;
+
+   rc = virtsnd_ctl_query_info(snd, VIRTIO_SND_R_JACK_INFO, 0, snd->njacks,
+   sizeof(*info), info);
+   if (rc)
+   return rc;
+
+   for (i = 0; i < snd->njacks; ++i) {
+   struct virtio_jack *jack = >jacks[i];
+   struct virtio_pcm *pcm;
+
+   jack->nid = le32_to_cpu(info[i].hdr.hda_fn_nid);
+   jack->features = le32_to_cpu(info[i].features);
+   jack->defconf = le32_to_cpu(info[i].hda_reg_defconf);
+   jack->caps = le32_to_cpu(info[i].hda_reg_caps);
+   jack->connected = info[i].connected;
+
+   pcm = virtsnd_pcm_find_or_create(snd, jack->nid);
+   if (IS_ERR(pcm))
+   return PTR_ERR(pcm);
+   }
+
+   devm_kfree(>dev, info);
+
+   return 0;
+}


Thanks
Guennadi
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v2 6/9] ALSA: virtio: PCM substream operators

[Guennadi Liakhovetski]

One more thing I missed yesterday:

On Mon, 25 Jan 2021, Guennadi Liakhovetski wrote:



On Sun, 24 Jan 2021, Anton Yakovlev wrote:


Introduce the operators required for the operation of substreams.

Signed-off-by: Anton Yakovlev 
---
sound/virtio/Makefile |   3 +-
sound/virtio/virtio_pcm.c |   5 +-
sound/virtio/virtio_pcm.h |   2 +
sound/virtio/virtio_pcm_ops.c | 513 ++
4 files changed, 521 insertions(+), 2 deletions(-)
create mode 100644 sound/virtio/virtio_pcm_ops.c


[snip]


diff --git a/sound/virtio/virtio_pcm_ops.c b/sound/virtio/virtio_pcm_ops.c
new file mode 100644
index ..19882777fcd6
--- /dev/null
+++ b/sound/virtio/virtio_pcm_ops.c
@@ -0,0 +1,513 @@


[snip]


+/**
+ * virtsnd_pcm_release() - Release the PCM substream on the device side.
+ * @substream: VirtIO substream.
+ *
+ * Context: Any context that permits to sleep.
+ * Return: 0 on success, -errno on failure.
+ */
+static inline bool virtsnd_pcm_released(struct virtio_pcm_substream 
*substream)

+{
+   /*
+	 * The spec states that upon receipt of the RELEASE command "the 
device
+	 * MUST complete all pending I/O messages for the specified stream 
ID".

+* Thus, we consider the absence of I/O messages in the queue as an
+* indication that the substream has been released.
+*/
+   return atomic_read(>msg_count) == 0;


Also here having it atomic doesn't really seem to help. This just means, that 
at some point of time it was == 0.



+}
+
+static int virtsnd_pcm_release(struct virtio_pcm_substream *substream)


kernel-doc missing


+{
+   struct virtio_snd *snd = substream->snd;
+   struct virtio_snd_msg *msg;
+   unsigned int js = msecs_to_jiffies(msg_timeout_ms);
+   int rc;
+
+   msg = virtsnd_pcm_ctl_msg_alloc(substream, VIRTIO_SND_R_PCM_RELEASE,
+   GFP_KERNEL);
+   if (IS_ERR(msg))
+   return PTR_ERR(msg);
+
+   rc = virtsnd_ctl_msg_send_sync(snd, msg);
+   if (rc)
+   return rc;
+
+   return wait_event_interruptible_timeout(substream->msg_empty,
+   virtsnd_pcm_released(substream),
+   js);


wait_event_interruptible_timeout() will return a positive number in 
success cases, 0 means a timeout and condition still false. Whereas when 
you call this function you interpret 0 as success and you expect any != 0 
to be a negative error. Wondering how this worked during your tests?


Thanks
Guennadi
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v2 6/9] ALSA: virtio: PCM substream operators

[Guennadi Liakhovetski]

On Sun, 24 Jan 2021, Anton Yakovlev wrote:


Introduce the operators required for the operation of substreams.

Signed-off-by: Anton Yakovlev 
---
sound/virtio/Makefile |   3 +-
sound/virtio/virtio_pcm.c |   5 +-
sound/virtio/virtio_pcm.h |   2 +
sound/virtio/virtio_pcm_ops.c | 513 ++
4 files changed, 521 insertions(+), 2 deletions(-)
create mode 100644 sound/virtio/virtio_pcm_ops.c


[snip]


diff --git a/sound/virtio/virtio_pcm_ops.c b/sound/virtio/virtio_pcm_ops.c
new file mode 100644
index ..19882777fcd6
--- /dev/null
+++ b/sound/virtio/virtio_pcm_ops.c
@@ -0,0 +1,513 @@


[snip]


+/**
+ * virtsnd_pcm_release() - Release the PCM substream on the device side.
+ * @substream: VirtIO substream.
+ *
+ * Context: Any context that permits to sleep.
+ * Return: 0 on success, -errno on failure.
+ */
+static inline bool virtsnd_pcm_released(struct virtio_pcm_substream *substream)
+{
+   /*
+* The spec states that upon receipt of the RELEASE command "the device
+* MUST complete all pending I/O messages for the specified stream ID".
+* Thus, we consider the absence of I/O messages in the queue as an
+* indication that the substream has been released.
+*/
+   return atomic_read(>msg_count) == 0;


Also here having it atomic doesn't really seem to help. This just means, 
that at some point of time it was == 0.



+}
+
+static int virtsnd_pcm_release(struct virtio_pcm_substream *substream)


kernel-doc missing


+{
+   struct virtio_snd *snd = substream->snd;
+   struct virtio_snd_msg *msg;
+   unsigned int js = msecs_to_jiffies(msg_timeout_ms);
+   int rc;
+
+   msg = virtsnd_pcm_ctl_msg_alloc(substream, VIRTIO_SND_R_PCM_RELEASE,
+   GFP_KERNEL);
+   if (IS_ERR(msg))
+   return PTR_ERR(msg);
+
+   rc = virtsnd_ctl_msg_send_sync(snd, msg);
+   if (rc)
+   return rc;
+
+   return wait_event_interruptible_timeout(substream->msg_empty,
+   virtsnd_pcm_released(substream),
+   js);
+}
+
+/**
+ * virtsnd_pcm_open() - Open the PCM substream.
+ * @substream: Kernel ALSA substream.
+ *
+ * Context: Any context.
+ * Return: 0 on success, -errno on failure.
+ */
+static int virtsnd_pcm_open(struct snd_pcm_substream *substream)
+{
+   struct virtio_pcm *pcm = snd_pcm_substream_chip(substream);
+   struct virtio_pcm_substream *ss = NULL;
+
+   if (pcm) {
+   switch (substream->stream) {
+   case SNDRV_PCM_STREAM_PLAYBACK:
+   case SNDRV_PCM_STREAM_CAPTURE: {
+   struct virtio_pcm_stream *stream =
+   >streams[substream->stream];
+
+   if (substream->number < stream->nsubstreams)


Can this condition ever be false?


+   ss = stream->substreams[substream->number];
+   break;
+   }
+   }
+   }
+
+   if (!ss)
+   return -EBADFD;
+
+   substream->runtime->hw = ss->hw;
+   substream->private_data = ss;
+
+   return 0;
+}
+
+/**
+ * virtsnd_pcm_close() - Close the PCM substream.
+ * @substream: Kernel ALSA substream.
+ *
+ * Context: Any context.
+ * Return: 0.
+ */
+static int virtsnd_pcm_close(struct snd_pcm_substream *substream)
+{
+   return 0;
+}
+
+/**
+ * virtsnd_pcm_hw_params() - Set the parameters of the PCM substream.
+ * @substream: Kernel ALSA substream.
+ * @hw_params: Hardware parameters (can be NULL).
+ *
+ * The function can be called both from the upper level (in this case,
+ * @hw_params is not NULL) or from the driver itself (in this case, @hw_params
+ * is NULL, and the parameter values are taken from the runtime structure).
+ *
+ * In all cases, the function:
+ *   1. checks the state of the virtqueue and, if necessary, tries to fix it,
+ *   2. sets the parameters on the device side,
+ *   3. allocates a hardware buffer and I/O messages.
+ *
+ * Context: Any context that permits to sleep.
+ * Return: 0 on success, -errno on failure.
+ */
+static int virtsnd_pcm_hw_params(struct snd_pcm_substream *substream,
+struct snd_pcm_hw_params *hw_params)
+{
+   struct snd_pcm_runtime *runtime = substream->runtime;
+   struct virtio_pcm_substream *ss = snd_pcm_substream_chip(substream);
+   struct virtio_device *vdev = ss->snd->vdev;
+   struct virtio_snd_msg *msg;
+   struct virtio_snd_pcm_set_params *request;
+   snd_pcm_format_t format;
+   unsigned int channels;
+   unsigned int rate;
+   unsigned int buffer_bytes;
+   unsigned int period_bytes;
+   unsigned int periods;
+   unsigned int i;
+   int vformat = -1;
+   int vrate = -1;
+   int rc;
+
+   /*
+* If we got here after ops->trigger() was called, the 

Re: [PATCH v2 5/9] ALSA: virtio: handling control and I/O messages for the PCM device

[Guennadi Liakhovetski]

On Sun, 24 Jan 2021, Anton Yakovlev wrote:


The driver implements a message-based transport for I/O substream
operations. Before the start of the substream, the hardware buffer is
sliced into I/O messages, the number of which is equal to the current
number of periods. The size of each message is equal to the current
size of one period.

I/O messages are organized in an ordered queue. The completion of the
I/O message indicates an elapsed period (the only exception is the end
of the stream for the capture substream). Upon completion, the message
is automatically re-added to the end of the queue.

Signed-off-by: Anton Yakovlev 
---
sound/virtio/Makefile |   3 +-
sound/virtio/virtio_card.c|  10 ++
sound/virtio/virtio_card.h|   9 +
sound/virtio/virtio_pcm.c |   3 +
sound/virtio/virtio_pcm.h |  31 
sound/virtio/virtio_pcm_msg.c | 325 ++
6 files changed, 380 insertions(+), 1 deletion(-)
create mode 100644 sound/virtio/virtio_pcm_msg.c

diff --git a/sound/virtio/Makefile b/sound/virtio/Makefile
index 69162a545a41..626af3cc3ed7 100644
--- a/sound/virtio/Makefile
+++ b/sound/virtio/Makefile
@@ -5,5 +5,6 @@ obj-$(CONFIG_SND_VIRTIO) += virtio_snd.o
virtio_snd-objs := \
virtio_card.o \
virtio_ctl_msg.o \
-   virtio_pcm.o
+   virtio_pcm.o \
+   virtio_pcm_msg.o

diff --git a/sound/virtio/virtio_card.c b/sound/virtio/virtio_card.c
index 39fe13b43dd1..11d025ee77c2 100644
--- a/sound/virtio/virtio_card.c
+++ b/sound/virtio/virtio_card.c
@@ -143,6 +143,12 @@ static int virtsnd_find_vqs(struct virtio_snd *snd)
callbacks[VIRTIO_SND_VQ_CONTROL] = virtsnd_ctl_notify_cb;
callbacks[VIRTIO_SND_VQ_EVENT] = virtsnd_event_notify_cb;

+   virtio_cread(vdev, struct virtio_snd_config, streams, );
+   if (n) {
+   callbacks[VIRTIO_SND_VQ_TX] = virtsnd_pcm_tx_notify_cb;
+   callbacks[VIRTIO_SND_VQ_RX] = virtsnd_pcm_rx_notify_cb;
+   }
+
rc = virtio_find_vqs(vdev, VIRTIO_SND_VQ_MAX, vqs, callbacks, names,
 NULL);
if (rc) {
@@ -177,6 +183,10 @@ static int virtsnd_find_vqs(struct virtio_snd *snd)
 * virtsnd_enable_event_vq() - Enable the event virtqueue.
 * @snd: VirtIO sound device.
 *
+ * The tx queue is enabled only if the device supports playback stream(s).
+ *
+ * The rx queue is enabled only if the device supports capture stream(s).
+ *
 * Context: Any context.
 */
static void virtsnd_enable_event_vq(struct virtio_snd *snd)
diff --git a/sound/virtio/virtio_card.h b/sound/virtio/virtio_card.h
index be6651a6aaf8..b11c09984882 100644
--- a/sound/virtio/virtio_card.h
+++ b/sound/virtio/virtio_card.h
@@ -89,4 +89,13 @@ virtsnd_rx_queue(struct virtio_snd *snd)
return >queues[VIRTIO_SND_VQ_RX];
}

+static inline struct virtio_snd_queue *
+virtsnd_pcm_queue(struct virtio_pcm_substream *substream)
+{
+   if (substream->direction == SNDRV_PCM_STREAM_PLAYBACK)
+   return virtsnd_tx_queue(substream->snd);
+   else
+   return virtsnd_rx_queue(substream->snd);
+}
+
#endif /* VIRTIO_SND_CARD_H */
diff --git a/sound/virtio/virtio_pcm.c b/sound/virtio/virtio_pcm.c
index 036990b7b78a..1ab50dcc88c8 100644
--- a/sound/virtio/virtio_pcm.c
+++ b/sound/virtio/virtio_pcm.c
@@ -376,6 +376,7 @@ int virtsnd_pcm_parse_cfg(struct virtio_snd *snd)

substream->snd = snd;
substream->sid = i;
+   init_waitqueue_head(>msg_empty);

rc = virtsnd_pcm_build_hw(substream, [i]);
if (rc)
@@ -530,6 +531,8 @@ void virtsnd_pcm_event(struct virtio_snd *snd, struct 
virtio_snd_event *event)
break;
}
case VIRTIO_SND_EVT_PCM_XRUN: {
+   if (atomic_read(>xfer_enabled))


Why does .xfer_enabled have to be atomic? It only takes two values - 0 and 
1, I don't see any incrementing, or test-and-set type operations or 
anything similar. Also I don't see .xfer_enabled being set to 1 anywhere 
in this patch, presumably that happens in one of later patches.



+   atomic_set(>xfer_xrun, 1);


Ditto.


break;
}
}
diff --git a/sound/virtio/virtio_pcm.h b/sound/virtio/virtio_pcm.h
index 73fb4d9dc524..d011b7e1d18d 100644
--- a/sound/virtio/virtio_pcm.h
+++ b/sound/virtio/virtio_pcm.h
@@ -24,6 +24,7 @@
#include 

struct virtio_pcm;
+struct virtio_pcm_msg;

/**
 * struct virtio_pcm_substream - VirtIO PCM substream.
@@ -34,6 +35,16 @@ struct virtio_pcm;
 * @features: Stream VirtIO feature bit map (1 << VIRTIO_SND_PCM_F_XXX).
 * @substream: Kernel ALSA substream.
 * @hw: Kernel ALSA substream hardware descriptor.
+ * @frame_bytes: Current frame size in bytes.
+ * @period_size: Current period size in frames.
+ * @buffer_size: Current buffer size in frames.
+ * @hw_ptr: Substream hardware pointer value in frames [0 ... buffer_size).
+ * @xfer_enabled: Data transfer state (0 - off, 1 - on).
+ * @xfer_xrun: 

Re: [PATCH v2 4/9] ALSA: virtio: build PCM devices and substream hardware descriptors

[Guennadi Liakhovetski]

On Sun, 24 Jan 2021, Anton Yakovlev wrote:


Like the HDA specification, the virtio sound device specification links
PCM substreams, jacks and PCM channel maps into functional groups. For
each discovered group, a PCM device is created, the number of which
coincides with the group number.

Introduce the module parameters for setting the hardware buffer
parameters:
 pcm_buffer_ms [=160]
 pcm_periods_min [=2]
 pcm_periods_max [=16]
 pcm_period_ms_min [=10]
 pcm_period_ms_max [=80]

Signed-off-by: Anton Yakovlev 
---
sound/virtio/Makefile  |   3 +-
sound/virtio/virtio_card.c |  45 
sound/virtio/virtio_card.h |   9 +
sound/virtio/virtio_pcm.c  | 536 +
sound/virtio/virtio_pcm.h  |  89 ++
5 files changed, 681 insertions(+), 1 deletion(-)
create mode 100644 sound/virtio/virtio_pcm.c
create mode 100644 sound/virtio/virtio_pcm.h

diff --git a/sound/virtio/Makefile b/sound/virtio/Makefile
index dc551e637441..69162a545a41 100644
--- a/sound/virtio/Makefile
+++ b/sound/virtio/Makefile
@@ -4,5 +4,6 @@ obj-$(CONFIG_SND_VIRTIO) += virtio_snd.o

virtio_snd-objs := \
virtio_card.o \
-   virtio_ctl_msg.o
+   virtio_ctl_msg.o \
+   virtio_pcm.o

diff --git a/sound/virtio/virtio_card.c b/sound/virtio/virtio_card.c
index 955eadc2d858..39fe13b43dd1 100644
--- a/sound/virtio/virtio_card.c
+++ b/sound/virtio/virtio_card.c
@@ -92,6 +92,17 @@ static void virtsnd_event_notify_cb(struct virtqueue *vqueue)
if (!event)
break;

+   switch (le32_to_cpu(event->hdr.code)) {
+   case VIRTIO_SND_EVT_PCM_PERIOD_ELAPSED:
+   case VIRTIO_SND_EVT_PCM_XRUN: {


In the previous patch you had a switch-case statement complying to the 
common kernel coding style. It isn't specified in coding-style.rst, but 
these superfluous braces really don't seem to be good for anything - in 
this and multiple other switch-case statements in the series.



+   virtsnd_pcm_event(snd, event);
+   break;
+   }
+   default: {
+   break;


An empty default doesn't seem very useful either. So the above could've 
just been


+   switch (le32_to_cpu(event->hdr.code)) {
+   case VIRTIO_SND_EVT_PCM_PERIOD_ELAPSED:
+   case VIRTIO_SND_EVT_PCM_XRUN:
+   virtsnd_pcm_event(snd, event);
+   }


+   }
+   }
+
virtsnd_event_send(queue->vqueue, event, true,
   GFP_ATOMIC);
}
@@ -274,6 +285,16 @@ static int virtsnd_build_devs(struct virtio_snd *snd)
strscpy(snd->card->longname, "VirtIO Sound Card",
sizeof(snd->card->longname));

+   rc = virtsnd_pcm_parse_cfg(snd);
+   if (rc)
+   return rc;
+
+   if (snd->nsubstreams) {
+   rc = virtsnd_pcm_build_devs(snd);
+   if (rc)
+   return rc;
+   }
+
return snd_card_register(snd->card);
}

@@ -302,6 +323,9 @@ static int virtsnd_validate(struct virtio_device *vdev)
return -EINVAL;
}

+   if (virtsnd_pcm_validate(vdev))
+   return -EINVAL;
+
return 0;
}

@@ -325,6 +349,7 @@ static int virtsnd_probe(struct virtio_device *vdev)
snd->vdev = vdev;
INIT_WORK(>reset_work, virtsnd_reset_fn);
INIT_LIST_HEAD(>ctl_msgs);
+   INIT_LIST_HEAD(>pcm_list);

vdev->priv = snd;

@@ -359,6 +384,8 @@ static int virtsnd_probe(struct virtio_device *vdev)
static void virtsnd_remove(struct virtio_device *vdev)
{
struct virtio_snd *snd = vdev->priv;
+   struct virtio_pcm *pcm;
+   struct virtio_pcm *pcm_next;

if (!snd)
return;
@@ -376,6 +403,24 @@ static void virtsnd_remove(struct virtio_device *vdev)
vdev->config->reset(vdev);
vdev->config->del_vqs(vdev);

+   list_for_each_entry_safe(pcm, pcm_next, >pcm_list, list) {
+   unsigned int i;
+
+   list_del(>list);
+
+   for (i = 0; i < ARRAY_SIZE(pcm->streams); ++i) {
+   struct virtio_pcm_stream *stream = >streams[i];
+
+   if (stream->substreams)
+   devm_kfree(>dev, stream->substreams);
+   }
+
+   devm_kfree(>dev, pcm);


Please double-check both devm_kfree() calls above. Probably they aren't 
needed in the .remove() method.



+   }
+
+   if (snd->substreams)
+   devm_kfree(>dev, snd->substreams);
+
devm_kfree(>dev, snd);

vdev->priv = NULL;
diff --git a/sound/virtio/virtio_card.h b/sound/virtio/virtio_card.h
index 37b734a92134..be6651a6aaf8 100644
--- a/sound/virtio/virtio_card.h

Re: [PATCH v2 3/9] ALSA: virtio: handling control messages

[Guennadi Liakhovetski]

I think the use of (devm_)kmalloc() and friends needs some refinement in 
several patches in the series.


On Sun, 24 Jan 2021, Anton Yakovlev wrote:


The control queue can be used by different parts of the driver to send
commands to the device. Control messages can be either synchronous or
asynchronous. The lifetime of a message is controlled by a reference
count.

Introduce a module parameter to set the message completion timeout:
 msg_timeout_ms [=1000]

Signed-off-by: Anton Yakovlev 
---
sound/virtio/Makefile |   3 +-
sound/virtio/virtio_card.c|  20 +++
sound/virtio/virtio_card.h|   7 +
sound/virtio/virtio_ctl_msg.c | 293 ++
sound/virtio/virtio_ctl_msg.h | 122 ++
5 files changed, 444 insertions(+), 1 deletion(-)
create mode 100644 sound/virtio/virtio_ctl_msg.c
create mode 100644 sound/virtio/virtio_ctl_msg.h


[snip]


diff --git a/sound/virtio/virtio_ctl_msg.c b/sound/virtio/virtio_ctl_msg.c
new file mode 100644
index ..c1701756bc32
--- /dev/null
+++ b/sound/virtio/virtio_ctl_msg.c
@@ -0,0 +1,293 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Sound card driver for virtio
+ * Copyright (C) 2020  OpenSynergy GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify


Same comment about licence, and in other patches as well.


+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see .
+ */
+#include 
+#include 
+
+#include "virtio_card.h"
+#include "virtio_ctl_msg.h"
+
+/**
+ * virtsnd_ctl_msg_alloc_ext() - Allocate and initialize a control message.
+ * @vdev: VirtIO parent device.
+ * @request_size: Size of request header (pointed to by sg_request field).
+ * @response_size: Size of response header (pointed to by sg_response field).
+ * @sgs: Additional data to attach to the message (may be NULL).
+ * @out_sgs: Number of scattergather elements to attach to the request header.
+ * @in_sgs: Number of scattergather elements to attach to the response header.
+ * @gfp: Kernel flags for memory allocation.
+ *
+ * The message will be automatically freed when the ref_count value is 0.
+ *
+ * Context: Any context. May sleep if @gfp flags permit.
+ * Return: Allocated message on success, ERR_PTR(-errno) on failure.
+ */
+struct virtio_snd_msg *virtsnd_ctl_msg_alloc_ext(struct virtio_device *vdev,
+size_t request_size,
+size_t response_size,
+struct scatterlist *sgs,
+unsigned int out_sgs,
+unsigned int in_sgs, gfp_t gfp)
+{
+   struct virtio_snd_msg *msg;
+   size_t msg_size =
+   sizeof(*msg) + (1 + out_sgs + 1 + in_sgs) * sizeof(*msg->sgs);
+   unsigned int i;
+
+   msg = devm_kzalloc(>dev, msg_size + request_size + response_size,
+  gfp);


Messages are short-lived, right? So, I think their allocation and freeing 
has to be explicit, no need for devm_.



+   if (!msg)
+   return ERR_PTR(-ENOMEM);
+
+   sg_init_one(>sg_request, (u8 *)msg + msg_size, request_size);
+   sg_init_one(>sg_response, (u8 *)msg + msg_size + request_size,
+   response_size);
+
+   INIT_LIST_HEAD(>list);
+   init_completion(>notify);
+   atomic_set(>ref_count, 1);
+
+   msg->sgs[msg->out_sgs++] = >sg_request;
+   if (sgs)
+   for (i = 0; i < out_sgs; ++i)
+   msg->sgs[msg->out_sgs++] = [i];
+
+   msg->sgs[msg->out_sgs + msg->in_sgs++] = >sg_response;
+   if (sgs)
+   for (i = out_sgs; i < out_sgs + in_sgs; ++i)
+   msg->sgs[msg->out_sgs + msg->in_sgs++] = [i];
+
+   return msg;
+}
+
+/**
+ * virtsnd_ctl_msg_send() - Send an (asynchronous) control message.
+ * @snd: VirtIO sound device.
+ * @msg: Control message.
+ *
+ * If a message is failed to be enqueued, it will be deleted. If message 
content
+ * is still needed, the caller must additionally to virtsnd_ctl_msg_ref/unref()
+ * it.
+ *
+ * Context: Any context. Takes and releases the control queue spinlock.
+ * Return: 0 on success, -errno on failure.
+ */
+int virtsnd_ctl_msg_send(struct virtio_snd *snd, struct virtio_snd_msg *msg)
+{
+   struct virtio_device *vdev = snd->vdev;
+   struct virtio_snd_queue *queue = virtsnd_control_queue(snd);

Re: [PATCH v2 2/9] ALSA: virtio: add virtio sound driver

[Guennadi Liakhovetski]

Hi Anton,

A couple of mostly cosmetic comments inline.

On Sun, 24 Jan 2021, Anton Yakovlev wrote:


Introduce skeleton of the virtio sound driver. The driver implements
the virtio sound device specification, which has become part of the
virtio standard.

Initial initialization of the device, virtqueues and creation of an
empty ALSA sound device. Also, handling DEVICE_NEEDS_RESET device
status.

Signed-off-by: Anton Yakovlev 
---
MAINTAINERS |   9 +
include/uapi/linux/virtio_snd.h | 361 +++
sound/Kconfig   |   2 +
sound/Makefile  |   3 +-
sound/virtio/Kconfig|  10 +
sound/virtio/Makefile   |   7 +
sound/virtio/virtio_card.c  | 415 
sound/virtio/virtio_card.h  |  76 ++
8 files changed, 882 insertions(+), 1 deletion(-)
create mode 100644 include/uapi/linux/virtio_snd.h
create mode 100644 sound/virtio/Kconfig
create mode 100644 sound/virtio/Makefile
create mode 100644 sound/virtio/virtio_card.c
create mode 100644 sound/virtio/virtio_card.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 00836f6452f0..3f509d54a457 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -18936,6 +18936,15 @@ W: https://virtio-mem.gitlab.io/
F:  drivers/virtio/virtio_mem.c
F:  include/uapi/linux/virtio_mem.h

+VIRTIO SOUND DRIVER
+M: Anton Yakovlev 
+M: "Michael S. Tsirkin" 
+L: virtualization@lists.linux-foundation.org
+L: alsa-de...@alsa-project.org (moderated for non-subscribers)
+S: Maintained
+F: include/uapi/linux/virtio_snd.h
+F: sound/virtio/*
+
VIRTUAL BOX GUEST DEVICE DRIVER
M:  Hans de Goede 
M:  Arnd Bergmann 
diff --git a/include/uapi/linux/virtio_snd.h b/include/uapi/linux/virtio_snd.h
new file mode 100644
index ..1ff6310e54d6
--- /dev/null
+++ b/include/uapi/linux/virtio_snd.h
@@ -0,0 +1,361 @@
+/* SPDX-License-Identifier: BSD-3-Clause */
+/*
+ * Copyright (C) 2020  OpenSynergy GmbH
+ *
+ * This header is BSD licensed so anyone can use the definitions to
+ * implement compatible drivers/servers.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:


Can a BSD licence actually be further restricted?


+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. Neither the name of OpenSynergy GmbH nor the names of its contributors
+ *may be used to endorse or promote products derived from this software
+ *without specific prior written permission.
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+ * FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL IBM OR


IBM? Also no idea whether this warranty disclaimer is appropriate here. I 
thought we were transitioning to those SPDX identifiers to eliminate all 
these headers.



+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF
+ * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+ * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT
+ * OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */


[snip]


diff --git a/sound/virtio/virtio_card.c b/sound/virtio/virtio_card.c
new file mode 100644
index ..532d823fdf6f
--- /dev/null
+++ b/sound/virtio/virtio_card.c
@@ -0,0 +1,415 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Sound card driver for virtio
+ * Copyright (C) 2020  OpenSynergy GmbH
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.


Same here, I think SPDX means you don't need all this here any more.


+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "virtio_card.h"
+

Re: [PATCH v7 3/3] vhost: add an RPMsg API

[Guennadi Liakhovetski]

Hi Mathieu,

On Fri, Sep 18, 2020 at 09:52:49AM -0600, Mathieu Poirier wrote:
> Good morning,
> 
> On Fri, Sep 18, 2020 at 11:02:29AM +0200, Guennadi Liakhovetski wrote:
> > Hi Mathieu,
> > 
> > On Thu, Sep 17, 2020 at 04:01:38PM -0600, Mathieu Poirier wrote:
> > > On Thu, Sep 10, 2020 at 01:13:51PM +0200, Guennadi Liakhovetski wrote:
> > > > Linux supports running the RPMsg protocol over the VirtIO transport
> > > > protocol, but currently there is only support for VirtIO clients and
> > > > no support for VirtIO servers. This patch adds a vhost-based RPMsg
> > > > server implementation, which makes it possible to use RPMsg over
> > > > VirtIO between guest VMs and the host.
> > > 
> > > I now get the client/server concept you are describing above but that 
> > > happened
> > > only after a lot of mental gymnastics.  If you drop the whole 
> > > client/server
> > > concept and concentrate on what this patch does, things will go better.  
> > > I would
> > > personally go with what you have in the Kconfig: 
> > > 
> > > > + Vhost RPMsg API allows vhost drivers to communicate with 
> > > > VirtIO
> > > > + drivers on guest VMs, using the RPMsg over VirtIO protocol.
> > > 
> > > It is concise but describes exactly what this patch provide.
> > 
> > Ok, thanks, will try to improve.
> > 
> > > > Signed-off-by: Guennadi Liakhovetski 
> > > > 
> > > > ---
> > > >  drivers/vhost/Kconfig   |   7 +
> > > >  drivers/vhost/Makefile  |   3 +
> > > >  drivers/vhost/rpmsg.c   | 370 
> > > >  drivers/vhost/vhost_rpmsg.h |  74 
> > > >  4 files changed, 454 insertions(+)
> > > >  create mode 100644 drivers/vhost/rpmsg.c
> > > >  create mode 100644 drivers/vhost/vhost_rpmsg.h

[snip]

> > > > diff --git a/drivers/vhost/rpmsg.c b/drivers/vhost/rpmsg.c
> > > > new file mode 100644
> > > > index ..0ddee5b5f017
> > > > --- /dev/null
> > > > +++ b/drivers/vhost/rpmsg.c
> > > > @@ -0,0 +1,370 @@

[snip]

> > > > +/*
> > > > + * Return false to terminate the external loop only if we fail to 
> > > > obtain either
> > > > + * a request or a response buffer
> > > > + */
> > > > +static bool handle_rpmsg_req_single(struct vhost_rpmsg *vr,
> > > > +   struct vhost_virtqueue *vq)
> > > > +{
> > > > +   struct vhost_rpmsg_iter iter;
> > > > +   int ret = vhost_rpmsg_start_lock(vr, , 
> > > > VIRTIO_RPMSG_REQUEST, -EINVAL);
> > > > +   if (!ret)
> > > > +   ret = vhost_rpmsg_finish_unlock(vr, );
> > > > +   if (ret < 0) {
> > > > +   if (ret != -EAGAIN)
> > > > +   vq_err(vq, "%s(): RPMSG processing failed %d\n",
> > > > +  __func__, ret);
> > > > +   return false;
> > > > +   }
> > > > +
> > > > +   if (!iter.ept->write)
> > > > +   return true;
> > > > +
> > > > +   ret = vhost_rpmsg_start_lock(vr, , VIRTIO_RPMSG_RESPONSE, 
> > > > -EINVAL);
> > > > +   if (!ret)
> > > > +   ret = vhost_rpmsg_finish_unlock(vr, );
> > > > +   if (ret < 0) {
> > > > +   vq_err(vq, "%s(): RPMSG finalising failed %d\n", 
> > > > __func__, ret);
> > > > +   return false;
> > > > +   }
> > > 
> > > As I said before dealing with the "response" queue here seems to be 
> > > introducing
> > > coupling with vhost_rpmsg_start_lock()...  Endpoints should be doing that.
> > 
> > Sorry, could you elaborate a bit, what do you mean by coupling?
> 
> In function vhost_rpmsg_start_lock() the rpmsg header is prepared for a 
> response
> at the end of the processing associated with the reception of a
> VIRTIO_RPMSG_REQUEST.  I assumed (perhaps wrongly) that such as response was
> sent here.  In that case preparing the response and sending the response 
> should
> be done at the same place.

This will change in the next version, in it I'll remove response preparation 
from 
request handling.

> But my assumption may be completely wrong... A better question should pr

Re: [PATCH v6 0/4] Add a vhost RPMsg API

[Guennadi Liakhovetski]

On Fri, Sep 18, 2020 at 12:39:07PM +0200, Vincent Whitchurch wrote:
> On Fri, Sep 18, 2020 at 11:47:20AM +0200, Guennadi Liakhovetski wrote:
> > On Fri, Sep 18, 2020 at 09:47:45AM +0200, Arnaud POULIQUEN wrote:
> > > IMO, as this API is defined in the Linux documentation [5] we should 
> > > respect it, to ensure
> > > one generic implementation. The RPMsg sample client[4] uses this user 
> > > API, so seems to me
> > > a good candidate to verify this. 
> > > 
> > > That's said, shall we multiple the RPMsg implementations in Linux with 
> > > several APIs,
> > > With the risk to make the RPMsg clients devices dependent on these 
> > > implementations?
> > > That could lead to complex code or duplications...
> > 
> > So, no, in my understanding there aren't two competing alternative APIs, 
> > you'd never have 
> > to choose between them. If you're writing a driver for Linux to communicate 
> > with remote 
> > processors or to run on VMs, you use the existing API. If you're writing a 
> > driver for 
> > Linux to communicate with those VMs, you use the vhost API and whatever 
> > help is available 
> > for RPMsg processing.
> > 
> > However, I can in principle imagine a single driver, written to work on 
> > both sides. 
> > Something like the rpmsg_char.c or maybe some networking driver. Is that 
> > what you're 
> > referring to? I can see that as a fun exercise, but are there any real uses 
> > for that? 
> 
> I hinted at a real use case for this in the previous mail thread[0].
> I'm exploring using rpmsg-char to allow communication between two chips,
> both running Linux.  rpmsg-char can be used pretty much as-is for both
> sides of the userspace-to-userspace communication and (the userspace
> side of the) userspace-to-kernel communication between the two chips.
> 
> > You could do the same with VirtIO, however, it has been decided to go with 
> > two 
> > distinct APIs: virtio for guests and vhost for the host, noone bothered to 
> > create a 
> > single API for both and nobody seems to miss one. Why would we want one 
> > with RPMsg?
> 
> I think I answered this question in the previous mail thread as well[1]:
> | virtio has distinct driver and device roles so the completely different
> | APIs on each side are understandable.  But I don't see that distinction
> | in the rpmsg API which is why it seems like a good idea to me to make it
> | work from both sides of the link and allow the reuse of drivers like
> | rpmsg-char, instead of imposing virtio's distinction on rpmsg.

I think RPMsg is lacking real established documentation... Quating from [2]:


In the current protocol, at startup, the master sends notification to remote to 
let it 
know that it can receive name service announcement.


Isn't that a sufficient asymnetry?

Thanks
Guennadi

[2] https://github.com/OpenAMP/open-amp/wiki/RPMsg-Messaging-Protocol

> 
> [0] https://www.spinics.net/lists/linux-virtualization/msg43799.html
> [1] https://www.spinics.net/lists/linux-virtualization/msg43802.html
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v6 0/4] Add a vhost RPMsg API

[Guennadi Liakhovetski]

Hi Arnaud,

On Fri, Sep 18, 2020 at 09:47:45AM +0200, Arnaud POULIQUEN wrote:
> Hi Guennadi,
> 
> On 9/18/20 7:44 AM, Guennadi Liakhovetski wrote:
> > Hi Arnaud,
> > 
> > On Thu, Sep 17, 2020 at 05:21:02PM +0200, Arnaud POULIQUEN wrote:
> >> Hi Guennadi,
> >>
> >>> -----Original Message-
> >>> From: Guennadi Liakhovetski 
> >>> Sent: jeudi 17 septembre 2020 07:47
> >>> To: Arnaud POULIQUEN 
> >>> Cc: k...@vger.kernel.org; linux-remotep...@vger.kernel.org;
> >>> virtualization@lists.linux-foundation.org; sound-open-firmware@alsa-
> >>> project.org; Pierre-Louis Bossart ; 
> >>> Liam
> >>> Girdwood ; Michael S. Tsirkin
> >>> ; Jason Wang ; Ohad Ben-Cohen
> >>> ; Bjorn Andersson ; Mathieu
> >>> Poirier ; Vincent Whitchurch
> >>> 
> >>> Subject: Re: [PATCH v6 0/4] Add a vhost RPMsg API
> >>>
> >>> Hi Arnaud,
> >>>
> >>> On Tue, Sep 15, 2020 at 02:13:23PM +0200, Arnaud POULIQUEN wrote:
> >>>> Hi  Guennadi,
> >>>>
> >>>> On 9/1/20 5:11 PM, Guennadi Liakhovetski wrote:
> >>>>> 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 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. 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, 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
> >>> been several side discussions and patch sets.
> >>>
> >>>> Regarding your patchset, it is quite confusing for me. It seems that
> >>>> you implement your own protocol on top of vhost forked from the RPMsg
> >>> one.
> >>>> But look to me that it is not the RPMsg protocol.
> >>>
> >>> I'm implementing a counterpart to the rpmsg protocol over VirtIO as 
> >>> initially
> >>> implemented by drivers/rpmsg/virtio_rpmsg_bus.c for the "main CPU" (in 
> >>> case
> >>> of remoteproc over VirtIO) or the guest side in case of Linux 
> >>> virtualisation.
> >>> Since my implementation can talk to that driver, I don't think, that I'm 
> >>> inventing
> >>> a new protocol. I'm adding support for the same protocol for the opposite 
> >>> side
> >>> of the VirtIO divide.
> >>
> >> The main point I would like to highlight here is related to the use of the 
> >> name "RPMsg"
> >> more than how you implement your IPC protocol.
> >> If It is a counterpart, it probably does not respect interface for RPMsg 
> >> clients.
> &g

Re: [PATCH v7 3/3] vhost: add an RPMsg API

[Guennadi Liakhovetski]

Hi Mathieu,

On Thu, Sep 17, 2020 at 04:01:38PM -0600, Mathieu Poirier wrote:
> On Thu, Sep 10, 2020 at 01:13:51PM +0200, Guennadi Liakhovetski wrote:
> > Linux supports running the RPMsg protocol over the VirtIO transport
> > protocol, but currently there is only support for VirtIO clients and
> > no support for VirtIO servers. This patch adds a vhost-based RPMsg
> > server implementation, which makes it possible to use RPMsg over
> > VirtIO between guest VMs and the host.
> 
> I now get the client/server concept you are describing above but that happened
> only after a lot of mental gymnastics.  If you drop the whole client/server
> concept and concentrate on what this patch does, things will go better.  I 
> would
> personally go with what you have in the Kconfig: 
> 
> > + Vhost RPMsg API allows vhost drivers to communicate with VirtIO
> > + drivers on guest VMs, using the RPMsg over VirtIO protocol.
> 
> It is concise but describes exactly what this patch provide.

Ok, thanks, will try to improve.

> > Signed-off-by: Guennadi Liakhovetski 
> > ---
> >  drivers/vhost/Kconfig   |   7 +
> >  drivers/vhost/Makefile  |   3 +
> >  drivers/vhost/rpmsg.c   | 370 
> >  drivers/vhost/vhost_rpmsg.h |  74 
> >  4 files changed, 454 insertions(+)
> >  create mode 100644 drivers/vhost/rpmsg.c
> >  create mode 100644 drivers/vhost/vhost_rpmsg.h
> > 
> > diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
> > index 587fbae06182..ee1a19b7ab3d 100644
> > --- a/drivers/vhost/Kconfig
> > +++ b/drivers/vhost/Kconfig
> > @@ -38,6 +38,13 @@ config VHOST_NET
> >   To compile this driver as a module, choose M here: the module will
> >   be called vhost_net.
> >  
> > +config VHOST_RPMSG
> > +   tristate
> > +   select VHOST
> > +   help
> > + Vhost RPMsg API allows vhost drivers to communicate with VirtIO
> > + drivers on guest VMs, using the RPMsg over VirtIO protocol.
> > +
> 
> I suppose you intend this to be selectable from another config option?

yes.

> >  config VHOST_SCSI
> > tristate "VHOST_SCSI TCM fabric driver"
> > depends on TARGET_CORE && EVENTFD
> > diff --git a/drivers/vhost/Makefile b/drivers/vhost/Makefile
> > index f3e1897cce85..9cf459d59f97 100644
> > --- a/drivers/vhost/Makefile
> > +++ b/drivers/vhost/Makefile
> > @@ -2,6 +2,9 @@
> >  obj-$(CONFIG_VHOST_NET) += vhost_net.o
> >  vhost_net-y := net.o
> >  
> > +obj-$(CONFIG_VHOST_RPMSG) += vhost_rpmsg.o
> > +vhost_rpmsg-y := rpmsg.o
> > +
> >  obj-$(CONFIG_VHOST_SCSI) += vhost_scsi.o
> >  vhost_scsi-y := scsi.o
> >  
> > diff --git a/drivers/vhost/rpmsg.c b/drivers/vhost/rpmsg.c
> > new file mode 100644
> > index ..0ddee5b5f017
> > --- /dev/null
> > +++ b/drivers/vhost/rpmsg.c
> > @@ -0,0 +1,370 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright(c) 2020 Intel Corporation. All rights reserved.
> > + *
> > + * Author: Guennadi Liakhovetski 
> > + *
> > + * Vhost RPMsg VirtIO interface provides a set of functions to be used on 
> > the
> > + * host side as a counterpart to the guest side RPMsg VirtIO API, provided 
> > by
> > + * drivers/rpmsg/virtio_rpmsg_bus.c. This API can be used by any vhost 
> > driver to
> > + * handle RPMsg specific virtqueue processing.
> > + * Vhost drivers, using this API will use their own VirtIO device IDs, that
> > + * should then also be added to the ID table in virtio_rpmsg_bus.c
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> 
> As far as I can tell the above two are not needed.

Look like left-over, will remove.

> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "vhost.h"
> > +#include "vhost_rpmsg.h"
> > +
> > +/*
> > + * All virtio-rpmsg virtual queue kicks always come with just one buffer -
> > + * either input or output, but we can also handle split messages
> > + */
> > +static int vhost_rpmsg_get_msg(struct vhost_virtqueue *vq, unsigned int 
> > *cnt)
> > +{
> > +   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), , 
> > ,
> > +NULL, NULL);
> > +   if (head < 0) {
> > +   vq_err(vq

Re: [PATCH v7 3/3] vhost: add an RPMsg API

[Guennadi Liakhovetski]

Hi Vincent,

On Thu, Sep 17, 2020 at 10:55:59AM +0200, Vincent Whitchurch wrote:
> On Thu, Sep 10, 2020 at 01:13:51PM +0200, Guennadi Liakhovetski wrote:
> > +int vhost_rpmsg_start_lock(struct vhost_rpmsg *vr, struct vhost_rpmsg_iter 
> > *iter,
> > +  unsigned int qid, ssize_t len)
> > +   __acquires(vq->mutex)
> > +{
> > +   struct vhost_virtqueue *vq = vr->vq + qid;
> > +   unsigned int cnt;
> > +   ssize_t ret;
> > +   size_t tmp;
> > +
> > +   if (qid >= VIRTIO_RPMSG_NUM_OF_VQS)
> > +   return -EINVAL;
> > +
> > +   iter->vq = vq;
> > +
> > +   mutex_lock(>mutex);
> > +   vhost_disable_notify(>dev, vq);
> > +
> > +   iter->head = vhost_rpmsg_get_msg(vq, );
> > +   if (iter->head == vq->num)
> > +   iter->head = -EAGAIN;
> > +
> > +   if (iter->head < 0) {
> > +   ret = iter->head;
> > +   goto unlock;
> > +   }
> > +
> [...]
> > +
> > +return_buf:
> > +   vhost_add_used(vq, iter->head, 0);
> > +unlock:
> > +   vhost_enable_notify(>dev, vq);
> > +   mutex_unlock(>mutex);
> > +
> > +   return ret;
> > +}
> 
> There is a race condition here.  New buffers could have been added while
> notifications were disabled (between vhost_disable_notify() and
> vhost_enable_notify()), so the other vhost drivers check the return
> value of vhost_enable_notify() and rerun their work loops if it returns
> true.  This driver doesn't do that so it stops processing requests if
> that condition hits.

You're right, thanks for spotting this!

> Something like the below seems to fix it but the correct fix could maybe
> involve changing this API to account for this case so that it looks more
> like the code in other vhost drivers.

I'll try to use your proposed code, we'll see if it turns out incorrect.

> diff --git a/drivers/vhost/rpmsg.c b/drivers/vhost/rpmsg.c
> index 7c753258d42..673dd4ec865 100644
> --- a/drivers/vhost/rpmsg.c
> +++ b/drivers/vhost/rpmsg.c
> @@ -302,8 +302,14 @@ static void handle_rpmsg_req_kick(struct vhost_work 
> *work)
>   struct vhost_virtqueue *vq = container_of(work, struct vhost_virtqueue,
> poll.work);
>   struct vhost_rpmsg *vr = container_of(vq->dev, struct vhost_rpmsg, dev);
> + struct vhost_virtqueue *reqvq = vr->vq + VIRTIO_RPMSG_REQUEST;

This is only called on the request queue, so, we can just use vq here.

>  
> - while (handle_rpmsg_req_single(vr, vq))
> + /*
> +  * The !vhost_vq_avail_empty() check is needed since the vhost_rpmsg*
> +  * APIs don't check the return value of vhost_enable_notify() and retry
> +  * if there were buffers added while notifications were disabled.
> +  */
> + while (handle_rpmsg_req_single(vr, vq) || 
> !vhost_vq_avail_empty(reqvq->dev, reqvq))
>   ;
>  }

Thanks
Guennadi
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v6 0/4] Add a vhost RPMsg API

[Guennadi Liakhovetski]

Hi Arnaud,

On Thu, Sep 17, 2020 at 05:21:02PM +0200, Arnaud POULIQUEN wrote:
> Hi Guennadi,
> 
> > -Original Message-
> > From: Guennadi Liakhovetski 
> > Sent: jeudi 17 septembre 2020 07:47
> > To: Arnaud POULIQUEN 
> > Cc: k...@vger.kernel.org; linux-remotep...@vger.kernel.org;
> > virtualization@lists.linux-foundation.org; sound-open-firmware@alsa-
> > project.org; Pierre-Louis Bossart ; 
> > Liam
> > Girdwood ; Michael S. Tsirkin
> > ; Jason Wang ; Ohad Ben-Cohen
> > ; Bjorn Andersson ; Mathieu
> > Poirier ; Vincent Whitchurch
> > 
> > Subject: Re: [PATCH v6 0/4] Add a vhost RPMsg API
> > 
> > Hi Arnaud,
> > 
> > On Tue, Sep 15, 2020 at 02:13:23PM +0200, Arnaud POULIQUEN wrote:
> > > Hi  Guennadi,
> > >
> > > On 9/1/20 5:11 PM, Guennadi Liakhovetski wrote:
> > > > 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 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. 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, 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
> > been several side discussions and patch sets.
> > 
> > > Regarding your patchset, it is quite confusing for me. It seems that
> > > you implement your own protocol on top of vhost forked from the RPMsg
> > one.
> > > But look to me that it is not the RPMsg protocol.
> > 
> > I'm implementing a counterpart to the rpmsg protocol over VirtIO as 
> > initially
> > implemented by drivers/rpmsg/virtio_rpmsg_bus.c for the "main CPU" (in case
> > of remoteproc over VirtIO) or the guest side in case of Linux 
> > virtualisation.
> > Since my implementation can talk to that driver, I don't think, that I'm 
> > inventing
> > a new protocol. I'm adding support for the same protocol for the opposite 
> > side
> > of the VirtIO divide.
> 
> The main point I would like to highlight here is related to the use of the 
> name "RPMsg"
> more than how you implement your IPC protocol.
> If It is a counterpart, it probably does not respect interface for RPMsg 
> clients.
> A good way to answer this, might be to respond to this question:
> Is the rpmsg sample client[4] can be used on top of your vhost RPMsg 
> implementation?
> If the response is no, describe it as a RPMsg implementation could lead to 
> confusion...

Sorry, I don't quite understand your logic. RPMsg is a communication protocol, 
not an 
API. An RPMsg implementation has to be able to communicate with other compliant 
RPMsg 
implementations, it doesn't have to provide any specific API. Am I missing 
anything?

Thanks
Guennadi

> [4] 
> https://elixir.bootlin.com/linux/v5.9-rc5/source/samples/rpmsg/rpmsg_client_sample.c
> 
> Regards,
> Arnaud
> 
> > 
> > > So i would be agree with Vincent[2] which proposed to switch on a
> > > RPMsg API and creating a vhost

Re: [PATCH v6 0/4] Add a vhost RPMsg API

[Guennadi Liakhovetski]

Hi Vincent,

On Thu, Sep 17, 2020 at 10:36:44AM +0200, Vincent Whitchurch wrote:
> On Thu, Sep 17, 2020 at 07:47:06AM +0200, Guennadi Liakhovetski wrote:
> > On Tue, Sep 15, 2020 at 02:13:23PM +0200, Arnaud POULIQUEN wrote:
> > > So i would be agree with Vincent[2] which proposed to switch on a RPMsg 
> > > API
> > > and creating a vhost rpmsg device. This is also proposed in the 
> > > "Enhance VHOST to enable SoC-to-SoC communication" RFC[3].
> > > Do you think that this alternative could match with your need?
> > 
> > As I replied to Vincent, I understand his proposal and the approach taken 
> > in the series [3], but I'm not sure I agree, that adding yet another 
> > virtual device / driver layer on the vhost side is a good idea. As far as 
> > I understand adding new completely virtual devices isn't considered to be 
> > a good practice in the kernel. Currently vhost is just a passive "library" 
> > and my vhost-rpmsg support keeps it that way. Not sure I'm in favour of 
> > converting vhost to a virtual device infrastructure.
> 
> I know it wasn't what you meant, but I noticed that the above paragraph
> could be read as if my suggestion was to convert vhost to a virtual
> device infrastructure, so I just want to clarify that that those are not
> related.  The only similarity between what I suggested in the thread in
> [2] and Kishon's RFC in [3] is that both involve creating a generic
> vhost-rpmsg driver which would allow the RPMsg API to be used for both
> sides of the link, instead of introducing a new API just for the server
> side.  That can be done without rewriting drivers/vhost/.

Thanks for the clarification. Another flexibility, that I'm trying to preserve 
with my approach is keeping direct access to iovec style data buffers for 
cases where that's the structure, that's already used by the respective 
driver on the host side. Since we already do packing and unpacking on the 
guest / client side, we don't need the same on the host / server side again.

Thanks
Guennadi

> > > [1]. 
> > > https://patchwork.kernel.org/project/linux-remoteproc/list/?series=338335 
> > > [2]. https://www.spinics.net/lists/linux-virtualization/msg44195.html
> > > [3]. https://www.spinics.net/lists/linux-remoteproc/msg06634.html  
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v6 0/4] Add a vhost RPMsg API

[Guennadi Liakhovetski]

Hi Arnaud,

On Tue, Sep 15, 2020 at 02:13:23PM +0200, Arnaud POULIQUEN wrote:
> Hi  Guennadi,
> 
> On 9/1/20 5:11 PM, Guennadi Liakhovetski wrote:
> > 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 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. 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, 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 been several side discussions and patch sets.

> Regarding your patchset, it is quite confusing for me. It seems that you
> implement your own protocol on top of vhost forked from the RPMsg one.
> But look to me that it is not the RPMsg protocol.

I'm implementing a counterpart to the rpmsg protocol over VirtIO as 
initially implemented by drivers/rpmsg/virtio_rpmsg_bus.c for the "main 
CPU" (in case of remoteproc over VirtIO) or the guest side in case of 
Linux virtualisation. Since my implementation can talk to that driver, 
I don't think, that I'm inventing a new protocol. I'm adding support 
for the same protocol for the opposite side of the VirtIO divide.

> So i would be agree with Vincent[2] which proposed to switch on a RPMsg API
> and creating a vhost rpmsg device. This is also proposed in the 
> "Enhance VHOST to enable SoC-to-SoC communication" RFC[3].
> Do you think that this alternative could match with your need?

As I replied to Vincent, I understand his proposal and the approach taken 
in the series [3], but I'm not sure I agree, that adding yet another 
virtual device / driver layer on the vhost side is a good idea. As far as 
I understand adding new completely virtual devices isn't considered to be 
a good practice in the kernel. Currently vhost is just a passive "library" 
and my vhost-rpmsg support keeps it that way. Not sure I'm in favour of 
converting vhost to a virtual device infrastructure.

Thanks for pointing me out at [3], I should have a better look at it.

Thanks
Guennadi

> [1]. 
> https://patchwork.kernel.org/project/linux-remoteproc/list/?series=338335 
> [2]. https://www.spinics.net/lists/linux-virtualization/msg44195.html
> [3]. https://www.spinics.net/lists/linux-remoteproc/msg06634.html  
> 
> Thanks,
> Arnaud
> 
> > 
> > Thanks
> > Guennadi
> > 
> > Guennadi Liakhovetski (4):
> >   vhost: convert VHOST_VSOCK_SET_RUNNING to a generic ioctl
> >   rpmsg: move common structures and defines to headers
> >   rpmsg: update documentation
> >   vhost: add an RPMsg API
> > 
> >  Documentation/rpmsg.txt  |   6 +-
> >  drivers/rpmsg/virtio_rpmsg_bus.c |  78 +--
> >  drivers/vhost/Kconfig|   7 +
> >  drivers/vhost/Makefile   |   3 +
> >  drivers/vhost/rpmsg.c| 373 +++
> >  drivers/vhost/vhost_rpmsg.h  |  74 ++
> >  include/linux/rpmsg/virtio.h |  83 +++
> >  include/uapi/linux/rpmsg.h   |   3 +
> >  include/uapi/linux/vhost.h   |   4 +-
> >  9 files changed, 551 insertions(+), 80 deletions(-)
> >  create mode 100644 drivers/vhost/rpmsg.c
> >  create mode 100644 drivers/vhost/vhost_rpmsg.h
> >  create mode 100644 include/linux/rpmsg/virtio.h
> > 
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v5 4/4] vhost: add an RPMsg API

[Guennadi Liakhovetski]

On Fri, Sep 11, 2020 at 11:33:13AM -0600, Mathieu Poirier wrote:
> On Fri, Sep 11, 2020 at 09:46:56AM +0200, Guennadi Liakhovetski wrote:
> > Hi Mathieu,
> > 
> > On Thu, Sep 10, 2020 at 11:22:11AM -0600, Mathieu Poirier wrote:
> > > Good morning Guennadi,
> > > 
> > > On Thu, Sep 10, 2020 at 10:38:54AM +0200, Guennadi Liakhovetski wrote:
> > > > Hi Mathieu,
> > > > 
> > > > On Wed, Sep 09, 2020 at 04:39:46PM -0600, Mathieu Poirier wrote:
> > > > > Good afternoon,
> > > > > 
> > > > > On Wed, Aug 26, 2020 at 07:46:36PM +0200, Guennadi Liakhovetski wrote:
> > > > > > Linux supports running the RPMsg protocol over the VirtIO transport
> > > > > > protocol, but currently there is only support for VirtIO clients and
> > > > > > no support for a VirtIO server. This patch adds a vhost-based RPMsg
> > > > > > server implementation.
> > > > > 
> > > > > This changelog is very confusing...  At this time the name service in 
> > > > > the
> > > > > remoteproc space runs as a server on the application processor.  But 
> > > > > from the
> > > > > above the remoteproc usecase seems to be considered to be a client
> > > > > configuration.
> > > > 
> > > > I agree that this isn't very obvious. But I think it is common to call 
> > > > the 
> > > > host "a server" and guests "clients." E.g. in vhost.c in the 
> > > > top-of-thefile 
> > > > comment:
> > > 
> > > Ok - that part we agree on.
> > > 
> > > > 
> > > >  * Generic code for virtio server in host kernel.
> > > > 
> > > > I think the generic concept behind this notation is, that as guests 
> > > > boot, 
> > > > they send their requests to the host, e.g. VirtIO device drivers on 
> > > > guests 
> > > > send requests over VirtQueues to VirtIO servers on the host, which can 
> > > > run 
> > > > either in the user- or in the kernel-space. And I think you can follow 
> > > > that 
> > > 
> > > I can see that process taking place.  After all virtIO devices on guests 
> > > are
> > > only stubs that need host support for access to HW.
> > > 
> > > > logic in case of devices or remote processors too: it's the main CPU(s) 
> > > > that boot(s) and start talking to devices and remote processors, so in 
> > > > that 
> > > > sence devices are servers and the CPUs are their clients.
> > > 
> > > In the remote processor case, the remoteproc core (application processor) 
> > > sets up
> > > the name service but does not initiate the communication with a remote
> > > processor.  It simply waits there for a name space request to come in 
> > > from the
> > > remote processor.
> > 
> > Hm, I don't see that in two examples, that I looked at: mtk and virtio. In 
> > both 
> > cases the announcement seems to be directly coming from the application 
> > processor 
> > maybe after some initialisation.
>  
> Can you expand on that part - perhaps point me to the (virtio) code you are
> referring to? 

Ok, we're both right: it goes both ways.

Here's my understanding of the control flow of virtio_rpmsg_bus.c:

1. The driver registers a VirtIO driver with the VIRTIO_ID_RPMSG ID.
2. When the driver is probed, if the server / the application processor 
supports the 
   VIRTIO_RPMSG_F_NS feature, the driver calls __rpmsg_create_ept() to create 
an 
   endpoint with rpmsg_ns_cb() as a callback.
3. When a namespace announcement arrives from the server, the callback is 
called, 
   which then registers a new channel (in case of CREATE). That then created an
   rpmsg device.
4. If there's a matching rpmsg driver for that device, it's .probe() method is 
   called, so it can then add its own rpmsg endpoints, to be used for its 
proper 
   communication.

Now there was indeed something in virtio_rpmsg_bus.c that I didn't fully 
understand: 
virtio_rpmsg_announce_create() and virtio_rpmsg_announce_destroy() functions. 
Now I 
understood, that as the client registers its custom channels, it also then can 
send name service announcements to the application processor, using those 
functions. 
This is also described in [1] as:


Name Service sub-component (optional)

This subcomponent is a minimum implementation of the name service which is 
present 
in the Linux Kernel implementation of RPMsg. It allows the communicating node 
both 
to send

Re: [PATCH v5 1/4] vhost: convert VHOST_VSOCK_SET_RUNNING to a generic ioctl

[Guennadi Liakhovetski]

On Thu, Sep 10, 2020 at 10:46:43AM -0600, Mathieu Poirier wrote:
> On Thu, Sep 10, 2020 at 09:15:13AM +0200, Guennadi Liakhovetski wrote:
> > Hi Mathieu,
> > 
> > On Wed, Sep 09, 2020 at 04:42:14PM -0600, Mathieu Poirier wrote:
> > > On Wed, Aug 26, 2020 at 07:46:33PM +0200, Guennadi Liakhovetski wrote:
> > > > VHOST_VSOCK_SET_RUNNING is used by the vhost vsock driver to perform
> > > > crucial VirtQueue initialisation, like assigning .private fields and
> > > > calling vhost_vq_init_access(), and clean up. However, this ioctl is
> > > > actually extremely useful for any vhost driver, that doesn't have a
> > > > side channel to inform it of a status change, e.g. upon a guest
> > > > reboot. This patch makes that ioctl generic, while preserving its
> > > > numeric value and also keeping the original alias.
> > > > 
> > > > Signed-off-by: Guennadi Liakhovetski 
> > > > 
> > > > ---
> > > >  include/uapi/linux/vhost.h | 4 +++-
> > > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/include/uapi/linux/vhost.h b/include/uapi/linux/vhost.h
> > > > index 75232185324a..11a4948b6216 100644
> > > > --- a/include/uapi/linux/vhost.h
> > > > +++ b/include/uapi/linux/vhost.h
> > > > @@ -97,6 +97,8 @@
> > > >  #define VHOST_SET_BACKEND_FEATURES _IOW(VHOST_VIRTIO, 0x25, __u64)
> > > >  #define VHOST_GET_BACKEND_FEATURES _IOR(VHOST_VIRTIO, 0x26, __u64)
> > > >  
> > > > +#define VHOST_SET_RUNNING _IOW(VHOST_VIRTIO, 0x61, int)
> > > > +
> > > 
> > > I don't see it used in the next patches and as such should be part of 
> > > another
> > > series.
> > 
> > It isn't used in the next patches, it is used in this patch - see below.
> >
> 
> Right, but why is this part of this set?  What does it bring?  It should be 
> part
> of a patchset where "VHOST_SET_RUNNING" is used.

Ok, I can remove this patch from this series and make it a part of the series, 
containing [1] "vhost: add an SOF Audio DSP driver"

Thanks
Guennadi

[1] https://www.spinics.net/lists/linux-virtualization/msg43309.html

> > > >  /* VHOST_NET specific defines */
> > > >  
> > > >  /* Attach virtio net ring to a raw socket, or tap device.
> > > > @@ -118,7 +120,7 @@
> > > >  /* VHOST_VSOCK specific defines */
> > > >  
> > > >  #define VHOST_VSOCK_SET_GUEST_CID  _IOW(VHOST_VIRTIO, 0x60, __u64)
> > > > -#define VHOST_VSOCK_SET_RUNNING_IOW(VHOST_VIRTIO, 
> > > > 0x61, int)
> > > > +#define VHOST_VSOCK_SET_RUNNINGVHOST_SET_RUNNING
> > > >  
> > > >  /* VHOST_VDPA specific defines */
> > > >  
> > > > -- 
> > > > 2.28.0
> > > > 
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v5 4/4] vhost: add an RPMsg API

[Guennadi Liakhovetski]

Hi Mathieu,

On Thu, Sep 10, 2020 at 11:22:11AM -0600, Mathieu Poirier wrote:
> Good morning Guennadi,
> 
> On Thu, Sep 10, 2020 at 10:38:54AM +0200, Guennadi Liakhovetski wrote:
> > Hi Mathieu,
> > 
> > On Wed, Sep 09, 2020 at 04:39:46PM -0600, Mathieu Poirier wrote:
> > > Good afternoon,
> > > 
> > > On Wed, Aug 26, 2020 at 07:46:36PM +0200, Guennadi Liakhovetski wrote:
> > > > Linux supports running the RPMsg protocol over the VirtIO transport
> > > > protocol, but currently there is only support for VirtIO clients and
> > > > no support for a VirtIO server. This patch adds a vhost-based RPMsg
> > > > server implementation.
> > > 
> > > This changelog is very confusing...  At this time the name service in the
> > > remoteproc space runs as a server on the application processor.  But from 
> > > the
> > > above the remoteproc usecase seems to be considered to be a client
> > > configuration.
> > 
> > I agree that this isn't very obvious. But I think it is common to call the 
> > host "a server" and guests "clients." E.g. in vhost.c in the top-of-thefile 
> > comment:
> 
> Ok - that part we agree on.
> 
> > 
> >  * Generic code for virtio server in host kernel.
> > 
> > I think the generic concept behind this notation is, that as guests boot, 
> > they send their requests to the host, e.g. VirtIO device drivers on guests 
> > send requests over VirtQueues to VirtIO servers on the host, which can run 
> > either in the user- or in the kernel-space. And I think you can follow that 
> 
> I can see that process taking place.  After all virtIO devices on guests are
> only stubs that need host support for access to HW.
> 
> > logic in case of devices or remote processors too: it's the main CPU(s) 
> > that boot(s) and start talking to devices and remote processors, so in that 
> > sence devices are servers and the CPUs are their clients.
> 
> In the remote processor case, the remoteproc core (application processor) 
> sets up
> the name service but does not initiate the communication with a remote
> processor.  It simply waits there for a name space request to come in from the
> remote processor.

Hm, I don't see that in two examples, that I looked at: mtk and virtio. In both 
cases the announcement seems to be directly coming from the application 
processor 
maybe after some initialisation.

> > And yes, the name-space announcement use-case seems confusing to me too - 
> > it 
> > reverts the relationship in a way: once a guest has booted and established 
> > 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 attention to this set [1] from Arnaud.  Please have a look as it will
> impact your work.
> 
> https://patchwork.kernel.org/project/linux-remoteproc/list/?series=338335

Yes, I've had a look at that series, thanks for forwarding it to me. TBH I 
don't quite understand some choices there, e.g. creating a separate driver and 
then having to register devices just for the namespace announcement. I don't 
think creating virtual devices is taken easily in Linux. But either way I 
don't think our series conflict a lot, but I do hope that I can merge my 
series first, he'd just have to switch to using the header, that I'm adding. 
Hardly too many changes otherwise.

> > > And I don't see a server implementation per se...  It is more like a 
> > > client
> > > implementation since vhost_rpmsg_announce() uses the RESPONSE queue, 
> > > which sends
> > > messages from host to guest.
> > > 
> > > Perhaps it is my lack of familiarity with vhost terminology.
> > > 
> > > > 
> > > > Signed-off-by: Guennadi Liakhovetski 
> > > > 
> > > > ---
> > > >  drivers/vhost/Kconfig   |   7 +
> > > >  drivers/vhost/Makefile  |   3 +
> > > >  drivers/vhost/rpmsg.c   | 373 
> > > >  drivers/vhost/vhost_rpmsg.h |  74 +++
> > > >  4 files changed, 457 insertions(+)
> > > >  create mode 100644 driv

Re: [PATCH v5 3/4] rpmsg: update documentation

[Guennadi Liakhovetski]

On Thu, Sep 10, 2020 at 09:18:41AM +0200, Guennadi Liakhovetski wrote:
> On Wed, Sep 09, 2020 at 04:45:21PM -0600, Mathieu Poirier wrote:
> > On Wed, Aug 26, 2020 at 07:46:35PM +0200, Guennadi Liakhovetski wrote:
> > > rpmsg_create_ept() takes struct rpmsg_channel_info chinfo as its last
> > > argument, not a u32 value. The first two arguments are also updated.
> > > 
> > > Signed-off-by: Guennadi Liakhovetski 
> > > 
> > > ---
> > >  Documentation/rpmsg.txt | 6 +++---
> > >  1 file changed, 3 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/Documentation/rpmsg.txt b/Documentation/rpmsg.txt
> > > index 24b7a9e1a5f9..1ce353cb232a 100644
> > > --- a/Documentation/rpmsg.txt
> > > +++ b/Documentation/rpmsg.txt
> > > @@ -192,9 +192,9 @@ Returns 0 on success and an appropriate error value 
> > > on failure.
> > >  
> > >  ::
> > >  
> > > -  struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_channel *rpdev,
> > > - void (*cb)(struct rpmsg_channel *, void *, int, void *, u32),
> > > - void *priv, u32 addr);
> > > +  struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_device *rpdev,
> > > +   rpmsg_rx_cb_t cb, void *priv,
> > > +   struct rpmsg_channel_info chinfo);
> > 
> > Again I don't see this being used in this set...  It should have been sent 
> > on
> > its own to the remoteproc and documentation mailing list.  Note that
> > Documentation/rpmsg.txt is now Documentation/staging/rpmsg.rst

But you haven't pulled that change into your tree yet. Should I send as is for 
now 
or wait for you to cherry-pick that change?

> Sure, can send it separately.
> 
> Thanks
> Guennadi
> 
> > >  every rpmsg address in the system is bound to an rx callback (so when
> > >  inbound messages arrive, they are dispatched by the rpmsg bus using the
> > > -- 
> > > 2.28.0
> > > 
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH v7 3/3] vhost: add an RPMsg API

[Guennadi Liakhovetski]

Linux supports running the RPMsg protocol over the VirtIO transport
protocol, but currently there is only support for VirtIO clients and
no support for VirtIO servers. This patch adds a vhost-based RPMsg
server implementation, which makes it possible to use RPMsg over
VirtIO between guest VMs and the host.

Signed-off-by: Guennadi Liakhovetski 
---
 drivers/vhost/Kconfig   |   7 +
 drivers/vhost/Makefile  |   3 +
 drivers/vhost/rpmsg.c   | 370 
 drivers/vhost/vhost_rpmsg.h |  74 
 4 files changed, 454 insertions(+)
 create mode 100644 drivers/vhost/rpmsg.c
 create mode 100644 drivers/vhost/vhost_rpmsg.h

diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
index 587fbae06182..ee1a19b7ab3d 100644
--- a/drivers/vhost/Kconfig
+++ b/drivers/vhost/Kconfig
@@ -38,6 +38,13 @@ config VHOST_NET
  To compile this driver as a module, choose M here: the module will
  be called vhost_net.
 
+config VHOST_RPMSG
+   tristate
+   select VHOST
+   help
+ Vhost RPMsg API allows vhost drivers to communicate with VirtIO
+ drivers on guest VMs, using the RPMsg over VirtIO protocol.
+
 config VHOST_SCSI
tristate "VHOST_SCSI TCM fabric driver"
depends on TARGET_CORE && EVENTFD
diff --git a/drivers/vhost/Makefile b/drivers/vhost/Makefile
index f3e1897cce85..9cf459d59f97 100644
--- a/drivers/vhost/Makefile
+++ b/drivers/vhost/Makefile
@@ -2,6 +2,9 @@
 obj-$(CONFIG_VHOST_NET) += vhost_net.o
 vhost_net-y := net.o
 
+obj-$(CONFIG_VHOST_RPMSG) += vhost_rpmsg.o
+vhost_rpmsg-y := rpmsg.o
+
 obj-$(CONFIG_VHOST_SCSI) += vhost_scsi.o
 vhost_scsi-y := scsi.o
 
diff --git a/drivers/vhost/rpmsg.c b/drivers/vhost/rpmsg.c
new file mode 100644
index ..0ddee5b5f017
--- /dev/null
+++ b/drivers/vhost/rpmsg.c
@@ -0,0 +1,370 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright(c) 2020 Intel Corporation. All rights reserved.
+ *
+ * Author: Guennadi Liakhovetski 
+ *
+ * Vhost RPMsg VirtIO interface provides a set of functions to be used on the
+ * host side as a counterpart to the guest side RPMsg VirtIO API, provided by
+ * drivers/rpmsg/virtio_rpmsg_bus.c. This API can be used by any vhost driver 
to
+ * handle RPMsg specific virtqueue processing.
+ * Vhost drivers, using this API will use their own VirtIO device IDs, that
+ * should then also be added to the ID table in virtio_rpmsg_bus.c
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "vhost.h"
+#include "vhost_rpmsg.h"
+
+/*
+ * All virtio-rpmsg virtual queue kicks always come with just one buffer -
+ * either input or output, but we can also handle split messages
+ */
+static int vhost_rpmsg_get_msg(struct vhost_virtqueue *vq, unsigned int *cnt)
+{
+   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), , 
,
+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 == >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 == >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 -EINVAL;
+}
+
+static const struct vhost_rpmsg_ept *vhost_rpmsg_ept_find(struct vhost_rpmsg 
*vr, int addr)
+{
+   unsigned int i;
+
+   for (i = 0; i < vr->n_epts; i++)
+   if (vr->ept[i].addr == addr)
+   return vr->ept + i;
+
+   return NULL;
+}
+
+/*
+ * if len < 0, then for reading a request, the complete virtual queue buffer
+ * size is prepared, for sending a response, the length in the iterator is used
+ */
+int vhost_rpmsg_start_lock(struct vhost_rpmsg *vr, struct vhost_rpmsg_iter 
*iter,
+  unsigned int qid, ssize_t len)
+   __acquires(vq->mutex)
+{
+   struct vhost_virtqueue *vq = vr->vq + qid;
+   unsigned int cnt;
+   ssize_t ret;
+   size_t tmp;
+
+   if (qid >= VIRTIO_RPMSG_NUM_OF_VQS)
+   return -EINVAL;
+
+   iter->vq = vq;
+
+   mutex_lock(>mutex);

[PATCH v7 0/3] Add a vhost RPMsg API

[Guennadi Liakhovetski]

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:
- 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. 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, ready
for review and submission, available at
https://github.com/thesofproject/linux/pull/1501/commits

Thanks
Guennadi

Guennadi Liakhovetski (3):
  vhost: convert VHOST_VSOCK_SET_RUNNING to a generic ioctl
  rpmsg: move common structures and defines to headers
  vhost: add an RPMsg API

 drivers/rpmsg/virtio_rpmsg_bus.c |  78 +--
 drivers/vhost/Kconfig|   7 +
 drivers/vhost/Makefile   |   3 +
 drivers/vhost/rpmsg.c| 370 +++
 drivers/vhost/vhost_rpmsg.h  |  74 +++
 include/linux/rpmsg/virtio.h |  83 +++
 include/uapi/linux/rpmsg.h   |   3 +
 include/uapi/linux/vhost.h   |   4 +-
 8 files changed, 545 insertions(+), 77 deletions(-)
 create mode 100644 drivers/vhost/rpmsg.c
 create mode 100644 drivers/vhost/vhost_rpmsg.h
 create mode 100644 include/linux/rpmsg/virtio.h

-- 
2.28.0

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH v7 2/3] rpmsg: move common structures and defines to headers

[Guennadi Liakhovetski]

virtio_rpmsg_bus.c keeps RPMsg protocol structure declarations and
common defines like the ones, needed for name-space announcements,
internal. Move them to common headers instead.

Signed-off-by: Guennadi Liakhovetski 
Reviewed-by: Mathieu Poirier 
---
 drivers/rpmsg/virtio_rpmsg_bus.c | 78 +-
 include/linux/rpmsg/virtio.h | 83 
 include/uapi/linux/rpmsg.h   |  3 ++
 3 files changed, 88 insertions(+), 76 deletions(-)
 create mode 100644 include/linux/rpmsg/virtio.h

diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index 9006fc7f73d0..f39c426f9c5e 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -27,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "rpmsg_internal.h"
 
@@ -70,58 +72,6 @@ struct virtproc_info {
struct rpmsg_endpoint *ns_ept;
 };
 
-/* The feature bitmap for virtio rpmsg */
-#define VIRTIO_RPMSG_F_NS  0 /* RP supports name service notifications */
-
-/**
- * struct rpmsg_hdr - common header for all rpmsg messages
- * @src: source address
- * @dst: destination address
- * @reserved: reserved for future use
- * @len: length of payload (in bytes)
- * @flags: message flags
- * @data: @len bytes of message payload data
- *
- * Every message sent(/received) on the rpmsg bus begins with 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 to publish a new service, or announce
- * about its removal. When we receive these messages, an appropriate
- * rpmsg channel (i.e device) is created/destroyed. In turn, the ->probe()
- * or ->remove() handler of the appropriate rpmsg driver will be invoked
- * (if/as-soon-as one is registered).
- */
-struct rpmsg_ns_msg {
-   char name[RPMSG_NAME_SIZE];
-   __virtio32 addr;
-   __virtio32 flags;
-} __packed;
-
-/**
- * enum rpmsg_ns_flags - dynamic name service announcement flags
- *
- * @RPMSG_NS_CREATE: a new remote service was just created
- * @RPMSG_NS_DESTROY: a known remote service was just destroyed
- */
-enum rpmsg_ns_flags {
-   RPMSG_NS_CREATE = 0,
-   RPMSG_NS_DESTROY= 1,
-};
-
 /**
  * @vrp: the remote processor this channel belongs to
  */
@@ -134,27 +84,6 @@ struct virtio_rpmsg_channel {
 #define to_virtio_rpmsg_channel(_rpdev) \
container_of(_rpdev, struct virtio_rpmsg_channel, rpdev)
 
-/*
- * We're allocating buffers of 512 bytes each for communications. The
- * number of buffers will be computed from the number of buffers supported
- * by the vring, upto a maximum of 512 buffers (256 in each direction).
- *
- * Each buffer will have 16 bytes for the msg header and 496 bytes for
- * the payload.
- *
- * This will utilize a maximum total space of 256KB for the buffers.
- *
- * We might also want to add support for user-provided buffers in time.
- * This will allow bigger buffer size flexibility, and can also be used
- * to achieve zero-copy messaging.
- *
- * Note that these numbers are purely a decision of this driver - we
- * can change this without changing anything in the firmware of the remote
- * processor.
- */
-#define MAX_RPMSG_NUM_BUFS (512)
-#define MAX_RPMSG_BUF_SIZE (512)
-
 /*
  * Local addresses are dynamically allocated on-demand.
  * We do not dynamically assign addresses from the low 1024 range,
@@ -162,9 +91,6 @@ struct virtio_rpmsg_channel {
  */
 #define RPMSG_RESERVED_ADDRESSES   (1024)
 
-/* Address 53 is reserved for advertising remote services */
-#define RPMSG_NS_ADDR  (53)
-
 static void virtio_rpmsg_destroy_ept(struct rpmsg_endpoint *ept);
 static int virtio_rpmsg_send(struct rpmsg_endpoint *ept, void *data, int len);
 static int virtio_rpmsg_sendto(struct rpmsg_endpoint *ept, void *data, int len,
diff --git a/include/linux/rpmsg/virtio.h b/include/linux/rpmsg/virtio.h
new file mode 100644
index ..3ede1a4a68a3
--- /dev/null
+++ b/include/linux/rpmsg/virtio.h
@@ -0,0 +1,83 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _LINUX_RPMSG_VIRTIO_H
+#define _LINUX_RPMSG_VIRTIO_H
+
+#include 
+#include 
+#include 
+
+/**
+ * struct rpmsg_hdr - common header for all rpmsg messages
+ * @src: source address
+ * @dst: destination address
+ * @reserved: reserved for future use
+ * @len: length of payload (in bytes)
+ * @flags: message flags
+ * @data: @len bytes of message payload data
+ *
+ * Every message sent(/received) on the rpmsg bus begins 

[PATCH v7 1/3] vhost: convert VHOST_VSOCK_SET_RUNNING to a generic ioctl

[Guennadi Liakhovetski]

VHOST_VSOCK_SET_RUNNING is used by the vhost vsock driver to perform
crucial VirtQueue initialisation, like assigning .private fields and
calling vhost_vq_init_access(), and clean up. However, this ioctl is
actually extremely useful for any vhost driver, that doesn't have a
side channel to inform it of a status change, e.g. upon a guest
reboot. This patch makes that ioctl generic, while preserving its
numeric value and also keeping the original alias.

Signed-off-by: Guennadi Liakhovetski 
---
 include/uapi/linux/vhost.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/vhost.h b/include/uapi/linux/vhost.h
index 75232185324a..11a4948b6216 100644
--- a/include/uapi/linux/vhost.h
+++ b/include/uapi/linux/vhost.h
@@ -97,6 +97,8 @@
 #define VHOST_SET_BACKEND_FEATURES _IOW(VHOST_VIRTIO, 0x25, __u64)
 #define VHOST_GET_BACKEND_FEATURES _IOR(VHOST_VIRTIO, 0x26, __u64)
 
+#define VHOST_SET_RUNNING _IOW(VHOST_VIRTIO, 0x61, int)
+
 /* VHOST_NET specific defines */
 
 /* Attach virtio net ring to a raw socket, or tap device.
@@ -118,7 +120,7 @@
 /* VHOST_VSOCK specific defines */
 
 #define VHOST_VSOCK_SET_GUEST_CID  _IOW(VHOST_VIRTIO, 0x60, __u64)
-#define VHOST_VSOCK_SET_RUNNING_IOW(VHOST_VIRTIO, 0x61, int)
+#define VHOST_VSOCK_SET_RUNNINGVHOST_SET_RUNNING
 
 /* VHOST_VDPA specific defines */
 
-- 
2.28.0

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v5 4/4] vhost: add an RPMsg API

[Guennadi Liakhovetski]

Hi Mathieu,

On Wed, Sep 09, 2020 at 04:39:46PM -0600, Mathieu Poirier wrote:
> Good afternoon,
> 
> On Wed, Aug 26, 2020 at 07:46:36PM +0200, Guennadi Liakhovetski wrote:
> > Linux supports running the RPMsg protocol over the VirtIO transport
> > protocol, but currently there is only support for VirtIO clients and
> > no support for a VirtIO server. This patch adds a vhost-based RPMsg
> > server implementation.
> 
> This changelog is very confusing...  At this time the name service in the
> remoteproc space runs as a server on the application processor.  But from the
> above the remoteproc usecase seems to be considered to be a client
> configuration.

I agree that this isn't very obvious. But I think it is common to call the 
host "a server" and guests "clients." E.g. in vhost.c in the top-of-thefile 
comment:

 * Generic code for virtio server in host kernel.

I think the generic concept behind this notation is, that as guests boot, 
they send their requests to the host, e.g. VirtIO device drivers on guests 
send requests over VirtQueues to VirtIO servers on the host, which can run 
either in the user- or in the kernel-space. And I think you can follow that 
logic in case of devices or remote processors too: it's the main CPU(s) 
that boot(s) and start talking to devices and remote processors, so in that 
sence devices are servers and the CPUs are their clients.

And yes, the name-space announcement use-case seems confusing to me too - it 
reverts the relationship in a way: once a guest has booted and established 
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.

> And I don't see a server implementation per se...  It is more like a client
> implementation since vhost_rpmsg_announce() uses the RESPONSE queue, which 
> sends
> messages from host to guest.
> 
> Perhaps it is my lack of familiarity with vhost terminology.
> 
> > 
> > Signed-off-by: Guennadi Liakhovetski 
> > ---
> >  drivers/vhost/Kconfig   |   7 +
> >  drivers/vhost/Makefile  |   3 +
> >  drivers/vhost/rpmsg.c   | 373 
> >  drivers/vhost/vhost_rpmsg.h |  74 +++
> >  4 files changed, 457 insertions(+)
> >  create mode 100644 drivers/vhost/rpmsg.c
> >  create mode 100644 drivers/vhost/vhost_rpmsg.h
> > 
> > diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
> > index 587fbae06182..046b948fc411 100644
> > --- a/drivers/vhost/Kconfig
> > +++ b/drivers/vhost/Kconfig
> > @@ -38,6 +38,13 @@ config VHOST_NET
> >   To compile this driver as a module, choose M here: the module will
> >   be called vhost_net.
> >  
> > +config VHOST_RPMSG
> > +   tristate
> > +   select VHOST
> > +   help
> > + Vhost RPMsg API allows vhost drivers to communicate with VirtIO
> > + drivers, using the RPMsg over VirtIO protocol.
> 
> I had to assume vhost drivers are running on the host and virtIO drivers on 
> the
> guests.  This may be common knowledge for people familiar with vhosts but
> certainly obscur for commoners  Having a help section that is clear on what is
> happening would remove any ambiguity.

It is the terminology, yes, but you're right, the wording isn't very clear, 
will 
improve.

> > +
> >  config VHOST_SCSI
> > tristate "VHOST_SCSI TCM fabric driver"
> > depends on TARGET_CORE && EVENTFD
> > diff --git a/drivers/vhost/Makefile b/drivers/vhost/Makefile
> > index f3e1897cce85..9cf459d59f97 100644
> > --- a/drivers/vhost/Makefile
> > +++ b/drivers/vhost/Makefile
> > @@ -2,6 +2,9 @@
> >  obj-$(CONFIG_VHOST_NET) += vhost_net.o
> >  vhost_net-y := net.o
> >  
> > +obj-$(CONFIG_VHOST_RPMSG) += vhost_rpmsg.o
> > +vhost_rpmsg-y := rpmsg.o
> > +
> >  obj-$(CONFIG_VHOST_SCSI) += vhost_scsi.o
> >  vhost_scsi-y := scsi.o
> >  
> > diff --git a/drivers/vhost/rpmsg.c b/drivers/vhost/rpmsg.c
> > new file mode 100644
> > index ..c26d7a4afc6d
> > --- /dev/null
> > +++ b/drivers/vhost/rpmsg.c
> > @@ -0,0 +1,373 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright(c) 2020 Intel Corporation. All rights reserved.
> > + *
> > + * Author: Guennadi Liakhovetski 
> > + *
> > + * Vhost RPMsg VirtIO interface. It provides a set of functions to match 
> > the
> > + * guest side RPMsg VirtIO API, provided by 
> > drivers/rpmsg/virtio_rpmsg_bus.c
> 
> Again, very confusing.  The changelog refe

Re: [PATCH v5 3/4] rpmsg: update documentation

[Guennadi Liakhovetski]

On Wed, Sep 09, 2020 at 04:45:21PM -0600, Mathieu Poirier wrote:
> On Wed, Aug 26, 2020 at 07:46:35PM +0200, Guennadi Liakhovetski wrote:
> > rpmsg_create_ept() takes struct rpmsg_channel_info chinfo as its last
> > argument, not a u32 value. The first two arguments are also updated.
> > 
> > Signed-off-by: Guennadi Liakhovetski 
> > ---
> >  Documentation/rpmsg.txt | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/Documentation/rpmsg.txt b/Documentation/rpmsg.txt
> > index 24b7a9e1a5f9..1ce353cb232a 100644
> > --- a/Documentation/rpmsg.txt
> > +++ b/Documentation/rpmsg.txt
> > @@ -192,9 +192,9 @@ Returns 0 on success and an appropriate error value on 
> > failure.
> >  
> >  ::
> >  
> > -  struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_channel *rpdev,
> > -   void (*cb)(struct rpmsg_channel *, void *, int, void *, u32),
> > -   void *priv, u32 addr);
> > +  struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_device *rpdev,
> > + rpmsg_rx_cb_t cb, void *priv,
> > + struct rpmsg_channel_info chinfo);
> 
> Again I don't see this being used in this set...  It should have been sent on
> its own to the remoteproc and documentation mailing list.  Note that
> Documentation/rpmsg.txt is now Documentation/staging/rpmsg.rst

Sure, can send it separately.

Thanks
Guennadi

> >  every rpmsg address in the system is bound to an rx callback (so when
> >  inbound messages arrive, they are dispatched by the rpmsg bus using the
> > -- 
> > 2.28.0
> > 
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v5 1/4] vhost: convert VHOST_VSOCK_SET_RUNNING to a generic ioctl

[Guennadi Liakhovetski]

Hi Mathieu,

On Wed, Sep 09, 2020 at 04:42:14PM -0600, Mathieu Poirier wrote:
> On Wed, Aug 26, 2020 at 07:46:33PM +0200, Guennadi Liakhovetski wrote:
> > VHOST_VSOCK_SET_RUNNING is used by the vhost vsock driver to perform
> > crucial VirtQueue initialisation, like assigning .private fields and
> > calling vhost_vq_init_access(), and clean up. However, this ioctl is
> > actually extremely useful for any vhost driver, that doesn't have a
> > side channel to inform it of a status change, e.g. upon a guest
> > reboot. This patch makes that ioctl generic, while preserving its
> > numeric value and also keeping the original alias.
> > 
> > Signed-off-by: Guennadi Liakhovetski 
> > ---
> >  include/uapi/linux/vhost.h | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/include/uapi/linux/vhost.h b/include/uapi/linux/vhost.h
> > index 75232185324a..11a4948b6216 100644
> > --- a/include/uapi/linux/vhost.h
> > +++ b/include/uapi/linux/vhost.h
> > @@ -97,6 +97,8 @@
> >  #define VHOST_SET_BACKEND_FEATURES _IOW(VHOST_VIRTIO, 0x25, __u64)
> >  #define VHOST_GET_BACKEND_FEATURES _IOR(VHOST_VIRTIO, 0x26, __u64)
> >  
> > +#define VHOST_SET_RUNNING _IOW(VHOST_VIRTIO, 0x61, int)
> > +
> 
> I don't see it used in the next patches and as such should be part of another
> series.

It isn't used in the next patches, it is used in this patch - see below.

Thanks
Guennadi

> >  /* VHOST_NET specific defines */
> >  
> >  /* Attach virtio net ring to a raw socket, or tap device.
> > @@ -118,7 +120,7 @@
> >  /* VHOST_VSOCK specific defines */
> >  
> >  #define VHOST_VSOCK_SET_GUEST_CID  _IOW(VHOST_VIRTIO, 0x60, __u64)
> > -#define VHOST_VSOCK_SET_RUNNING_IOW(VHOST_VIRTIO, 0x61, int)
> > +#define VHOST_VSOCK_SET_RUNNINGVHOST_SET_RUNNING
> >  
> >  /* VHOST_VDPA specific defines */
> >  
> > -- 
> > 2.28.0
> > 
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v6 2/4] rpmsg: move common structures and defines to headers

[Guennadi Liakhovetski]

Hi Mathieu,

On Wed, Sep 02, 2020 at 11:24:37AM -0600, Mathieu Poirier wrote:
> On Wed, Sep 02, 2020 at 07:35:27AM +0200, Guennadi Liakhovetski wrote:
> > Hi Mathew,
> > 
> > On Tue, Sep 01, 2020 at 11:23:21AM -0600, Mathieu Poirier wrote:
> > > On Tue, Sep 01, 2020 at 05:11:51PM +0200, Guennadi Liakhovetski wrote:
> > > > virtio_rpmsg_bus.c keeps RPMsg protocol structure declarations and
> > > > common defines like the ones, needed for name-space announcements,
> > > > internal. Move them to common headers instead.
> > > > 
> > > > Signed-off-by: Guennadi Liakhovetski 
> > > > 
> > > 
> > > I already reviewed this patch and added my RB to it.  Please carry it in 
> > > your
> > > next revision.
> > 
> > But only as long as the patch doesn't change, right? And in fact it did 
> > change 
> > this time - I renamed the header, moving it under include/linux/rpmsg, 
> > actually 
> 
> Patch 2/4 in V5 was identical to what was submitted in V4 and my RB tag was 
> not
> added, nor was the entry for virtio_rpmsg.h added to the MAINTAINERS file.

Right, yes, I forgot about that your request when creating v5, sorry about 
that, 
that's why I made a v6 with the header moved to include/linux/rpmsg/.

> > also following your suggestion. Still, formally the patch has changed, so, 
> > I 
> > didn't include your "Reviewed-by" in this version. And you anyway would be 
> 
> Reviewed-by: Mathieu Poirier 
> 
> > reviewing the other patches in this series to, right?
> 
> As much as I'd like to reviewing the other patches in this series won't be
> possible at this time. 

Ok, understand, I'm wondering then what the path to upstreaming would be then?

Thanks
Guennadi

> > > Thanks,
> > > Mathieu
> > > 
> > > > ---
> > > >  drivers/rpmsg/virtio_rpmsg_bus.c | 78 +-
> > > >  include/linux/rpmsg/virtio.h | 83 
> > > >  include/uapi/linux/rpmsg.h   |  3 ++
> > > >  3 files changed, 88 insertions(+), 76 deletions(-)
> > > >  create mode 100644 include/linux/rpmsg/virtio.h
> > > > 
> > > > diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c 
> > > > b/drivers/rpmsg/virtio_rpmsg_bus.c
> > > > index 9006fc7f73d0..f39c426f9c5e 100644
> > > > --- a/drivers/rpmsg/virtio_rpmsg_bus.c
> > > > +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
> > > > @@ -19,6 +19,7 @@
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > +#include 
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > @@ -27,6 +28,7 @@
> > > >  #include 
> > > >  #include 
> > > >  #include 
> > > > +#include 
> > > >  
> > > >  #include "rpmsg_internal.h"
> > > >  
> > > > @@ -70,58 +72,6 @@ struct virtproc_info {
> > > > struct rpmsg_endpoint *ns_ept;
> > > >  };
> > > >  
> > > > -/* The feature bitmap for virtio rpmsg */
> > > > -#define VIRTIO_RPMSG_F_NS  0 /* RP supports name service 
> > > > notifications */
> > > > -
> > > > -/**
> > > > - * struct rpmsg_hdr - common header for all rpmsg messages
> > > > - * @src: source address
> > > > - * @dst: destination address
> > > > - * @reserved: reserved for future use
> > > > - * @len: length of payload (in bytes)
> > > > - * @flags: message flags
> > > > - * @data: @len bytes of message payload data
> > > > - *
> > > > - * Every message sent(/received) on the rpmsg bus begins with 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 to publish a ne

Re: [PATCH v6 2/4] rpmsg: move common structures and defines to headers

[Guennadi Liakhovetski]

Hi Mathew,

On Tue, Sep 01, 2020 at 11:23:21AM -0600, Mathieu Poirier wrote:
> On Tue, Sep 01, 2020 at 05:11:51PM +0200, Guennadi Liakhovetski wrote:
> > virtio_rpmsg_bus.c keeps RPMsg protocol structure declarations and
> > common defines like the ones, needed for name-space announcements,
> > internal. Move them to common headers instead.
> > 
> > Signed-off-by: Guennadi Liakhovetski 
> 
> I already reviewed this patch and added my RB to it.  Please carry it in your
> next revision.

But only as long as the patch doesn't change, right? And in fact it did change 
this time - I renamed the header, moving it under include/linux/rpmsg, actually 
also following your suggestion. Still, formally the patch has changed, so, I 
didn't include your "Reviewed-by" in this version. And you anyway would be 
reviewing the other patches in this series to, right?

Thanks
Guennadi

> Thanks,
> Mathieu
> 
> > ---
> >  drivers/rpmsg/virtio_rpmsg_bus.c | 78 +-
> >  include/linux/rpmsg/virtio.h | 83 
> >  include/uapi/linux/rpmsg.h   |  3 ++
> >  3 files changed, 88 insertions(+), 76 deletions(-)
> >  create mode 100644 include/linux/rpmsg/virtio.h
> > 
> > diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c 
> > b/drivers/rpmsg/virtio_rpmsg_bus.c
> > index 9006fc7f73d0..f39c426f9c5e 100644
> > --- a/drivers/rpmsg/virtio_rpmsg_bus.c
> > +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
> > @@ -19,6 +19,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -27,6 +28,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include "rpmsg_internal.h"
> >  
> > @@ -70,58 +72,6 @@ struct virtproc_info {
> > struct rpmsg_endpoint *ns_ept;
> >  };
> >  
> > -/* The feature bitmap for virtio rpmsg */
> > -#define VIRTIO_RPMSG_F_NS  0 /* RP supports name service notifications */
> > -
> > -/**
> > - * struct rpmsg_hdr - common header for all rpmsg messages
> > - * @src: source address
> > - * @dst: destination address
> > - * @reserved: reserved for future use
> > - * @len: length of payload (in bytes)
> > - * @flags: message flags
> > - * @data: @len bytes of message payload data
> > - *
> > - * Every message sent(/received) on the rpmsg bus begins with 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 to publish a new service, or announce
> > - * about its removal. When we receive these messages, an appropriate
> > - * rpmsg channel (i.e device) is created/destroyed. In turn, the ->probe()
> > - * or ->remove() handler of the appropriate rpmsg driver will be invoked
> > - * (if/as-soon-as one is registered).
> > - */
> > -struct rpmsg_ns_msg {
> > -   char name[RPMSG_NAME_SIZE];
> > -   __virtio32 addr;
> > -   __virtio32 flags;
> > -} __packed;
> > -
> > -/**
> > - * enum rpmsg_ns_flags - dynamic name service announcement flags
> > - *
> > - * @RPMSG_NS_CREATE: a new remote service was just created
> > - * @RPMSG_NS_DESTROY: a known remote service was just destroyed
> > - */
> > -enum rpmsg_ns_flags {
> > -   RPMSG_NS_CREATE = 0,
> > -   RPMSG_NS_DESTROY= 1,
> > -};
> > -
> >  /**
> >   * @vrp: the remote processor this channel belongs to
> >   */
> > @@ -134,27 +84,6 @@ struct virtio_rpmsg_channel {
> >  #define to_virtio_rpmsg_channel(_rpdev) \
> > container_of(_rpdev, struct virtio_rpmsg_channel, rpdev)
> >  
> > -/*
> > - * We're allocating buffers of 512 bytes each for communications. The
> > - * number of buffers will be computed from the number of buffers supported
> > - * by the vring, upto a maximum of 512 buffers (256 in each direction).
> > - *
> > - * Each buffer will have 16 bytes for the msg header and 496 bytes for
> > - * the payload.
> > - *
> > - * This will utilize a maximum total space of 256KB for the buffers.
> > - 

[PATCH v6 3/4] rpmsg: update documentation

[Guennadi Liakhovetski]

rpmsg_create_ept() takes struct rpmsg_channel_info chinfo as its last
argument, not a u32 value. The first two arguments are also updated.

Signed-off-by: Guennadi Liakhovetski 
---
 Documentation/rpmsg.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/rpmsg.txt b/Documentation/rpmsg.txt
index 24b7a9e1a5f9..1ce353cb232a 100644
--- a/Documentation/rpmsg.txt
+++ b/Documentation/rpmsg.txt
@@ -192,9 +192,9 @@ Returns 0 on success and an appropriate error value on 
failure.
 
 ::
 
-  struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_channel *rpdev,
-   void (*cb)(struct rpmsg_channel *, void *, int, void *, u32),
-   void *priv, u32 addr);
+  struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_device *rpdev,
+ rpmsg_rx_cb_t cb, void *priv,
+ struct rpmsg_channel_info chinfo);
 
 every rpmsg address in the system is bound to an rx callback (so when
 inbound messages arrive, they are dispatched by the rpmsg bus using the
-- 
2.28.0

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH v6 2/4] rpmsg: move common structures and defines to headers

[Guennadi Liakhovetski]

virtio_rpmsg_bus.c keeps RPMsg protocol structure declarations and
common defines like the ones, needed for name-space announcements,
internal. Move them to common headers instead.

Signed-off-by: Guennadi Liakhovetski 
---
 drivers/rpmsg/virtio_rpmsg_bus.c | 78 +-
 include/linux/rpmsg/virtio.h | 83 
 include/uapi/linux/rpmsg.h   |  3 ++
 3 files changed, 88 insertions(+), 76 deletions(-)
 create mode 100644 include/linux/rpmsg/virtio.h

diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index 9006fc7f73d0..f39c426f9c5e 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -27,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "rpmsg_internal.h"
 
@@ -70,58 +72,6 @@ struct virtproc_info {
struct rpmsg_endpoint *ns_ept;
 };
 
-/* The feature bitmap for virtio rpmsg */
-#define VIRTIO_RPMSG_F_NS  0 /* RP supports name service notifications */
-
-/**
- * struct rpmsg_hdr - common header for all rpmsg messages
- * @src: source address
- * @dst: destination address
- * @reserved: reserved for future use
- * @len: length of payload (in bytes)
- * @flags: message flags
- * @data: @len bytes of message payload data
- *
- * Every message sent(/received) on the rpmsg bus begins with 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 to publish a new service, or announce
- * about its removal. When we receive these messages, an appropriate
- * rpmsg channel (i.e device) is created/destroyed. In turn, the ->probe()
- * or ->remove() handler of the appropriate rpmsg driver will be invoked
- * (if/as-soon-as one is registered).
- */
-struct rpmsg_ns_msg {
-   char name[RPMSG_NAME_SIZE];
-   __virtio32 addr;
-   __virtio32 flags;
-} __packed;
-
-/**
- * enum rpmsg_ns_flags - dynamic name service announcement flags
- *
- * @RPMSG_NS_CREATE: a new remote service was just created
- * @RPMSG_NS_DESTROY: a known remote service was just destroyed
- */
-enum rpmsg_ns_flags {
-   RPMSG_NS_CREATE = 0,
-   RPMSG_NS_DESTROY= 1,
-};
-
 /**
  * @vrp: the remote processor this channel belongs to
  */
@@ -134,27 +84,6 @@ struct virtio_rpmsg_channel {
 #define to_virtio_rpmsg_channel(_rpdev) \
container_of(_rpdev, struct virtio_rpmsg_channel, rpdev)
 
-/*
- * We're allocating buffers of 512 bytes each for communications. The
- * number of buffers will be computed from the number of buffers supported
- * by the vring, upto a maximum of 512 buffers (256 in each direction).
- *
- * Each buffer will have 16 bytes for the msg header and 496 bytes for
- * the payload.
- *
- * This will utilize a maximum total space of 256KB for the buffers.
- *
- * We might also want to add support for user-provided buffers in time.
- * This will allow bigger buffer size flexibility, and can also be used
- * to achieve zero-copy messaging.
- *
- * Note that these numbers are purely a decision of this driver - we
- * can change this without changing anything in the firmware of the remote
- * processor.
- */
-#define MAX_RPMSG_NUM_BUFS (512)
-#define MAX_RPMSG_BUF_SIZE (512)
-
 /*
  * Local addresses are dynamically allocated on-demand.
  * We do not dynamically assign addresses from the low 1024 range,
@@ -162,9 +91,6 @@ struct virtio_rpmsg_channel {
  */
 #define RPMSG_RESERVED_ADDRESSES   (1024)
 
-/* Address 53 is reserved for advertising remote services */
-#define RPMSG_NS_ADDR  (53)
-
 static void virtio_rpmsg_destroy_ept(struct rpmsg_endpoint *ept);
 static int virtio_rpmsg_send(struct rpmsg_endpoint *ept, void *data, int len);
 static int virtio_rpmsg_sendto(struct rpmsg_endpoint *ept, void *data, int len,
diff --git a/include/linux/rpmsg/virtio.h b/include/linux/rpmsg/virtio.h
new file mode 100644
index ..3ede1a4a68a3
--- /dev/null
+++ b/include/linux/rpmsg/virtio.h
@@ -0,0 +1,83 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _LINUX_RPMSG_VIRTIO_H
+#define _LINUX_RPMSG_VIRTIO_H
+
+#include 
+#include 
+#include 
+
+/**
+ * struct rpmsg_hdr - common header for all rpmsg messages
+ * @src: source address
+ * @dst: destination address
+ * @reserved: reserved for future use
+ * @len: length of payload (in bytes)
+ * @flags: message flags
+ * @data: @len bytes of message payload data
+ *
+ * Every message sent(/received) on the rpmsg bus begins with this header.
+ */
+

[PATCH v6 4/4] vhost: add an RPMsg API

[Guennadi Liakhovetski]

Linux supports running the RPMsg protocol over the VirtIO transport
protocol, but currently there is only support for VirtIO clients and
no support for a VirtIO server. This patch adds a vhost-based RPMsg
server implementation.

Signed-off-by: Guennadi Liakhovetski 
---
 drivers/vhost/Kconfig   |   7 +
 drivers/vhost/Makefile  |   3 +
 drivers/vhost/rpmsg.c   | 373 
 drivers/vhost/vhost_rpmsg.h |  74 +++
 4 files changed, 457 insertions(+)
 create mode 100644 drivers/vhost/rpmsg.c
 create mode 100644 drivers/vhost/vhost_rpmsg.h

diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
index 587fbae06182..046b948fc411 100644
--- a/drivers/vhost/Kconfig
+++ b/drivers/vhost/Kconfig
@@ -38,6 +38,13 @@ config VHOST_NET
  To compile this driver as a module, choose M here: the module will
  be called vhost_net.
 
+config VHOST_RPMSG
+   tristate
+   select VHOST
+   help
+ Vhost RPMsg API allows vhost drivers to communicate with VirtIO
+ drivers, using the RPMsg over VirtIO protocol.
+
 config VHOST_SCSI
tristate "VHOST_SCSI TCM fabric driver"
depends on TARGET_CORE && EVENTFD
diff --git a/drivers/vhost/Makefile b/drivers/vhost/Makefile
index f3e1897cce85..9cf459d59f97 100644
--- a/drivers/vhost/Makefile
+++ b/drivers/vhost/Makefile
@@ -2,6 +2,9 @@
 obj-$(CONFIG_VHOST_NET) += vhost_net.o
 vhost_net-y := net.o
 
+obj-$(CONFIG_VHOST_RPMSG) += vhost_rpmsg.o
+vhost_rpmsg-y := rpmsg.o
+
 obj-$(CONFIG_VHOST_SCSI) += vhost_scsi.o
 vhost_scsi-y := scsi.o
 
diff --git a/drivers/vhost/rpmsg.c b/drivers/vhost/rpmsg.c
new file mode 100644
index ..2fa527121a8f
--- /dev/null
+++ b/drivers/vhost/rpmsg.c
@@ -0,0 +1,373 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright(c) 2020 Intel Corporation. All rights reserved.
+ *
+ * Author: Guennadi Liakhovetski 
+ *
+ * Vhost RPMsg VirtIO interface. It provides a set of functions to match the
+ * guest side RPMsg VirtIO API, provided by drivers/rpmsg/virtio_rpmsg_bus.c
+ * These functions handle creation of 2 virtual queues, handling of endpoint
+ * addresses, sending a name-space announcement to the guest as well as any
+ * user messages. This API can be used by any vhost driver to handle RPMsg
+ * specific processing.
+ * Specific vhost drivers, using this API will use their own VirtIO device
+ * IDs, that should then also be added to the ID table in virtio_rpmsg_bus.c
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "vhost.h"
+#include "vhost_rpmsg.h"
+
+/*
+ * All virtio-rpmsg virtual queue kicks always come with just one buffer -
+ * either input or output, but we can also handle split messages
+ */
+static int vhost_rpmsg_get_msg(struct vhost_virtqueue *vq, unsigned int *cnt)
+{
+   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), , 
,
+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 == >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 == >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 -EINVAL;
+}
+
+static const struct vhost_rpmsg_ept *vhost_rpmsg_ept_find(struct vhost_rpmsg 
*vr, int addr)
+{
+   unsigned int i;
+
+   for (i = 0; i < vr->n_epts; i++)
+   if (vr->ept[i].addr == addr)
+   return vr->ept + i;
+
+   return NULL;
+}
+
+/*
+ * if len < 0, then for reading a request, the complete virtual queue buffer
+ * size is prepared, for sending a response, the length in the iterator is used
+ */
+int vhost_rpmsg_start_lock(struct vhost_rpmsg *vr, struct vhost_rpmsg_iter 
*iter,
+  unsigned int qid, ssize_t len)
+   __acquires(vq->mutex)
+{
+   struct vhost_virtqueue *vq = vr->vq + qid;
+   unsigned int cnt;
+   ssize_t ret;
+   size_t tmp;
+
+   if (qid >= VIRTIO_RPMSG_NUM_OF_VQS)
+   return -EINVAL;
+
+   iter->vq = 

[PATCH v6 1/4] vhost: convert VHOST_VSOCK_SET_RUNNING to a generic ioctl

[Guennadi Liakhovetski]

VHOST_VSOCK_SET_RUNNING is used by the vhost vsock driver to perform
crucial VirtQueue initialisation, like assigning .private fields and
calling vhost_vq_init_access(), and clean up. However, this ioctl is
actually extremely useful for any vhost driver, that doesn't have a
side channel to inform it of a status change, e.g. upon a guest
reboot. This patch makes that ioctl generic, while preserving its
numeric value and also keeping the original alias.

Signed-off-by: Guennadi Liakhovetski 
---
 include/uapi/linux/vhost.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/vhost.h b/include/uapi/linux/vhost.h
index 75232185324a..11a4948b6216 100644
--- a/include/uapi/linux/vhost.h
+++ b/include/uapi/linux/vhost.h
@@ -97,6 +97,8 @@
 #define VHOST_SET_BACKEND_FEATURES _IOW(VHOST_VIRTIO, 0x25, __u64)
 #define VHOST_GET_BACKEND_FEATURES _IOR(VHOST_VIRTIO, 0x26, __u64)
 
+#define VHOST_SET_RUNNING _IOW(VHOST_VIRTIO, 0x61, int)
+
 /* VHOST_NET specific defines */
 
 /* Attach virtio net ring to a raw socket, or tap device.
@@ -118,7 +120,7 @@
 /* VHOST_VSOCK specific defines */
 
 #define VHOST_VSOCK_SET_GUEST_CID  _IOW(VHOST_VIRTIO, 0x60, __u64)
-#define VHOST_VSOCK_SET_RUNNING_IOW(VHOST_VIRTIO, 0x61, int)
+#define VHOST_VSOCK_SET_RUNNINGVHOST_SET_RUNNING
 
 /* VHOST_VDPA specific defines */
 
-- 
2.28.0

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH v6 0/4] Add a vhost RPMsg API

[Guennadi Liakhovetski]

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 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. 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, ready
for review and submission, available at
https://github.com/thesofproject/linux/pull/1501/commits

Thanks
Guennadi

Guennadi Liakhovetski (4):
  vhost: convert VHOST_VSOCK_SET_RUNNING to a generic ioctl
  rpmsg: move common structures and defines to headers
  rpmsg: update documentation
  vhost: add an RPMsg API

 Documentation/rpmsg.txt  |   6 +-
 drivers/rpmsg/virtio_rpmsg_bus.c |  78 +--
 drivers/vhost/Kconfig|   7 +
 drivers/vhost/Makefile   |   3 +
 drivers/vhost/rpmsg.c| 373 +++
 drivers/vhost/vhost_rpmsg.h  |  74 ++
 include/linux/rpmsg/virtio.h |  83 +++
 include/uapi/linux/rpmsg.h   |   3 +
 include/uapi/linux/vhost.h   |   4 +-
 9 files changed, 551 insertions(+), 80 deletions(-)
 create mode 100644 drivers/vhost/rpmsg.c
 create mode 100644 drivers/vhost/vhost_rpmsg.h
 create mode 100644 include/linux/rpmsg/virtio.h

-- 
2.28.0

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH v5 4/4] vhost: add an RPMsg API

[Guennadi Liakhovetski]

Linux supports running the RPMsg protocol over the VirtIO transport
protocol, but currently there is only support for VirtIO clients and
no support for a VirtIO server. This patch adds a vhost-based RPMsg
server implementation.

Signed-off-by: Guennadi Liakhovetski 
---
 drivers/vhost/Kconfig   |   7 +
 drivers/vhost/Makefile  |   3 +
 drivers/vhost/rpmsg.c   | 373 
 drivers/vhost/vhost_rpmsg.h |  74 +++
 4 files changed, 457 insertions(+)
 create mode 100644 drivers/vhost/rpmsg.c
 create mode 100644 drivers/vhost/vhost_rpmsg.h

diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
index 587fbae06182..046b948fc411 100644
--- a/drivers/vhost/Kconfig
+++ b/drivers/vhost/Kconfig
@@ -38,6 +38,13 @@ config VHOST_NET
  To compile this driver as a module, choose M here: the module will
  be called vhost_net.
 
+config VHOST_RPMSG
+   tristate
+   select VHOST
+   help
+ Vhost RPMsg API allows vhost drivers to communicate with VirtIO
+ drivers, using the RPMsg over VirtIO protocol.
+
 config VHOST_SCSI
tristate "VHOST_SCSI TCM fabric driver"
depends on TARGET_CORE && EVENTFD
diff --git a/drivers/vhost/Makefile b/drivers/vhost/Makefile
index f3e1897cce85..9cf459d59f97 100644
--- a/drivers/vhost/Makefile
+++ b/drivers/vhost/Makefile
@@ -2,6 +2,9 @@
 obj-$(CONFIG_VHOST_NET) += vhost_net.o
 vhost_net-y := net.o
 
+obj-$(CONFIG_VHOST_RPMSG) += vhost_rpmsg.o
+vhost_rpmsg-y := rpmsg.o
+
 obj-$(CONFIG_VHOST_SCSI) += vhost_scsi.o
 vhost_scsi-y := scsi.o
 
diff --git a/drivers/vhost/rpmsg.c b/drivers/vhost/rpmsg.c
new file mode 100644
index ..c26d7a4afc6d
--- /dev/null
+++ b/drivers/vhost/rpmsg.c
@@ -0,0 +1,373 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright(c) 2020 Intel Corporation. All rights reserved.
+ *
+ * Author: Guennadi Liakhovetski 
+ *
+ * Vhost RPMsg VirtIO interface. It provides a set of functions to match the
+ * guest side RPMsg VirtIO API, provided by drivers/rpmsg/virtio_rpmsg_bus.c
+ * These functions handle creation of 2 virtual queues, handling of endpoint
+ * addresses, sending a name-space announcement to the guest as well as any
+ * user messages. This API can be used by any vhost driver to handle RPMsg
+ * specific processing.
+ * Specific vhost drivers, using this API will use their own VirtIO device
+ * IDs, that should then also be added to the ID table in virtio_rpmsg_bus.c
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "vhost.h"
+#include "vhost_rpmsg.h"
+
+/*
+ * All virtio-rpmsg virtual queue kicks always come with just one buffer -
+ * either input or output, but we can also handle split messages
+ */
+static int vhost_rpmsg_get_msg(struct vhost_virtqueue *vq, unsigned int *cnt)
+{
+   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), , 
,
+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 == >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 == >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 -EINVAL;
+}
+
+static const struct vhost_rpmsg_ept *vhost_rpmsg_ept_find(struct vhost_rpmsg 
*vr, int addr)
+{
+   unsigned int i;
+
+   for (i = 0; i < vr->n_epts; i++)
+   if (vr->ept[i].addr == addr)
+   return vr->ept + i;
+
+   return NULL;
+}
+
+/*
+ * if len < 0, then for reading a request, the complete virtual queue buffer
+ * size is prepared, for sending a response, the length in the iterator is used
+ */
+int vhost_rpmsg_start_lock(struct vhost_rpmsg *vr, struct vhost_rpmsg_iter 
*iter,
+  unsigned int qid, ssize_t len)
+   __acquires(vq->mutex)
+{
+   struct vhost_virtqueue *vq = vr->vq + qid;
+   unsigned int cnt;
+   ssize_t ret;
+   size_t tmp;
+
+   if (qid >= VIRTIO_RPMSG_NUM_OF_VQS)
+   return -EINVAL;
+
+   iter->vq = 

[PATCH v5 2/4] rpmsg: move common structures and defines to headers

[Guennadi Liakhovetski]

virtio_rpmsg_bus.c keeps RPMsg protocol structure declarations and
common defines like the ones, needed for name-space announcements,
internal. Move them to common headers instead.

Signed-off-by: Guennadi Liakhovetski 
---
 drivers/rpmsg/virtio_rpmsg_bus.c | 78 +-
 include/linux/virtio_rpmsg.h | 83 
 include/uapi/linux/rpmsg.h   |  3 ++
 3 files changed, 88 insertions(+), 76 deletions(-)
 create mode 100644 include/linux/virtio_rpmsg.h

diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index 9006fc7f73d0..9d5dd3f0a648 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -26,7 +26,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 
 #include "rpmsg_internal.h"
 
@@ -70,58 +72,6 @@ struct virtproc_info {
struct rpmsg_endpoint *ns_ept;
 };
 
-/* The feature bitmap for virtio rpmsg */
-#define VIRTIO_RPMSG_F_NS  0 /* RP supports name service notifications */
-
-/**
- * struct rpmsg_hdr - common header for all rpmsg messages
- * @src: source address
- * @dst: destination address
- * @reserved: reserved for future use
- * @len: length of payload (in bytes)
- * @flags: message flags
- * @data: @len bytes of message payload data
- *
- * Every message sent(/received) on the rpmsg bus begins with 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 to publish a new service, or announce
- * about its removal. When we receive these messages, an appropriate
- * rpmsg channel (i.e device) is created/destroyed. In turn, the ->probe()
- * or ->remove() handler of the appropriate rpmsg driver will be invoked
- * (if/as-soon-as one is registered).
- */
-struct rpmsg_ns_msg {
-   char name[RPMSG_NAME_SIZE];
-   __virtio32 addr;
-   __virtio32 flags;
-} __packed;
-
-/**
- * enum rpmsg_ns_flags - dynamic name service announcement flags
- *
- * @RPMSG_NS_CREATE: a new remote service was just created
- * @RPMSG_NS_DESTROY: a known remote service was just destroyed
- */
-enum rpmsg_ns_flags {
-   RPMSG_NS_CREATE = 0,
-   RPMSG_NS_DESTROY= 1,
-};
-
 /**
  * @vrp: the remote processor this channel belongs to
  */
@@ -134,27 +84,6 @@ struct virtio_rpmsg_channel {
 #define to_virtio_rpmsg_channel(_rpdev) \
container_of(_rpdev, struct virtio_rpmsg_channel, rpdev)
 
-/*
- * We're allocating buffers of 512 bytes each for communications. The
- * number of buffers will be computed from the number of buffers supported
- * by the vring, upto a maximum of 512 buffers (256 in each direction).
- *
- * Each buffer will have 16 bytes for the msg header and 496 bytes for
- * the payload.
- *
- * This will utilize a maximum total space of 256KB for the buffers.
- *
- * We might also want to add support for user-provided buffers in time.
- * This will allow bigger buffer size flexibility, and can also be used
- * to achieve zero-copy messaging.
- *
- * Note that these numbers are purely a decision of this driver - we
- * can change this without changing anything in the firmware of the remote
- * processor.
- */
-#define MAX_RPMSG_NUM_BUFS (512)
-#define MAX_RPMSG_BUF_SIZE (512)
-
 /*
  * Local addresses are dynamically allocated on-demand.
  * We do not dynamically assign addresses from the low 1024 range,
@@ -162,9 +91,6 @@ struct virtio_rpmsg_channel {
  */
 #define RPMSG_RESERVED_ADDRESSES   (1024)
 
-/* Address 53 is reserved for advertising remote services */
-#define RPMSG_NS_ADDR  (53)
-
 static void virtio_rpmsg_destroy_ept(struct rpmsg_endpoint *ept);
 static int virtio_rpmsg_send(struct rpmsg_endpoint *ept, void *data, int len);
 static int virtio_rpmsg_sendto(struct rpmsg_endpoint *ept, void *data, int len,
diff --git a/include/linux/virtio_rpmsg.h b/include/linux/virtio_rpmsg.h
new file mode 100644
index ..fcb523831e73
--- /dev/null
+++ b/include/linux/virtio_rpmsg.h
@@ -0,0 +1,83 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _LINUX_VIRTIO_RPMSG_H
+#define _LINUX_VIRTIO_RPMSG_H
+
+#include 
+#include 
+#include 
+
+/**
+ * struct rpmsg_hdr - common header for all rpmsg messages
+ * @src: source address
+ * @dst: destination address
+ * @reserved: reserved for future use
+ * @len: length of payload (in bytes)
+ * @flags: message flags
+ * @data: @len bytes of message payload data
+ *
+ * Every message sent(/received) on the rpmsg bus begins with this header.
+ */
+struct rpmsg_hdr {
+   __virtio32 src;
+   __virtio32 dst;
+   __v

[PATCH v5 1/4] vhost: convert VHOST_VSOCK_SET_RUNNING to a generic ioctl

[Guennadi Liakhovetski]

VHOST_VSOCK_SET_RUNNING is used by the vhost vsock driver to perform
crucial VirtQueue initialisation, like assigning .private fields and
calling vhost_vq_init_access(), and clean up. However, this ioctl is
actually extremely useful for any vhost driver, that doesn't have a
side channel to inform it of a status change, e.g. upon a guest
reboot. This patch makes that ioctl generic, while preserving its
numeric value and also keeping the original alias.

Signed-off-by: Guennadi Liakhovetski 
---
 include/uapi/linux/vhost.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/vhost.h b/include/uapi/linux/vhost.h
index 75232185324a..11a4948b6216 100644
--- a/include/uapi/linux/vhost.h
+++ b/include/uapi/linux/vhost.h
@@ -97,6 +97,8 @@
 #define VHOST_SET_BACKEND_FEATURES _IOW(VHOST_VIRTIO, 0x25, __u64)
 #define VHOST_GET_BACKEND_FEATURES _IOR(VHOST_VIRTIO, 0x26, __u64)
 
+#define VHOST_SET_RUNNING _IOW(VHOST_VIRTIO, 0x61, int)
+
 /* VHOST_NET specific defines */
 
 /* Attach virtio net ring to a raw socket, or tap device.
@@ -118,7 +120,7 @@
 /* VHOST_VSOCK specific defines */
 
 #define VHOST_VSOCK_SET_GUEST_CID  _IOW(VHOST_VIRTIO, 0x60, __u64)
-#define VHOST_VSOCK_SET_RUNNING_IOW(VHOST_VIRTIO, 0x61, int)
+#define VHOST_VSOCK_SET_RUNNINGVHOST_SET_RUNNING
 
 /* VHOST_VDPA specific defines */
 
-- 
2.28.0

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH v5 3/4] rpmsg: update documentation

[Guennadi Liakhovetski]

rpmsg_create_ept() takes struct rpmsg_channel_info chinfo as its last
argument, not a u32 value. The first two arguments are also updated.

Signed-off-by: Guennadi Liakhovetski 
---
 Documentation/rpmsg.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/rpmsg.txt b/Documentation/rpmsg.txt
index 24b7a9e1a5f9..1ce353cb232a 100644
--- a/Documentation/rpmsg.txt
+++ b/Documentation/rpmsg.txt
@@ -192,9 +192,9 @@ Returns 0 on success and an appropriate error value on 
failure.
 
 ::
 
-  struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_channel *rpdev,
-   void (*cb)(struct rpmsg_channel *, void *, int, void *, u32),
-   void *priv, u32 addr);
+  struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_device *rpdev,
+ rpmsg_rx_cb_t cb, void *priv,
+ struct rpmsg_channel_info chinfo);
 
 every rpmsg address in the system is bound to an rx callback (so when
 inbound messages arrive, they are dispatched by the rpmsg bus using the
-- 
2.28.0

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH v5 0/4] Add a vhost RPMsg API

[Guennadi Liakhovetski]

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:
  * remove "default n" from Kconfig

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, ready
for review and submission, available at
https://github.com/thesofproject/linux/pull/1501/commits

Thanks
Guennadi

Guennadi Liakhovetski (4):
  vhost: convert VHOST_VSOCK_SET_RUNNING to a generic ioctl
  rpmsg: move common structures and defines to headers
  rpmsg: update documentation
  vhost: add an RPMsg API

 Documentation/rpmsg.txt  |   6 +-
 drivers/rpmsg/virtio_rpmsg_bus.c |  78 +--
 drivers/vhost/Kconfig|   7 +
 drivers/vhost/Makefile   |   3 +
 drivers/vhost/rpmsg.c| 373 +++
 drivers/vhost/vhost_rpmsg.h  |  74 ++
 include/linux/virtio_rpmsg.h |  83 +++
 include/uapi/linux/rpmsg.h   |   3 +
 include/uapi/linux/vhost.h   |   4 +-
 9 files changed, 551 insertions(+), 80 deletions(-)
 create mode 100644 drivers/vhost/rpmsg.c
 create mode 100644 drivers/vhost/vhost_rpmsg.h
 create mode 100644 include/linux/virtio_rpmsg.h

-- 
2.28.0

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v4 4/4] vhost: add an RPMsg API

[Guennadi Liakhovetski]

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), 
> > > > > , ,
> > > > > +  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 == >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
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v4 4/4] vhost: add an RPMsg API

[Guennadi Liakhovetski]

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:
> > On Tue, Aug 04, 2020 at 10:27:08AM -0400, Michael S. Tsirkin wrote:
> > > On Wed, Jul 22, 2020 at 05:09:27PM +0200, Guennadi Liakhovetski wrote:
> > > > Linux supports running the RPMsg protocol over the VirtIO transport
> > > > protocol, but currently there is only support for VirtIO clients and
> > > > no support for a VirtIO server. This patch adds a vhost-based RPMsg
> > > > server implementation.
> > > > 
> > > > Signed-off-by: Guennadi Liakhovetski 
> > > > 
> > > > ---
> > > >  drivers/vhost/Kconfig   |   7 +
> > > >  drivers/vhost/Makefile  |   3 +
> > > >  drivers/vhost/rpmsg.c   | 375 
> > > >  drivers/vhost/vhost_rpmsg.h |  74 +++
> > > >  4 files changed, 459 insertions(+)
> > > >  create mode 100644 drivers/vhost/rpmsg.c
> > > >  create mode 100644 drivers/vhost/vhost_rpmsg.h
> > > > 
> > > > diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
> > > > index d3688c6afb87..602421bf1d03 100644
> > > > --- a/drivers/vhost/Kconfig
> > > > +++ b/drivers/vhost/Kconfig
> > > > @@ -38,6 +38,13 @@ config VHOST_NET
> > > >   To compile this driver as a module, choose M here: the module 
> > > > will
> > > >   be called vhost_net.
> > > >  
> > > > +config VHOST_RPMSG
> > > > +   tristate
> > > 
> > > So this lacks a description line so it does not appear
> > > in menuconfig. How is user supposed to set it?
> > > I added a one-line description.
> > 
> > That was on purpose. I don't think there's any value in this API 
> > stand-alone, 
> > so I let users select it as needed. But we can change that too, id desired.
> 
> I guess the patches actually selecting this 
> are separate then?

Yes, I posted them here before for reference 
https://www.spinics.net/lists/linux-remoteproc/msg06355.html

> > > > +   depends on VHOST
> > > 
> > > Other drivers select VHOST instead. Any reason not to
> > > do it like this here?
> > 
> > I have
> > 
> > +   select VHOST
> > +   select VHOST_RPMSG
> > 
> > in my client driver patch.
> 
> Any issues selecting from here so others get it for free?
> If this is selected then dependencies are ignored ...

I wasn't sure whether "select" works recursively, but looks like it does,
can do then, sure.

> > > > +   help
> > > > + Vhost RPMsg API allows vhost drivers to communicate with 
> > > > VirtIO
> > > > + drivers, using the RPMsg over VirtIO protocol.
> > > > +
> > > 
> > > >  config VHOST_SCSI
> > > > tristate "VHOST_SCSI TCM fabric driver"
> > > > depends on TARGET_CORE && EVENTFD
> > > > diff --git a/drivers/vhost/Makefile b/drivers/vhost/Makefile
> > > > index f3e1897cce85..9cf459d59f97 100644
> > > > --- a/drivers/vhost/Makefile
> > > > +++ b/drivers/vhost/Makefile
> > > > @@ -2,6 +2,9 @@
> > > >  obj-$(CONFIG_VHOST_NET) += vhost_net.o
> > > >  vhost_net-y := net.o
> > > >  
> > > > +obj-$(CONFIG_VHOST_RPMSG) += vhost_rpmsg.o
> > > > +vhost_rpmsg-y := rpmsg.o
> > > > +
> > > >  obj-$(CONFIG_VHOST_SCSI) += vhost_scsi.o
> > > >  vhost_scsi-y := scsi.o
> > > >  
> > > > diff --git a/drivers/vhost/rpmsg.c b/drivers/vhost/rpmsg.c
> > > > new file mode 100644
> > > > index ..d7ab48414224
> > > > --- /dev/null
> > > > +++ b/drivers/vhost/rpmsg.c
> > > > @@ -0,0 +1,375 @@
> > > > +// SPDX-License-Identifier: GPL-2.0-only
> > > > +/*
> > > > + * Copyright(c) 2020 Intel Corporation. All rights reserved.
> > > > + *
> > > > + * Author: Guennadi Liakhovetski 
> > > > 
> > > > + *
> > > > + * Vhost RPMsg VirtIO interface. It provides a set of functions to 
> > > > match the
> > > > + * guest side RPMsg VirtIO API, provided by 
> > > > drivers/rpmsg/virtio_rpmsg_bus.c
> > > > + * These functions handle creation of 2 virtual queues, handling of 
> > > > endpoint

Re: [PATCH v4 4/4] vhost: add an RPMsg API

[Guennadi Liakhovetski]

On Tue, Aug 04, 2020 at 10:27:08AM -0400, Michael S. Tsirkin wrote:
> On Wed, Jul 22, 2020 at 05:09:27PM +0200, Guennadi Liakhovetski wrote:
> > Linux supports running the RPMsg protocol over the VirtIO transport
> > protocol, but currently there is only support for VirtIO clients and
> > no support for a VirtIO server. This patch adds a vhost-based RPMsg
> > server implementation.
> > 
> > Signed-off-by: Guennadi Liakhovetski 
> > ---
> >  drivers/vhost/Kconfig   |   7 +
> >  drivers/vhost/Makefile  |   3 +
> >  drivers/vhost/rpmsg.c   | 375 
> >  drivers/vhost/vhost_rpmsg.h |  74 +++
> >  4 files changed, 459 insertions(+)
> >  create mode 100644 drivers/vhost/rpmsg.c
> >  create mode 100644 drivers/vhost/vhost_rpmsg.h
> > 
> > diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
> > index d3688c6afb87..602421bf1d03 100644
> > --- a/drivers/vhost/Kconfig
> > +++ b/drivers/vhost/Kconfig
> > @@ -38,6 +38,13 @@ config VHOST_NET
> >   To compile this driver as a module, choose M here: the module will
> >   be called vhost_net.
> >  
> > +config VHOST_RPMSG
> > +   tristate
> 
> So this lacks a description line so it does not appear
> in menuconfig. How is user supposed to set it?
> I added a one-line description.

That was on purpose. I don't think there's any value in this API stand-alone, 
so I let users select it as needed. But we can change that too, id desired.

> > +   depends on VHOST
> 
> Other drivers select VHOST instead. Any reason not to
> do it like this here?

I have

+   select VHOST
+   select VHOST_RPMSG

in my client driver patch.

> > +   help
> > + Vhost RPMsg API allows vhost drivers to communicate with VirtIO
> > + drivers, using the RPMsg over VirtIO protocol.
> > +
> 
> >  config VHOST_SCSI
> > tristate "VHOST_SCSI TCM fabric driver"
> > depends on TARGET_CORE && EVENTFD
> > diff --git a/drivers/vhost/Makefile b/drivers/vhost/Makefile
> > index f3e1897cce85..9cf459d59f97 100644
> > --- a/drivers/vhost/Makefile
> > +++ b/drivers/vhost/Makefile
> > @@ -2,6 +2,9 @@
> >  obj-$(CONFIG_VHOST_NET) += vhost_net.o
> >  vhost_net-y := net.o
> >  
> > +obj-$(CONFIG_VHOST_RPMSG) += vhost_rpmsg.o
> > +vhost_rpmsg-y := rpmsg.o
> > +
> >  obj-$(CONFIG_VHOST_SCSI) += vhost_scsi.o
> >  vhost_scsi-y := scsi.o
> >  
> > diff --git a/drivers/vhost/rpmsg.c b/drivers/vhost/rpmsg.c
> > new file mode 100644
> > index ..d7ab48414224
> > --- /dev/null
> > +++ b/drivers/vhost/rpmsg.c
> > @@ -0,0 +1,375 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright(c) 2020 Intel Corporation. All rights reserved.
> > + *
> > + * Author: Guennadi Liakhovetski 
> > + *
> > + * Vhost RPMsg VirtIO interface. It provides a set of functions to match 
> > the
> > + * guest side RPMsg VirtIO API, provided by 
> > drivers/rpmsg/virtio_rpmsg_bus.c
> > + * These functions handle creation of 2 virtual queues, handling of 
> > endpoint
> > + * addresses, sending a name-space announcement to the guest as well as any
> > + * user messages. This API can be used by any vhost driver to handle RPMsg
> > + * specific processing.
> > + * Specific vhost drivers, using this API will use their own VirtIO device
> > + * IDs, that should then also be added to the ID table in 
> > virtio_rpmsg_bus.c
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include "vhost.h"
> > +#include "vhost_rpmsg.h"
> > +
> > +/*
> > + * All virtio-rpmsg virtual queue kicks always come with just one buffer -
> > + * either input or output
> > + */
> > +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), , 
> > ,
> > +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 (

Re: [PATCH v4 0/4] Add a vhost RPMsg API

[Guennadi Liakhovetski]

On Tue, Aug 04, 2020 at 10:10:23AM -0400, Michael S. Tsirkin wrote:
> On Tue, Aug 04, 2020 at 03:19:19PM +0200, Guennadi Liakhovetski wrote:
> > Hi Michael,
> > 
> > On Tue, Aug 04, 2020 at 08:26:53AM -0400, Michael S. Tsirkin wrote:
> > > On Wed, Jul 22, 2020 at 05:09:23PM +0200, Guennadi Liakhovetski wrote:
> > > > Hi,
> > > > 
> > > > Now that virtio-rpmsg endianness fixes have been merged we can 
> > > > proceed with the next step.
> > > 
> > > OK my attempts to resolve conflicts just created a mess.
> > 
> > You just need to apply my previous patch for virtio-rpmsg first 
> > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/rpmsg/virtio_rpmsg_bus.c?id=111d1089700cdb752681ef44f54ab6137736f5c2
> > Then this series should apply cleanly.
> > 
> > Thanks
> > Guennadi
> 
> Hmm.  Could you test the vhost branch in my tree, and tell me if that looks
> good to you?

Sorry, I'm not sure I understand why you're trying to resolve conflicts 
manually. My previous patch is already in "next," if you don't pull from 
"next" you will have a conflict when pushing to it. What am I missing?

Thanks
Guennadi

> > > I dropped these for now, could you pls rebase on top
> > > of linux-next branch in my tree, and repost?
> > > Thanks!
> > > 
> > > 
> > > > 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:
> > > >   * remove "default n" from Kconfig
> > > > 
> > > > 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, ready
> > > > for review and submission, available at
> > > > https://github.com/thesofproject/linux/pull/1501/commits
> > > > 
> > > > Thanks
> > > > Guennadi
> > > > 
> > > > Guennadi Liakhovetski (4):
> > > >   vhost: convert VHOST_VSOCK_SET_RUNNING to a generic ioctl
> > > >   rpmsg: move common structures and defines to headers
> > > >   rpmsg: update documentation
> > > >   vhost: add an RPMsg API
> > > > 
> > > >  Documentation/rpmsg.txt  |   6 +-
> > > >  drivers/rpmsg/virtio_rpmsg_bus.c |  78 +--
> > > >  drivers/vhost/Kconfig|   7 +
> > > >  drivers/vhost/Makefile   |   3 +
> > > >  drivers/vhost/rpmsg.c| 375 +++
> > > >  drivers/vhost/vhost_rpmsg.h  |  74 ++
> > > >  include/linux/virtio_rpmsg.h |  83 +++
> > > >  include/uapi/linux/rpmsg.h   |   3 +
> > > >  include/uapi/linux/vhost.h   |   4 +-
> > > >  9 files changed, 553 insertions(+), 80 deletions(-)
> > > >  create mode 100644 drivers/vhost/rpmsg.c
> > > >  create mode 100644 drivers/vhost/vhost_rpmsg.h
> > > >  create mode 100644 include/linux/virtio_rpmsg.h
> > > > 
> > > > -- 
> > > > 2.27.0
> > > 
> 
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v4 0/4] Add a vhost RPMsg API

[Guennadi Liakhovetski]

Hi Michael,

On Tue, Aug 04, 2020 at 08:26:53AM -0400, Michael S. Tsirkin wrote:
> On Wed, Jul 22, 2020 at 05:09:23PM +0200, Guennadi Liakhovetski wrote:
> > Hi,
> > 
> > Now that virtio-rpmsg endianness fixes have been merged we can 
> > proceed with the next step.
> 
> OK my attempts to resolve conflicts just created a mess.

You just need to apply my previous patch for virtio-rpmsg first 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/rpmsg/virtio_rpmsg_bus.c?id=111d1089700cdb752681ef44f54ab6137736f5c2
Then this series should apply cleanly.

Thanks
Guennadi

> I dropped these for now, could you pls rebase on top
> of linux-next branch in my tree, and repost?
> Thanks!
> 
> 
> > 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:
> >   * remove "default n" from Kconfig
> > 
> > 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, ready
> > for review and submission, available at
> > https://github.com/thesofproject/linux/pull/1501/commits
> > 
> > Thanks
> > Guennadi
> > 
> > Guennadi Liakhovetski (4):
> >   vhost: convert VHOST_VSOCK_SET_RUNNING to a generic ioctl
> >   rpmsg: move common structures and defines to headers
> >   rpmsg: update documentation
> >   vhost: add an RPMsg API
> > 
> >  Documentation/rpmsg.txt  |   6 +-
> >  drivers/rpmsg/virtio_rpmsg_bus.c |  78 +--
> >  drivers/vhost/Kconfig|   7 +
> >  drivers/vhost/Makefile   |   3 +
> >  drivers/vhost/rpmsg.c| 375 +++
> >  drivers/vhost/vhost_rpmsg.h  |  74 ++
> >  include/linux/virtio_rpmsg.h |  83 +++
> >  include/uapi/linux/rpmsg.h   |   3 +
> >  include/uapi/linux/vhost.h   |   4 +-
> >  9 files changed, 553 insertions(+), 80 deletions(-)
> >  create mode 100644 drivers/vhost/rpmsg.c
> >  create mode 100644 drivers/vhost/vhost_rpmsg.h
> >  create mode 100644 include/linux/virtio_rpmsg.h
> > 
> > -- 
> > 2.27.0
> 
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v4 0/4] Add a vhost RPMsg API

[Guennadi Liakhovetski]

Hi Michael,

On Thu, Jul 30, 2020 at 12:08:29PM -0400, Michael S. Tsirkin wrote:
> On Wed, Jul 22, 2020 at 05:09:23PM +0200, Guennadi Liakhovetski wrote:
> > Hi,
> > 
> > Now that virtio-rpmsg endianness fixes have been merged we can 
> > proceed with the next step.
> 
> Which tree is this for?

The essential part of this series is for drivers/vhost, so, I presume 
that should be the target tree as well. There is however a small part 
for the drivers/rpmsg, should I split this series in two or shall we 
first review is as a whole to make its goals clearer?

Thanks
Guennadi

> > 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:
> >   * remove "default n" from Kconfig
> > 
> > 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, ready
> > for review and submission, available at
> > https://github.com/thesofproject/linux/pull/1501/commits
> > 
> > Thanks
> > Guennadi
> > 
> > Guennadi Liakhovetski (4):
> >   vhost: convert VHOST_VSOCK_SET_RUNNING to a generic ioctl
> >   rpmsg: move common structures and defines to headers
> >   rpmsg: update documentation
> >   vhost: add an RPMsg API
> > 
> >  Documentation/rpmsg.txt  |   6 +-
> >  drivers/rpmsg/virtio_rpmsg_bus.c |  78 +--
> >  drivers/vhost/Kconfig|   7 +
> >  drivers/vhost/Makefile   |   3 +
> >  drivers/vhost/rpmsg.c| 375 +++
> >  drivers/vhost/vhost_rpmsg.h  |  74 ++
> >  include/linux/virtio_rpmsg.h |  83 +++
> >  include/uapi/linux/rpmsg.h   |   3 +
> >  include/uapi/linux/vhost.h   |   4 +-
> >  9 files changed, 553 insertions(+), 80 deletions(-)
> >  create mode 100644 drivers/vhost/rpmsg.c
> >  create mode 100644 drivers/vhost/vhost_rpmsg.h
> >  create mode 100644 include/linux/virtio_rpmsg.h
> > 
> > -- 
> > 2.27.0
> 
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH v4 4/4] vhost: add an RPMsg API

[Guennadi Liakhovetski]

Linux supports running the RPMsg protocol over the VirtIO transport
protocol, but currently there is only support for VirtIO clients and
no support for a VirtIO server. This patch adds a vhost-based RPMsg
server implementation.

Signed-off-by: Guennadi Liakhovetski 
---
 drivers/vhost/Kconfig   |   7 +
 drivers/vhost/Makefile  |   3 +
 drivers/vhost/rpmsg.c   | 375 
 drivers/vhost/vhost_rpmsg.h |  74 +++
 4 files changed, 459 insertions(+)
 create mode 100644 drivers/vhost/rpmsg.c
 create mode 100644 drivers/vhost/vhost_rpmsg.h

diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
index d3688c6afb87..602421bf1d03 100644
--- a/drivers/vhost/Kconfig
+++ b/drivers/vhost/Kconfig
@@ -38,6 +38,13 @@ config VHOST_NET
  To compile this driver as a module, choose M here: the module will
  be called vhost_net.
 
+config VHOST_RPMSG
+   tristate
+   depends on VHOST
+   help
+ Vhost RPMsg API allows vhost drivers to communicate with VirtIO
+ drivers, using the RPMsg over VirtIO protocol.
+
 config VHOST_SCSI
tristate "VHOST_SCSI TCM fabric driver"
depends on TARGET_CORE && EVENTFD
diff --git a/drivers/vhost/Makefile b/drivers/vhost/Makefile
index f3e1897cce85..9cf459d59f97 100644
--- a/drivers/vhost/Makefile
+++ b/drivers/vhost/Makefile
@@ -2,6 +2,9 @@
 obj-$(CONFIG_VHOST_NET) += vhost_net.o
 vhost_net-y := net.o
 
+obj-$(CONFIG_VHOST_RPMSG) += vhost_rpmsg.o
+vhost_rpmsg-y := rpmsg.o
+
 obj-$(CONFIG_VHOST_SCSI) += vhost_scsi.o
 vhost_scsi-y := scsi.o
 
diff --git a/drivers/vhost/rpmsg.c b/drivers/vhost/rpmsg.c
new file mode 100644
index ..d7ab48414224
--- /dev/null
+++ b/drivers/vhost/rpmsg.c
@@ -0,0 +1,375 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright(c) 2020 Intel Corporation. All rights reserved.
+ *
+ * Author: Guennadi Liakhovetski 
+ *
+ * Vhost RPMsg VirtIO interface. It provides a set of functions to match the
+ * guest side RPMsg VirtIO API, provided by drivers/rpmsg/virtio_rpmsg_bus.c
+ * These functions handle creation of 2 virtual queues, handling of endpoint
+ * addresses, sending a name-space announcement to the guest as well as any
+ * user messages. This API can be used by any vhost driver to handle RPMsg
+ * specific processing.
+ * Specific vhost drivers, using this API will use their own VirtIO device
+ * IDs, that should then also be added to the ID table in virtio_rpmsg_bus.c
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "vhost.h"
+#include "vhost_rpmsg.h"
+
+/*
+ * All virtio-rpmsg virtual queue kicks always come with just one buffer -
+ * either input or output
+ */
+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), , 
,
+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 == >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 == >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 return the buffer using vhost_add_used()
+* or vhost_discard_vq_desc(). vhost_discard_vq_desc() is
+* described as "being useful for error handling," but it makes
+* the thus discarded buffers "unseen," so next time we look we
+* retrieve them again?
+*/
+   return -EINVAL;
+}
+
+static const struct vhost_rpmsg_ept *vhost_rpmsg_ept_find(struct vhost_rpmsg 
*vr, int addr)
+{
+   unsigned int i;
+
+   for (i = 0; i < vr->n_epts; i++)
+   if (vr->ept[i].addr == addr)
+   return vr->ept + i;
+
+   return NULL;
+}
+
+/*
+ * if len < 0, then for reading a request, the complete virtual queue buffer
+ * size is prepared, for sending a response, the length in the iterator is used
+ */
+int vhost_rpmsg_start_lock(struct vhost_rpmsg *vr, struct vhost_rpmsg_iter 
*iter,
+  unsigned int qid, ssize_t len)
+   __acquires(vq->mutex)
+{
+   

[PATCH v4 1/4] vhost: convert VHOST_VSOCK_SET_RUNNING to a generic ioctl

[Guennadi Liakhovetski]

VHOST_VSOCK_SET_RUNNING is used by the vhost vsock driver to perform
crucial VirtQueue initialisation, like assigning .private fields and
calling vhost_vq_init_access(), and clean up. However, this ioctl is
actually extremely useful for any vhost driver, that doesn't have a
side channel to inform it of a status change, e.g. upon a guest
reboot. This patch makes that ioctl generic, while preserving its
numeric value and also keeping the original alias.

Signed-off-by: Guennadi Liakhovetski 
---
 include/uapi/linux/vhost.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/vhost.h b/include/uapi/linux/vhost.h
index 0c2349612e77..5d9254e2a6b6 100644
--- a/include/uapi/linux/vhost.h
+++ b/include/uapi/linux/vhost.h
@@ -95,6 +95,8 @@
 #define VHOST_SET_BACKEND_FEATURES _IOW(VHOST_VIRTIO, 0x25, __u64)
 #define VHOST_GET_BACKEND_FEATURES _IOR(VHOST_VIRTIO, 0x26, __u64)
 
+#define VHOST_SET_RUNNING _IOW(VHOST_VIRTIO, 0x61, int)
+
 /* VHOST_NET specific defines */
 
 /* Attach virtio net ring to a raw socket, or tap device.
@@ -116,7 +118,7 @@
 /* VHOST_VSOCK specific defines */
 
 #define VHOST_VSOCK_SET_GUEST_CID  _IOW(VHOST_VIRTIO, 0x60, __u64)
-#define VHOST_VSOCK_SET_RUNNING_IOW(VHOST_VIRTIO, 0x61, int)
+#define VHOST_VSOCK_SET_RUNNINGVHOST_SET_RUNNING
 
 /* VHOST_VDPA specific defines */
 
-- 
2.27.0

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH v4 2/4] rpmsg: move common structures and defines to headers

[Guennadi Liakhovetski]

virtio_rpmsg_bus.c keeps RPMsg protocol structure declarations and
common defines like the ones, needed for name-space announcements,
internal. Move them to common headers instead.

Signed-off-by: Guennadi Liakhovetski 
---
 drivers/rpmsg/virtio_rpmsg_bus.c | 78 +-
 include/linux/virtio_rpmsg.h | 83 
 include/uapi/linux/rpmsg.h   |  3 ++
 3 files changed, 88 insertions(+), 76 deletions(-)
 create mode 100644 include/linux/virtio_rpmsg.h

diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index 9006fc7f73d0..9d5dd3f0a648 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -26,7 +26,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 
 #include "rpmsg_internal.h"
 
@@ -70,58 +72,6 @@ struct virtproc_info {
struct rpmsg_endpoint *ns_ept;
 };
 
-/* The feature bitmap for virtio rpmsg */
-#define VIRTIO_RPMSG_F_NS  0 /* RP supports name service notifications */
-
-/**
- * struct rpmsg_hdr - common header for all rpmsg messages
- * @src: source address
- * @dst: destination address
- * @reserved: reserved for future use
- * @len: length of payload (in bytes)
- * @flags: message flags
- * @data: @len bytes of message payload data
- *
- * Every message sent(/received) on the rpmsg bus begins with 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 to publish a new service, or announce
- * about its removal. When we receive these messages, an appropriate
- * rpmsg channel (i.e device) is created/destroyed. In turn, the ->probe()
- * or ->remove() handler of the appropriate rpmsg driver will be invoked
- * (if/as-soon-as one is registered).
- */
-struct rpmsg_ns_msg {
-   char name[RPMSG_NAME_SIZE];
-   __virtio32 addr;
-   __virtio32 flags;
-} __packed;
-
-/**
- * enum rpmsg_ns_flags - dynamic name service announcement flags
- *
- * @RPMSG_NS_CREATE: a new remote service was just created
- * @RPMSG_NS_DESTROY: a known remote service was just destroyed
- */
-enum rpmsg_ns_flags {
-   RPMSG_NS_CREATE = 0,
-   RPMSG_NS_DESTROY= 1,
-};
-
 /**
  * @vrp: the remote processor this channel belongs to
  */
@@ -134,27 +84,6 @@ struct virtio_rpmsg_channel {
 #define to_virtio_rpmsg_channel(_rpdev) \
container_of(_rpdev, struct virtio_rpmsg_channel, rpdev)
 
-/*
- * We're allocating buffers of 512 bytes each for communications. The
- * number of buffers will be computed from the number of buffers supported
- * by the vring, upto a maximum of 512 buffers (256 in each direction).
- *
- * Each buffer will have 16 bytes for the msg header and 496 bytes for
- * the payload.
- *
- * This will utilize a maximum total space of 256KB for the buffers.
- *
- * We might also want to add support for user-provided buffers in time.
- * This will allow bigger buffer size flexibility, and can also be used
- * to achieve zero-copy messaging.
- *
- * Note that these numbers are purely a decision of this driver - we
- * can change this without changing anything in the firmware of the remote
- * processor.
- */
-#define MAX_RPMSG_NUM_BUFS (512)
-#define MAX_RPMSG_BUF_SIZE (512)
-
 /*
  * Local addresses are dynamically allocated on-demand.
  * We do not dynamically assign addresses from the low 1024 range,
@@ -162,9 +91,6 @@ struct virtio_rpmsg_channel {
  */
 #define RPMSG_RESERVED_ADDRESSES   (1024)
 
-/* Address 53 is reserved for advertising remote services */
-#define RPMSG_NS_ADDR  (53)
-
 static void virtio_rpmsg_destroy_ept(struct rpmsg_endpoint *ept);
 static int virtio_rpmsg_send(struct rpmsg_endpoint *ept, void *data, int len);
 static int virtio_rpmsg_sendto(struct rpmsg_endpoint *ept, void *data, int len,
diff --git a/include/linux/virtio_rpmsg.h b/include/linux/virtio_rpmsg.h
new file mode 100644
index ..fcb523831e73
--- /dev/null
+++ b/include/linux/virtio_rpmsg.h
@@ -0,0 +1,83 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _LINUX_VIRTIO_RPMSG_H
+#define _LINUX_VIRTIO_RPMSG_H
+
+#include 
+#include 
+#include 
+
+/**
+ * struct rpmsg_hdr - common header for all rpmsg messages
+ * @src: source address
+ * @dst: destination address
+ * @reserved: reserved for future use
+ * @len: length of payload (in bytes)
+ * @flags: message flags
+ * @data: @len bytes of message payload data
+ *
+ * Every message sent(/received) on the rpmsg bus begins with this header.
+ */
+struct rpmsg_hdr {
+   __virtio32 src;
+   __virtio32 dst;
+   __v

[PATCH v4 0/4] Add a vhost RPMsg API

[Guennadi Liakhovetski]

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
- address comments from Pierre-Louis Bossart:
  * remove "default n" from Kconfig

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, ready
for review and submission, available at
https://github.com/thesofproject/linux/pull/1501/commits

Thanks
Guennadi

Guennadi Liakhovetski (4):
  vhost: convert VHOST_VSOCK_SET_RUNNING to a generic ioctl
  rpmsg: move common structures and defines to headers
  rpmsg: update documentation
  vhost: add an RPMsg API

 Documentation/rpmsg.txt  |   6 +-
 drivers/rpmsg/virtio_rpmsg_bus.c |  78 +--
 drivers/vhost/Kconfig|   7 +
 drivers/vhost/Makefile   |   3 +
 drivers/vhost/rpmsg.c| 375 +++
 drivers/vhost/vhost_rpmsg.h  |  74 ++
 include/linux/virtio_rpmsg.h |  83 +++
 include/uapi/linux/rpmsg.h   |   3 +
 include/uapi/linux/vhost.h   |   4 +-
 9 files changed, 553 insertions(+), 80 deletions(-)
 create mode 100644 drivers/vhost/rpmsg.c
 create mode 100644 drivers/vhost/vhost_rpmsg.h
 create mode 100644 include/linux/virtio_rpmsg.h

-- 
2.27.0

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH v4 3/4] rpmsg: update documentation

[Guennadi Liakhovetski]

rpmsg_create_ept() takes struct rpmsg_channel_info chinfo as its last
argument, not a u32 value. The first two arguments are also updated.

Signed-off-by: Guennadi Liakhovetski 
Reviewed-by: Mathieu Poirier 
---
 Documentation/rpmsg.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/rpmsg.txt b/Documentation/rpmsg.txt
index 24b7a9e1a5f9..1ce353cb232a 100644
--- a/Documentation/rpmsg.txt
+++ b/Documentation/rpmsg.txt
@@ -192,9 +192,9 @@ Returns 0 on success and an appropriate error value on 
failure.
 
 ::
 
-  struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_channel *rpdev,
-   void (*cb)(struct rpmsg_channel *, void *, int, void *, u32),
-   void *priv, u32 addr);
+  struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_device *rpdev,
+ rpmsg_rx_cb_t cb, void *priv,
+ struct rpmsg_channel_info chinfo);
 
 every rpmsg address in the system is bound to an rx callback (so when
 inbound messages arrive, they are dispatched by the rpmsg bus using the
-- 
2.27.0

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v4 1/3] virtio: add dma-buf support for exported objects

[Guennadi Liakhovetski]

Hi David,

On Fri, Jun 19, 2020 at 10:57:37AM +0900, David Stevens wrote:
> On Thu, Jun 18, 2020 at 9:29 PM Guennadi Liakhovetski
>  wrote:
> >
> > Hi Michael,
> >
> > On Thu, Jun 04, 2020 at 03:05:23PM -0400, Michael S. Tsirkin wrote:
> > > On Tue, May 26, 2020 at 07:58:09PM +0900, David Stevens wrote:
> > > > This change adds a new flavor of dma-bufs that can be used by virtio
> > > > drivers to share exported objects. A virtio dma-buf can be queried by
> > > > virtio drivers to obtain the UUID which identifies the underlying
> > > > exported object.
> > > >
> > > > Signed-off-by: David Stevens 
> > >
> > > Is this just for graphics? If yes I'd rather we put it in the graphics
> > > driver. We can always move it later ...
> >
> > Wouldn't this be the API that audio virtualisation will have to use to share
> > buffers between the host and any guests?
> 
> The new flavor of dma-buf isn't directly related to sharing buffers
> between the host and the guest. The purpose of this API is to help
> share buffers between multiple virtio devices - e.g. share buffers
> created by a virito-gpu device with a virito-video device. In
> particular, the new flavor of dma-buf provides a mechanism to attach
> identifying metadata to a dma-buf object that is shared between
> different virtio drivers in a single guest. This identifying metadata
> can then be passed to the importing device and used to fetch some
> resource from the exporting device. But the new flavor of dma-buf is
> an abstraction within the guest kernel, independent of the host-guest
> boundary, and it's definitely not necessary if we're only talking
> about a single virtio subsystem.

Thanks for the explanation!

Regards
Guennadi

> > > > ---
> > > >  drivers/virtio/Makefile |  2 +-
> > > >  drivers/virtio/virtio.c |  6 +++
> > > >  drivers/virtio/virtio_dma_buf.c | 89 +
> > > >  include/linux/virtio.h  |  1 +
> > > >  include/linux/virtio_dma_buf.h  | 58 +
> > > >  5 files changed, 155 insertions(+), 1 deletion(-)
> > > >  create mode 100644 drivers/virtio/virtio_dma_buf.c
> > > >  create mode 100644 include/linux/virtio_dma_buf.h
> > > >
> > > > diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
> > > > index 29a1386ecc03..ecdae5b596de 100644
> > > > --- a/drivers/virtio/Makefile
> > > > +++ b/drivers/virtio/Makefile
> > > > @@ -1,5 +1,5 @@
> > > >  # SPDX-License-Identifier: GPL-2.0
> > > > -obj-$(CONFIG_VIRTIO) += virtio.o virtio_ring.o
> > > > +obj-$(CONFIG_VIRTIO) += virtio.o virtio_ring.o virtio_dma_buf.o
> > > >  obj-$(CONFIG_VIRTIO_MMIO) += virtio_mmio.o
> > > >  obj-$(CONFIG_VIRTIO_PCI) += virtio_pci.o
> > > >  virtio_pci-y := virtio_pci_modern.o virtio_pci_common.o
> > > > diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
> > > > index a977e32a88f2..5d46f0ded92d 100644
> > > > --- a/drivers/virtio/virtio.c
> > > > +++ b/drivers/virtio/virtio.c
> > > > @@ -357,6 +357,12 @@ int register_virtio_device(struct virtio_device 
> > > > *dev)
> > > >  }
> > > >  EXPORT_SYMBOL_GPL(register_virtio_device);
> > > >
> > > > +bool is_virtio_device(struct device *dev)
> > > > +{
> > > > +   return dev->bus == _bus;
> > > > +}
> > > > +EXPORT_SYMBOL_GPL(is_virtio_device);
> > > > +
> > > >  void unregister_virtio_device(struct virtio_device *dev)
> > > >  {
> > > > int index = dev->index; /* save for after device release */
> > > > diff --git a/drivers/virtio/virtio_dma_buf.c 
> > > > b/drivers/virtio/virtio_dma_buf.c
> > > > new file mode 100644
> > > > index ..23e3399b11ed
> > > > --- /dev/null
> > > > +++ b/drivers/virtio/virtio_dma_buf.c
> > > > @@ -0,0 +1,89 @@
> > > > +// SPDX-License-Identifier: GPL-2.0-or-later
> > > > +/*
> > > > + * dma-bufs for virtio exported objects
> > > > + *
> > > > + * Copyright (C) 2020 Google, Inc.
> > > > + */
> > > > +
> > > > +#include 
> > > > +
> > > > +/**
> > > > + * virtio_dma_buf_export - Creates a new dma-buf for a virtio exported 
> > > > object
> > > > + *
> > > > + * This wraps

Re: [PATCH v3 5/5] vhost: add an RPMsg API

[Guennadi Liakhovetski]

On Thu, Jun 18, 2020 at 03:52:42PM +0200, Vincent Whitchurch wrote:
> On Thu, Jun 18, 2020 at 12:39:40PM +0200, Guennadi Liakhovetski wrote:
> > On Thu, Jun 18, 2020 at 11:33:24AM +0200, Vincent Whitchurch wrote:
> > > By the "normal rpmsg API" I mean register_rpmsg_driver(), rpmsg_send(),
> > > etc.  That API is not tied to virtio in any way and there are other
> > > non-virtio backends for this API in the tree.  So it seems quite natural
> > > to implement a vhost backend for this API so that both sides of the link
> > > can use the same API but different backends, instead of forcing them to
> > > use of different APIs.
> > 
> > Ok, I see what you mean now. But I'm not sure this is useful or desired. 
> > I'm 
> > not an expert in KVM / VirtIO, I've only been working in the area for less 
> > than a year, so, I might well be wrong.
> > 
> > You're proposing to use the rpmsg API in vhost drivers. As far as I 
> > understand so far that API was only designated for the Linux side (in case 
> > of 
> > AMPs) which corresponds to VM guests in virtualisation case. So, I'm not 
> > sure 
> > we want to use the same API for the hosts? This can be done as you have 
> > illustrated, but is it desirable? The vhost API is far enough from the 
> > VirtIO 
> > driver API, so I'm not sure why we want the same API for rpmsg?
> 
> Note that "the Linux side" is ambiguous for AMP since both sides can be
> Linux, as they happen to be in my case.  I'm running virtio/rpmsg
> between two physical processors (of different architectures), both
> running Linux.

Ok, interesting, I didn't know such configurations were used too. I understood 
the Linux rpmsg implementation in the way, that it's assumed, that the "host" 
has to boot the "device" by sending an ELF formatted executable image to it, is 
that optional? You aren't sending a complete Linux image to the device side, 
are you?

> virtio has distinct driver and device roles so the completely different
> APIs on each side are understandable.  But I don't see that distinction
> in the rpmsg API which is why it seems like a good idea to me to make it
> work from both sides of the link and allow the reuse of drivers like
> rpmsg-char, instead of imposing virtio's distinction on rpmsg.

Understand. In principle I'm open to this idea, but before I implement it it 
would be good to know what maintainers think?

Thanks
Guennadi
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v4 1/3] virtio: add dma-buf support for exported objects

[Guennadi Liakhovetski]

Hi Michael,

On Thu, Jun 04, 2020 at 03:05:23PM -0400, Michael S. Tsirkin wrote:
> On Tue, May 26, 2020 at 07:58:09PM +0900, David Stevens wrote:
> > This change adds a new flavor of dma-bufs that can be used by virtio
> > drivers to share exported objects. A virtio dma-buf can be queried by
> > virtio drivers to obtain the UUID which identifies the underlying
> > exported object.
> > 
> > Signed-off-by: David Stevens 
> 
> Is this just for graphics? If yes I'd rather we put it in the graphics
> driver. We can always move it later ...

Wouldn't this be the API that audio virtualisation will have to use to share 
buffers between the host and any guests?

Thanks
Guennadi

> > ---
> >  drivers/virtio/Makefile |  2 +-
> >  drivers/virtio/virtio.c |  6 +++
> >  drivers/virtio/virtio_dma_buf.c | 89 +
> >  include/linux/virtio.h  |  1 +
> >  include/linux/virtio_dma_buf.h  | 58 +
> >  5 files changed, 155 insertions(+), 1 deletion(-)
> >  create mode 100644 drivers/virtio/virtio_dma_buf.c
> >  create mode 100644 include/linux/virtio_dma_buf.h
> > 
> > diff --git a/drivers/virtio/Makefile b/drivers/virtio/Makefile
> > index 29a1386ecc03..ecdae5b596de 100644
> > --- a/drivers/virtio/Makefile
> > +++ b/drivers/virtio/Makefile
> > @@ -1,5 +1,5 @@
> >  # SPDX-License-Identifier: GPL-2.0
> > -obj-$(CONFIG_VIRTIO) += virtio.o virtio_ring.o
> > +obj-$(CONFIG_VIRTIO) += virtio.o virtio_ring.o virtio_dma_buf.o
> >  obj-$(CONFIG_VIRTIO_MMIO) += virtio_mmio.o
> >  obj-$(CONFIG_VIRTIO_PCI) += virtio_pci.o
> >  virtio_pci-y := virtio_pci_modern.o virtio_pci_common.o
> > diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
> > index a977e32a88f2..5d46f0ded92d 100644
> > --- a/drivers/virtio/virtio.c
> > +++ b/drivers/virtio/virtio.c
> > @@ -357,6 +357,12 @@ int register_virtio_device(struct virtio_device *dev)
> >  }
> >  EXPORT_SYMBOL_GPL(register_virtio_device);
> >  
> > +bool is_virtio_device(struct device *dev)
> > +{
> > +   return dev->bus == _bus;
> > +}
> > +EXPORT_SYMBOL_GPL(is_virtio_device);
> > +
> >  void unregister_virtio_device(struct virtio_device *dev)
> >  {
> > int index = dev->index; /* save for after device release */
> > diff --git a/drivers/virtio/virtio_dma_buf.c 
> > b/drivers/virtio/virtio_dma_buf.c
> > new file mode 100644
> > index ..23e3399b11ed
> > --- /dev/null
> > +++ b/drivers/virtio/virtio_dma_buf.c
> > @@ -0,0 +1,89 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * dma-bufs for virtio exported objects
> > + *
> > + * Copyright (C) 2020 Google, Inc.
> > + */
> > +
> > +#include 
> > +
> > +/**
> > + * virtio_dma_buf_export - Creates a new dma-buf for a virtio exported 
> > object
> > + *
> > + * This wraps dma_buf_export() to allow virtio drivers to create a dma-buf
> > + * for an virtio exported object that can be queried by other virtio 
> > drivers
> > + * for the object's UUID.
> > + */
> > +struct dma_buf *virtio_dma_buf_export(
> > +   const struct virtio_dma_buf_export_info *virtio_exp_info)
> > +{
> > +   struct dma_buf_export_info exp_info;
> > +
> > +   if (!virtio_exp_info->ops
> > +   || virtio_exp_info->ops->ops.attach != _dma_buf_attach
> > +   || !virtio_exp_info->ops->get_uuid) {
> > +   return ERR_PTR(-EINVAL);
> > +   }
> > +
> > +   exp_info.exp_name = virtio_exp_info->exp_name;
> > +   exp_info.owner = virtio_exp_info->owner;
> > +   exp_info.ops = _exp_info->ops->ops;
> > +   exp_info.size = virtio_exp_info->size;
> > +   exp_info.flags = virtio_exp_info->flags;
> > +   exp_info.resv = virtio_exp_info->resv;
> > +   exp_info.priv = virtio_exp_info->priv;
> > +   BUILD_BUG_ON(sizeof(struct virtio_dma_buf_export_info)
> > +!= sizeof(struct dma_buf_export_info));
> 
> This is the only part that gives me pause. Why do we need this hack?
> What's wrong with just using dma_buf_export_info directly,
> and if you want the virtio ops, just using container_off?
> 
> 
> 
> > +
> > +   return dma_buf_export(_info);
> > +}
> > +EXPORT_SYMBOL(virtio_dma_buf_export);
> > +
> > +/**
> > + * virtio_dma_buf_attach - mandatory attach callback for virtio dma-bufs
> > + */
> > +int virtio_dma_buf_attach(struct dma_buf *dma_buf,
> > + struct dma_buf_attachment *attach)
> > +{
> > +   int ret;
> > +   const struct virtio_dma_buf_ops *ops = container_of(
> > +   dma_buf->ops, const struct virtio_dma_buf_ops, ops);
> > +
> > +   if (ops->device_attach) {
> > +   ret = ops->device_attach(dma_buf, attach);
> > +   if (ret)
> > +   return ret;
> > +   }
> > +   return 0;
> > +}
> > +EXPORT_SYMBOL(virtio_dma_buf_attach);
> > +
> > +/**
> > + * is_virtio_dma_buf - returns true if the given dma-buf is a virtio 
> > dma-buf
> > + * @dma_buf: buffer to query
> > + */
> > +bool is_virtio_dma_buf(struct dma_buf *dma_buf)
> > +{
> > +   return dma_buf->ops->attach == 

Re: [PATCH v3 5/5] vhost: add an RPMsg API

[Guennadi Liakhovetski]

On Thu, Jun 18, 2020 at 11:33:24AM +0200, Vincent Whitchurch wrote:
> On Thu, Jun 18, 2020 at 11:03:42AM +0200, Guennadi Liakhovetski wrote:
> > On Wed, Jun 17, 2020 at 09:17:42PM +0200, Vincent Whitchurch wrote:
> > > On Wed, May 27, 2020 at 08:05:41PM +0200, Guennadi Liakhovetski wrote:
> > > > Linux supports running the RPMsg protocol over the VirtIO transport
> > > > protocol, but currently there is only support for VirtIO clients and
> > > > no support for a VirtIO server. This patch adds a vhost-based RPMsg
> > > > server implementation.
> > > 
> > > This looks really useful, but why is it implemented as an API and not as
> > > a real vhost driver which implements an rpmsg bus?  If you implement it
> > > as a vhost driver which implements rpmsg_device_ops and
> > > rpmsg_endpoint_ops, then wouldn't you be able to implement your
> > > vhost-sof driver using the normal rpmsg APIs?
> > 
> > Sorry, not sure what you mean by the "normal rpmsg API?" Do you mean the 
> > VirtIO RPMsg API? But that's the opposite side of the link - that's the 
> > guest side in the VM case and the Linux side in the remoteproc case. What 
> > this API is adding is a vhost RPMsg API. The kernel vhost framework 
> > itself is essentially a library of functions. Kernel vhost drivers simply 
> > create a misc device and use the vhost functions for some common 
> > functionality. This RPMsg vhost API stays in the same concept and provides 
> > further functions for RPMsg specific vhost operation.
> 
> By the "normal rpmsg API" I mean register_rpmsg_driver(), rpmsg_send(),
> etc.  That API is not tied to virtio in any way and there are other
> non-virtio backends for this API in the tree.  So it seems quite natural
> to implement a vhost backend for this API so that both sides of the link
> can use the same API but different backends, instead of forcing them to
> use of different APIs.

Ok, I see what you mean now. But I'm not sure this is useful or desired. I'm 
not an expert in KVM / VirtIO, I've only been working in the area for less 
than a year, so, I might well be wrong.

You're proposing to use the rpmsg API in vhost drivers. As far as I 
understand so far that API was only designated for the Linux side (in case of 
AMPs) which corresponds to VM guests in virtualisation case. So, I'm not sure 
we want to use the same API for the hosts? This can be done as you have 
illustrated, but is it desirable? The vhost API is far enough from the VirtIO 
driver API, so I'm not sure why we want the same API for rpmsg?

Thanks
Guennadi

> > > I tried quickly hooking up this code to such a vhost driver and I was
> > > able to communicate between host and guest systems with both
> > > rpmsg-client-sample and rpmsg-char which almost no modifications to
> > > those drivers.
> > 
> > You mean you used this patch to create RPMsg vhost drivers? Without 
> > creating a vhost RPMsg bus? Nice, glad to hear that!
> 
> Not quite, I hacked togther a single generic vhost-rpmsg-bus driver
> which just wraps the API in this patch and implements a basic
> rpmsg_device_ops and rpmsg_endpoint_ops.  Then with the following
> patches and no other vhost-specific API use, I was able to load and use
> the same rpmsg-char and rpmsg-client-sample drivers on both host and
> guest kernels.
> 
> Userspace sets up the vhost using vhost-rpmsg-bus' misc device and
> triggers creation of an rpdev which leads to a probe of the (for
> example) rpmsg-client-sample driver on the host (server), which, in
> turn, via NS announcement, triggers a creation of an rpdev and a probe
> of the rpmsg-client-sample driver on the guest (client).
> 
> diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c
> index a76b963a7e5..7a03978d002 100644
> --- a/drivers/rpmsg/rpmsg_char.c
> +++ b/drivers/rpmsg/rpmsg_char.c
> @@ -104,6 +104,11 @@ static int rpmsg_ept_cb(struct rpmsg_device *rpdev, void 
> *buf, int len,
>   struct rpmsg_eptdev *eptdev = priv;
>   struct sk_buff *skb;
>  
> + if (rpdev->dst == RPMSG_ADDR_ANY) {
> + printk("%s: got client address %#x from first rx!\n", __func__, 
> addr);
> + rpdev->dst = addr;
> + }
> +
>   skb = alloc_skb(len, GFP_ATOMIC);
>   if (!skb)
>   return -ENOMEM;
> @@ -235,6 +240,12 @@ static ssize_t rpmsg_eptdev_write(struct file *filp, 
> const char __user *buf,
>   goto unlock_eptdev;
>   }
>  
> + if (eptdev->rpdev->dst == RPMSG_ADDR_ANY) {
> + ret = -EPIPE;
> + WARN(1, "Cannot write first on server, must wait for 
> clie

Re: [PATCH v3 5/5] vhost: add an RPMsg API

[Guennadi Liakhovetski]

Hi Vincent,

On Wed, Jun 17, 2020 at 09:17:42PM +0200, Vincent Whitchurch wrote:
> On Wed, May 27, 2020 at 08:05:41PM +0200, Guennadi Liakhovetski wrote:
> > Linux supports running the RPMsg protocol over the VirtIO transport
> > protocol, but currently there is only support for VirtIO clients and
> > no support for a VirtIO server. This patch adds a vhost-based RPMsg
> > server implementation.
> 
> This looks really useful, but why is it implemented as an API and not as
> a real vhost driver which implements an rpmsg bus?  If you implement it
> as a vhost driver which implements rpmsg_device_ops and
> rpmsg_endpoint_ops, then wouldn't you be able to implement your
> vhost-sof driver using the normal rpmsg APIs?

Sorry, not sure what you mean by the "normal rpmsg API?" Do you mean the 
VirtIO RPMsg API? But that's the opposite side of the link - that's the 
guest side in the VM case and the Linux side in the remoteproc case. What 
this API is adding is a vhost RPMsg API. The kernel vhost framework 
itself is essentially a library of functions. Kernel vhost drivers simply 
create a misc device and use the vhost functions for some common 
functionality. This RPMsg vhost API stays in the same concept and provides 
further functions for RPMsg specific vhost operation.

> I tried quickly hooking up this code to such a vhost driver and I was
> able to communicate between host and guest systems with both
> rpmsg-client-sample and rpmsg-char which almost no modifications to
> those drivers.

You mean you used this patch to create RPMsg vhost drivers? Without 
creating a vhost RPMsg bus? Nice, glad to hear that!

Thanks
Guennadi
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [RFC 12/12] rpmsg: add a device ID to also bind to the ADSP device

[Guennadi Liakhovetski]

Hi Mathieu,

On Mon, Jun 08, 2020 at 10:17:57AM -0600, Mathieu Poirier wrote:
> On Fri, Jun 05, 2020 at 08:46:59AM +0200, Guennadi Liakhovetski wrote:
> > Hi Mathieu,
> > 
> > On Thu, Jun 04, 2020 at 02:01:56PM -0600, Mathieu Poirier wrote:
> > > On Fri, May 29, 2020 at 09:37:22AM +0200, Guennadi Liakhovetski wrote:
> > > > The ADSP device uses the RPMsg API to connect vhost and VirtIO SOF
> > > > Audio DSP drivers on KVM host and guest.
> > > > 
> > > > Signed-off-by: Guennadi Liakhovetski 
> > > > 
> > > > ---
> > > >  drivers/rpmsg/virtio_rpmsg_bus.c | 1 +
> > > >  1 file changed, 1 insertion(+)
> > > > 
> > > > diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c 
> > > > b/drivers/rpmsg/virtio_rpmsg_bus.c
> > > > index f3bd050..ebe3f19 100644
> > > > --- a/drivers/rpmsg/virtio_rpmsg_bus.c
> > > > +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
> > > > @@ -949,6 +949,7 @@ static void rpmsg_remove(struct virtio_device *vdev)
> > > >  
> > > >  static struct virtio_device_id id_table[] = {
> > > > { VIRTIO_ID_RPMSG, VIRTIO_DEV_ANY_ID },
> > > > +   { VIRTIO_ID_ADSP, VIRTIO_DEV_ANY_ID },
> > > 
> > > I am fine with this patch but won't add an RB because of the (many) 
> > > checkpatch
> > > errors.  Based on the comment I made on the previous set seeing those was
> > > unexpected.
> > 
> > Are you using "--strict?" Sorry, I don't see any checkpatch errors, only 
> > warnings. 
> 
> No, plane checkpatch on the rproc-next branch.
> 
> > Most of them are "over 80 characters" which as we now know is no more an 
> > issue,
> 
> There is a thread discussing the matter but I have not seen a clear resolution
> yet.

I think the resolution is pretty clear as defined by Linus, but maybe it has 
changed 
again since I last checked.

> > I just haven't updated my tree yet. Most others are really minor IMHO. 
> > Maybe one
> 
> Minor or not, if checkpatch complains then it is important enough to address. 
>  I
> am willing to overlook the lines over 80 characters but everything else needs 
> to
> be dealt with.

Sure, checkpatch should be run before each patch submission and whatever it 
reports 
should be considered. As Documentation/process/submitting-patches.rst clearly 
states:

"Check your patches with the patch style checker prior to submission
(scripts/checkpatch.pl).  Note, though, that the style checker should be
viewed as a guide, not as a replacement for human judgment.  If your code
looks better with a violation then its probably best left alone."

So, yes, I checked all what checkepatch reported and used my judgement to 
decide 
which recommendations to take and which to ignore.

Thanks
Guennadi

> Thanks,
> Mathieu
>  
> > of them I actually would want to fix - using "help" instead of "---help---" 
> > in 
> > Kconfig. What errors are you seeing in your checks?
> > 
> > Thanks
> > Guennadi
> > 
> > > Thanks,
> > > Mathieu
> > > 
> > > > { 0 },
> > > >  };
> > > >  
> > > > -- 
> > > > 1.9.3
> > > > 
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v3 0/5] Add a vhost RPMsg API

[Guennadi Liakhovetski]

On Mon, Jun 08, 2020 at 12:15:26PM +0200, Guennadi Liakhovetski wrote:
> On Mon, Jun 08, 2020 at 05:19:06AM -0400, Michael S. Tsirkin wrote:
> > On Mon, Jun 08, 2020 at 11:11:00AM +0200, Guennadi Liakhovetski wrote:
> > > Update: I looked through VirtIO 1.0 and 1.1 specs, data format their, 
> > > including byte order, is defined on a per-device type basis. RPMsg is 
> > > indeed included in the spec as device type 7, but that's the only 
> > > mention of it in both versions. It seems RPMsg over VirtIO isn't 
> > > standardised yet.
> > 
> > Yes. And it would be very good to have some standartization before we
> > keep adding things. For example without any spec if host code breaks
> > with some guests, how do we know which side should be fixed?
> > 
> > > Also it looks like newer interface definitions 
> > > specify using "guest native endianness" for Virtual Queue data.
> > 
> > They really don't or shouldn't. That's limited to legacy chapters.
> > Some definitions could have slipped through but it's not
> > the norm. I just quickly looked through the 1.1 spec and could
> > not find any instances that specify "guest native endianness"
> > but feel free to point them out to me.
> 
> Oh, there you go. No, sorry, my fault, it's the other way round: "guest 
> native" is for legacy and LE is for current / v1.0 and up.
> 
> > > So 
> > > I think the same should be done for RPMsg instead of enforcing LE?
> > 
> > That makes hardware implementations as well as any cross-endian
> > hypervisors tricky.
> 
> Yes, LE it is then. And we need to add some text to the spec.

I found the protocol and the message format definition: 
https://github.com/OpenAMP/open-amp/wiki/RPMsg-Messaging-Protocol#transport-layer---rpmsg
 
Don't know what the best way for referencing it in the VirtIO standard 
would be: just a link to the source or a quote.

Thanks
Guennadi
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v3 0/5] Add a vhost RPMsg API

[Guennadi Liakhovetski]

On Mon, Jun 08, 2020 at 05:19:06AM -0400, Michael S. Tsirkin wrote:
> On Mon, Jun 08, 2020 at 11:11:00AM +0200, Guennadi Liakhovetski wrote:
> > Update: I looked through VirtIO 1.0 and 1.1 specs, data format their, 
> > including byte order, is defined on a per-device type basis. RPMsg is 
> > indeed included in the spec as device type 7, but that's the only 
> > mention of it in both versions. It seems RPMsg over VirtIO isn't 
> > standardised yet.
> 
> Yes. And it would be very good to have some standartization before we
> keep adding things. For example without any spec if host code breaks
> with some guests, how do we know which side should be fixed?
> 
> > Also it looks like newer interface definitions 
> > specify using "guest native endianness" for Virtual Queue data.
> 
> They really don't or shouldn't. That's limited to legacy chapters.
> Some definitions could have slipped through but it's not
> the norm. I just quickly looked through the 1.1 spec and could
> not find any instances that specify "guest native endianness"
> but feel free to point them out to me.

Oh, there you go. No, sorry, my fault, it's the other way round: "guest 
native" is for legacy and LE is for current / v1.0 and up.

> > So 
> > I think the same should be done for RPMsg instead of enforcing LE?
> 
> That makes hardware implementations as well as any cross-endian
> hypervisors tricky.

Yes, LE it is then. And we need to add some text to the spec.

In theory there could be a backward compatibility issue - in case someone 
was already using virtio_rpmsg_bus.c in BE mode, but I very much doubt 
that...

Thanks
Guennadi
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v3 0/5] Add a vhost RPMsg API

[Guennadi Liakhovetski]

Update: I looked through VirtIO 1.0 and 1.1 specs, data format their, 
including byte order, is defined on a per-device type basis. RPMsg is 
indeed included in the spec as device type 7, but that's the only 
mention of it in both versions. It seems RPMsg over VirtIO isn't 
standardised yet. Also it looks like newer interface definitions 
specify using "guest native endianness" for Virtual Queue data. So 
I think the same should be done for RPMsg instead of enforcing LE?

Thanks
Guennadi

On Mon, Jun 08, 2020 at 09:37:15AM +0200, Guennadi Liakhovetski wrote:
> Hi Michael,
> 
> On Fri, Jun 05, 2020 at 08:34:35AM +0200, Guennadi Liakhovetski wrote:
> > 
> > On Thu, Jun 04, 2020 at 03:23:37PM -0400, Michael S. Tsirkin wrote:
> 
> [snip]
> 
> > > Another it's out of line with 1.0 spec passing guest
> > > endian data around. Won't work if host and guest
> > > endian-ness do not match. Should pass eveything in LE and
> > > convert.
> > 
> > Yes, I have to fix this, thanks.
> 
> Just to make sure my understanding is correct: this would involve also 
> modifying the current virtio_rpmsg_bus.c implementation to add 
> endianness conversions. That's what you meant, right?
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v3 0/5] Add a vhost RPMsg API

[Guennadi Liakhovetski]

Hi Michael,

On Fri, Jun 05, 2020 at 08:34:35AM +0200, Guennadi Liakhovetski wrote:
> 
> On Thu, Jun 04, 2020 at 03:23:37PM -0400, Michael S. Tsirkin wrote:

[snip]

> > Another it's out of line with 1.0 spec passing guest
> > endian data around. Won't work if host and guest
> > endian-ness do not match. Should pass eveything in LE and
> > convert.
> 
> Yes, I have to fix this, thanks.

Just to make sure my understanding is correct: this would involve also 
modifying the current virtio_rpmsg_bus.c implementation to add 
endianness conversions. That's what you meant, right?

Thanks
Guennadi
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [RFC 12/12] rpmsg: add a device ID to also bind to the ADSP device

[Guennadi Liakhovetski]

Hi Mathieu,

On Thu, Jun 04, 2020 at 02:01:56PM -0600, Mathieu Poirier wrote:
> On Fri, May 29, 2020 at 09:37:22AM +0200, Guennadi Liakhovetski wrote:
> > The ADSP device uses the RPMsg API to connect vhost and VirtIO SOF
> > Audio DSP drivers on KVM host and guest.
> > 
> > Signed-off-by: Guennadi Liakhovetski 
> > ---
> >  drivers/rpmsg/virtio_rpmsg_bus.c | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c 
> > b/drivers/rpmsg/virtio_rpmsg_bus.c
> > index f3bd050..ebe3f19 100644
> > --- a/drivers/rpmsg/virtio_rpmsg_bus.c
> > +++ b/drivers/rpmsg/virtio_rpmsg_bus.c
> > @@ -949,6 +949,7 @@ static void rpmsg_remove(struct virtio_device *vdev)
> >  
> >  static struct virtio_device_id id_table[] = {
> > { VIRTIO_ID_RPMSG, VIRTIO_DEV_ANY_ID },
> > +   { VIRTIO_ID_ADSP, VIRTIO_DEV_ANY_ID },
> 
> I am fine with this patch but won't add an RB because of the (many) checkpatch
> errors.  Based on the comment I made on the previous set seeing those was
> unexpected.

Are you using "--strict?" Sorry, I don't see any checkpatch errors, only 
warnings. 
Most of them are "over 80 characters" which as we now know is no more an issue, 
I just haven't updated my tree yet. Most others are really minor IMHO. Maybe 
one 
of them I actually would want to fix - using "help" instead of "---help---" in 
Kconfig. What errors are you seeing in your checks?

Thanks
Guennadi

> Thanks,
> Mathieu
> 
> > { 0 },
> >  };
> >  
> > -- 
> > 1.9.3
> > 
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [RFC 11/12] rpmsg: increase buffer size and reduce buffer number

[Guennadi Liakhovetski]

Hi Mathieu,

On Thu, Jun 04, 2020 at 01:58:39PM -0600, Mathieu Poirier wrote:
> Hi Guennadi,
> 
> On Fri, May 29, 2020 at 09:37:21AM +0200, Guennadi Liakhovetski wrote:
> > It is hard to imagine use-cases where 512 buffers would really be
> > needed, whereas 512 bytes per buffer might be too little. Change this
> > to use 16 16KiB buffers instead.
> > 
> > Signed-off-by: Guennadi Liakhovetski 
> > ---
> >  include/linux/virtio_rpmsg.h | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/include/linux/virtio_rpmsg.h b/include/linux/virtio_rpmsg.h
> > index 679be8b..1add468 100644
> > --- a/include/linux/virtio_rpmsg.h
> > +++ b/include/linux/virtio_rpmsg.h
> > @@ -72,8 +72,8 @@ enum rpmsg_ns_flags {
> >   * can change this without changing anything in the firmware of the remote
> >   * processor.
> >   */
> > -#define MAX_RPMSG_NUM_BUFS 512
> > -#define MAX_RPMSG_BUF_SIZE 512
> > +#define MAX_RPMSG_NUM_BUFS (512 / 32)
> > +#define MAX_RPMSG_BUF_SIZE (512 * 32)
> 
> These have been a standard in the rpmsg protocol since the inception of the
> subsystem 9 years ago and can't be changed without serious impact to existing
> implementations.

Yes, I expected this to raise complaints. I just modified them to be able to 
run my code, but a better solution is needed for sure.

> I suggest to dynamically set the number and size of the buffers to use
> based on the value of virtio_device_id::device.  To do that please spin
> off a new function, something like rpmsg_get_buffer_size(), and in there use
> the device ID to fetch the numbers based on vdev->id->device.  That way the
> rpmsg driver can be used by multiple clients and the specifics of the buffers
> adjusted without impact to other users.

I'll look into this!

Thanks
Guennadi

> Thanks,
> Mathieu
> 
> >  
> >  /* Address 53 is reserved for advertising remote services */
> >  #define RPMSG_NS_ADDR  53
> > -- 
> > 1.9.3
> > 
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v3 0/5] Add a vhost RPMsg API

[Guennadi Liakhovetski]

Hi Michael,

Thanks for your review.

On Thu, Jun 04, 2020 at 03:23:37PM -0400, Michael S. Tsirkin wrote:
> On Wed, May 27, 2020 at 08:05:36PM +0200, Guennadi Liakhovetski wrote:
> > 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. 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, ready
> > for review and submission, available at
> > https://github.com/thesofproject/linux/pull/1501/commits
> > A further patch for the ADSP vhost RPMsg driver will be sent
> > separately for review only since it cannot be merged without audio
> > patches being upstreamed first.
> 
> 
> RPMsg over virtio has several problems. One is that it's
> not specced at all. Before we add more stuff, I'd like so
> see at least an attempt at describing what it's supposed to do.

Sure, I can work on this with the original authors of the virtio-rpmsg 
implementation.

> Another it's out of line with 1.0 spec passing guest
> endian data around. Won't work if host and guest
> endian-ness do not match. Should pass eveything in LE and
> convert.

Yes, I have to fix this, thanks.

> It's great to see it's seeing active development finally.
> Do you think you will have time to address these?

Sure, I'll try to take care of them.

Thanks
Guennadi

> > Guennadi Liakhovetski (5):
> >   vhost: convert VHOST_VSOCK_SET_RUNNING to a generic ioctl
> >   vhost: (cosmetic) remove a superfluous variable initialisation
> >   rpmsg: move common structures and defines to headers
> >   rpmsg: update documentation
> >   vhost: add an RPMsg API
> > 
> >  Documentation/rpmsg.txt  |   6 +-
> >  drivers/rpmsg/virtio_rpmsg_bus.c |  78 +---
> >  drivers/vhost/Kconfig|   7 +
> >  drivers/vhost/Makefile   |   3 +
> >  drivers/vhost/rpmsg.c| 382 
> > +++
> >  drivers/vhost/vhost.c|   2 +-
> >  drivers/vhost/vhost_rpmsg.h  |  74 
> >  include/linux/virtio_rpmsg.h |  81 +
> >  include/uapi/linux/rpmsg.h   |   3 +
> >  include/uapi/linux/vhost.h   |   4 +-
> >  10 files changed, 559 insertions(+), 81 deletions(-)
> >  create mode 100644 drivers/vhost/rpmsg.c
> >  create mode 100644 drivers/vhost/vhost_rpmsg.h
> >  create mode 100644 include/linux/virtio_rpmsg.h
> > 
> > -- 
> > 1.9.3
> 
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[RFC 11/12] rpmsg: increase buffer size and reduce buffer number

[Guennadi Liakhovetski]

It is hard to imagine use-cases where 512 buffers would really be
needed, whereas 512 bytes per buffer might be too little. Change this
to use 16 16KiB buffers instead.

Signed-off-by: Guennadi Liakhovetski 
---
 include/linux/virtio_rpmsg.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/virtio_rpmsg.h b/include/linux/virtio_rpmsg.h
index 679be8b..1add468 100644
--- a/include/linux/virtio_rpmsg.h
+++ b/include/linux/virtio_rpmsg.h
@@ -72,8 +72,8 @@ enum rpmsg_ns_flags {
  * can change this without changing anything in the firmware of the remote
  * processor.
  */
-#define MAX_RPMSG_NUM_BUFS 512
-#define MAX_RPMSG_BUF_SIZE 512
+#define MAX_RPMSG_NUM_BUFS (512 / 32)
+#define MAX_RPMSG_BUF_SIZE (512 * 32)
 
 /* Address 53 is reserved for advertising remote services */
 #define RPMSG_NS_ADDR  53
-- 
1.9.3

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[RFC 12/12] rpmsg: add a device ID to also bind to the ADSP device

[Guennadi Liakhovetski]

The ADSP device uses the RPMsg API to connect vhost and VirtIO SOF
Audio DSP drivers on KVM host and guest.

Signed-off-by: Guennadi Liakhovetski 
---
 drivers/rpmsg/virtio_rpmsg_bus.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index f3bd050..ebe3f19 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -949,6 +949,7 @@ static void rpmsg_remove(struct virtio_device *vdev)
 
 static struct virtio_device_id id_table[] = {
{ VIRTIO_ID_RPMSG, VIRTIO_DEV_ANY_ID },
+   { VIRTIO_ID_ADSP, VIRTIO_DEV_ANY_ID },
{ 0 },
 };
 
-- 
1.9.3

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[RFC 04/12] ASoC: SOF: add a power status IPC

[Guennadi Liakhovetski]

In a virtualised configuration the runtime PM of the host and any
guests aren't synchronised. But guests have to be able to tell the
host when they suspend and resume and know, whether the host has been
runtime suspended since that guests's topology had been sent to the
host last time. This is needed to decide whether to re-send the
topology again. To support this we add a new PM IPC message
SOF_IPC_PM_VFE_POWER_STATUS and a reset counter to track the state of
the DSP.

Signed-off-by: Guennadi Liakhovetski 
---
 include/sound/sof/header.h | 1 +
 sound/soc/sof/core.c   | 2 ++
 sound/soc/sof/ipc.c| 2 ++
 sound/soc/sof/loader.c | 4 
 sound/soc/sof/sof-priv.h   | 4 
 5 files changed, 13 insertions(+)

diff --git a/include/sound/sof/header.h b/include/sound/sof/header.h
index 2d35997..5ee296c 100644
--- a/include/sound/sof/header.h
+++ b/include/sound/sof/header.h
@@ -77,6 +77,7 @@
 #define SOF_IPC_PM_CLK_REQ SOF_CMD_TYPE(0x006)
 #define SOF_IPC_PM_CORE_ENABLE SOF_CMD_TYPE(0x007)
 #define SOF_IPC_PM_GATESOF_CMD_TYPE(0x008)
+#define SOF_IPC_PM_VFE_POWER_STATUSSOF_CMD_TYPE(0x010)
 
 /* component runtime config - multiple different types */
 #define SOF_IPC_COMP_SET_VALUE SOF_CMD_TYPE(0x001)
diff --git a/sound/soc/sof/core.c b/sound/soc/sof/core.c
index 17f264f..61f045c 100644
--- a/sound/soc/sof/core.c
+++ b/sound/soc/sof/core.c
@@ -8,6 +8,7 @@
 // Author: Liam Girdwood 
 //
 
+#include 
 #include 
 #include 
 #include 
@@ -312,6 +313,7 @@ int snd_sof_device_probe(struct device *dev, struct 
snd_sof_pdata *plat_data)
 #if IS_ENABLED(CONFIG_SND_SOC_SOF_DEBUG_PROBES)
sdev->extractor_stream_tag = SOF_PROBE_INVALID_NODE_ID;
 #endif
+   atomic_set(>dsp_reset_count, 0);
dev_set_drvdata(dev, sdev);
 
/* check all mandatory ops */
diff --git a/sound/soc/sof/ipc.c b/sound/soc/sof/ipc.c
index b3e1587..e9b0347 100644
--- a/sound/soc/sof/ipc.c
+++ b/sound/soc/sof/ipc.c
@@ -105,6 +105,8 @@ static void ipc_log_header(struct device *dev, u8 *text, 
u32 cmd)
str2 = "CLK_REQ"; break;
case SOF_IPC_PM_CORE_ENABLE:
str2 = "CORE_ENABLE"; break;
+   case SOF_IPC_PM_VFE_POWER_STATUS:
+   str2 = "VFE_POWER_STATUS"; break;
default:
str2 = "unknown type"; break;
}
diff --git a/sound/soc/sof/loader.c b/sound/soc/sof/loader.c
index 4a5b57e..df95bcb 100644
--- a/sound/soc/sof/loader.c
+++ b/sound/soc/sof/loader.c
@@ -10,6 +10,7 @@
 // Generic firmware loader.
 //
 
+#include 
 #include 
 #include 
 #include "ops.h"
@@ -620,6 +621,9 @@ int snd_sof_run_firmware(struct snd_sof_dev *sdev)
/* fw boot is complete. Update the active cores mask */
sdev->enabled_cores_mask = init_core_mask;
 
+   /* increment reset count */
+   atomic_add(1, >dsp_reset_count);
+
return 0;
 }
 EXPORT_SYMBOL(snd_sof_run_firmware);
diff --git a/sound/soc/sof/sof-priv.h b/sound/soc/sof/sof-priv.h
index 3ed39b8..29ab6ad 100644
--- a/sound/soc/sof/sof-priv.h
+++ b/sound/soc/sof/sof-priv.h
@@ -11,6 +11,7 @@
 #ifndef __SOUND_SOC_SOF_PRIV_H
 #define __SOUND_SOC_SOF_PRIV_H
 
+#include 
 #include 
 #include 
 #include 
@@ -425,6 +426,9 @@ struct snd_sof_dev {
unsigned int extractor_stream_tag;
 #endif
 
+   /* VirtIO fields for host and guest */
+   atomic_t dsp_reset_count;
+
/* DMA for Trace */
struct snd_dma_buffer dmatb;
struct snd_dma_buffer dmatp;
-- 
1.9.3

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[RFC 06/12] ASoC: SOF: add an RPMsg VirtIO DSP driver

[Guennadi Liakhovetski]

Add a VirtIO driver, designed to work with the SOF vhost driver,
using the RPMsg protocol layer. This driver allows SOF to be used on
Virtual Machines (VMs) where the host is also a Linux system, using
the SOF driver natively. This driver communicates with the host using
the RPMsg standard over Virtual Queues. This version uses 3 RPMsg
endpoints: for control, for data and for position updates. The
control endpoint uses exactly the same IPC protocol as what is used
by the SOF driver natively to communicate with the DSP.  In the
future a zero-copy capability should be added thus eliminating 2 out
of 3 endpoints and only preserving the control channel.

Signed-off-by: Guennadi Liakhovetski 
---
 include/sound/sof.h |   4 +
 include/sound/sof/header.h  |   2 +
 include/sound/sof/rpmsg.h   | 120 ++
 include/sound/sof/topology.h|   9 +-
 include/uapi/linux/virtio_ids.h |   1 +
 sound/soc/sof/Kconfig   |   7 +
 sound/soc/sof/Makefile  |   4 +
 sound/soc/sof/core.c|  29 +-
 sound/soc/sof/ipc.c |  16 +-
 sound/soc/sof/pcm.c |   9 +
 sound/soc/sof/rpmsg-vfe.c   | 881 
 sound/soc/sof/sof-priv.h|  28 ++
 sound/soc/sof/topology.c|  18 +-
 13 files changed, 1099 insertions(+), 29 deletions(-)
 create mode 100644 include/sound/sof/rpmsg.h
 create mode 100644 sound/soc/sof/rpmsg-vfe.c

diff --git a/include/sound/sof.h b/include/sound/sof.h
index f3e716c..761ef8c 100644
--- a/include/sound/sof.h
+++ b/include/sound/sof.h
@@ -17,6 +17,8 @@
 
 struct snd_sof_dsp_ops;
 
+struct sof_vfe;
+
 /*
  * SOF Platform data.
  */
@@ -30,6 +32,8 @@ struct snd_sof_pdata {
/* indicate how many first bytes shouldn't be loaded into DSP memory. */
size_t fw_offset;
 
+   struct sof_vfe *vfe;
+
/*
 * notification callback used if the hardware initialization
 * can take time or is handled in a workqueue. This callback
diff --git a/include/sound/sof/header.h b/include/sound/sof/header.h
index 5ee296c..9844fbe 100644
--- a/include/sound/sof/header.h
+++ b/include/sound/sof/header.h
@@ -67,6 +67,8 @@
 #define SOF_IPC_TPLG_PIPE_COMPLETE SOF_CMD_TYPE(0x013)
 #define SOF_IPC_TPLG_BUFFER_NEWSOF_CMD_TYPE(0x020)
 #define SOF_IPC_TPLG_BUFFER_FREE   SOF_CMD_TYPE(0x021)
+#define SOF_IPC_TPLG_VFE_GET   SOF_CMD_TYPE(0x030)
+#define SOF_IPC_TPLG_VFE_COMP_ID   SOF_CMD_TYPE(0x031)
 
 /* PM */
 #define SOF_IPC_PM_CTX_SAVESOF_CMD_TYPE(0x001)
diff --git a/include/sound/sof/rpmsg.h b/include/sound/sof/rpmsg.h
new file mode 100644
index ..73dc34c
--- /dev/null
+++ b/include/sound/sof/rpmsg.h
@@ -0,0 +1,120 @@
+/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) */
+/*
+ * Copyright(c) 2018-2020 Intel Corporation. All rights reserved.
+ *
+ *  Contact Information:
+ *  Author:Luo Xionghu 
+ * Liam Girdwood 
+ * Guennadi Liakhovetski 
+ */
+
+#ifndef _SOF_RPMSG_H
+#define _SOF_RPMSG_H
+
+#include 
+
+#include 
+
+/* host endpoint addresses */
+enum {
+   SOF_RPMSG_ADDR_IPC, /* IPC commands and replies */
+   SOF_RPMSG_ADDR_POSN,/* Stream position updates */
+   SOF_RPMSG_ADDR_DATA,/* Audio data */
+   SOF_RPMSG_ADDR_COUNT,   /* Number of RPMsg endpoints */
+};
+
+/**
+ * struct sof_rpmsg_ipc_tplg_req - request for topology data
+ * @hdr:   the standard SOF IPC header
+ * @offset:the current offset when transferring a split file
+ */
+struct sof_rpmsg_ipc_tplg_req {
+   struct sof_ipc_cmd_hdr hdr;
+   size_t offset;
+} __packed;
+
+/**
+ * struct sof_rpmsg_ipc_tplg_resp - response to a topology file request
+ * @reply: the standard SOF IPC response header
+ * @data:  the complete topology file
+ *
+ * The topology file is transferred from the host to the guest over a virtual
+ * queue in chunks of SOF_IPC_MSG_MAX_SIZE - sizeof(struct sof_ipc_reply), so
+ * for data transfer the @data array is much smaller than 64KiB. 64KiB is what
+ * is included in struct sof_vfe for permanent storage of the complete file.
+ */
+struct sof_rpmsg_ipc_tplg_resp {
+   struct sof_ipc_reply reply;
+   /* There exist topology files already larger than 40KiB */
+   uint8_t data[64 * 1024 - sizeof(struct sof_ipc_reply)];
+} __packed;
+
+/**
+ * struct sof_rpmsg_ipc_power_req - power status change IPC
+ * @hdr:   the standard SOF IPC header
+ * @power: 1: on, 0: off
+ */
+struct sof_rpmsg_ipc_power_req {
+   struct sof_ipc_cmd_hdr hdr;
+   uint32_t power;
+} __packed;
+
+enum sof_rpmsg_ipc_reset_status {
+   SOF_RPMSG_IPC_RESET_NONE,   /* Host hasn't been reset */
+   SOF_RPMSG_IPC_RESET_DONE,   /* Host has been reset */
+};
+
+/**
+ * struct sof_rpmsg_ipc_power_resp - response to a power status request
+ * @reply: the standard SOF IPC response header
+ * @reset_status: enum

[RFC 01/12] ASoC: add function parameters to enable forced path pruning

[Guennadi Liakhovetski]

This is a preparation for the host part of a virtualised VirtIO audio
host-guest driver pair. It adds a "mode" parameter to
soc_dpcm_runtime_update() to allow it to be used when stopping
streaming in a virtual machine, which requires forced DPCM audio path
pruning.

For audio virtualisation the host side driver will be using the vhost
API, i.e. it will run completely in the kernel. When a guest begins to
stream audio, the vhost calls snd_soc_runtime_activate() and
soc_dpcm_runtime_update() to activate an audio path and update audio
routing. When streaming is stopped, the vhost driver calls
soc_dpcm_runtime_update() and snd_soc_runtime_deactivate(). The latter
doesn't work at the moment, because the DPCM doesn't recognise the
path as inactive. We address this by adding a "mode" parameter to
soc_dpcm_runtime_update(). If virtualisation isn't used, the current
behaviour isn't affected.

Signed-off-by: Guennadi Liakhovetski 
---
 include/sound/soc-dpcm.h | 28 
 sound/soc/soc-compress.c |  2 +-
 sound/soc/soc-dapm.c |  8 +++---
 sound/soc/soc-pcm.c  | 67 +---
 4 files changed, 74 insertions(+), 31 deletions(-)

diff --git a/include/sound/soc-dpcm.h b/include/sound/soc-dpcm.h
index 0f6c50b..b961c06 100644
--- a/include/sound/soc-dpcm.h
+++ b/include/sound/soc-dpcm.h
@@ -61,6 +61,23 @@ enum snd_soc_dpcm_trigger {
SND_SOC_DPCM_TRIGGER_BESPOKE,
 };
 
+/**
+ * enum snd_soc_dpcm_update_mode - mode for calling soc_dpcm_runtime_update()
+ *
+ * @SND_SOC_DPCM_UPDATE_FULL:  default mode, used for mux, mixer, and
+ * volume widgets
+ * @SND_SOC_DPCM_UPDATE_NEW_ONLY:  a pipeline is starting. Skip checking
+ * for old paths.
+ * @SND_SOC_DPCM_UPDATE_OLD_ONLY:  a pipeline is shutting down. Skip
+ * checking for new paths, force old path
+ * pruning.
+ */
+enum snd_soc_dpcm_update_mode {
+   SND_SOC_DPCM_UPDATE_FULL,
+   SND_SOC_DPCM_UPDATE_NEW_ONLY,
+   SND_SOC_DPCM_UPDATE_OLD_ONLY,
+};
+
 /*
  * Dynamic PCM link
  * This links together a FE and BE DAI at runtime and stores the link
@@ -133,7 +150,8 @@ struct snd_pcm_substream *
snd_soc_dpcm_get_substream(struct snd_soc_pcm_runtime *be, int stream);
 
 /* update audio routing between PCMs and any DAI links */
-int snd_soc_dpcm_runtime_update(struct snd_soc_card *card);
+int snd_soc_dpcm_runtime_update(struct snd_soc_card *card,
+   enum snd_soc_dpcm_update_mode mode);
 
 #ifdef CONFIG_DEBUG_FS
 void soc_dpcm_debugfs_add(struct snd_soc_pcm_runtime *rtd);
@@ -143,11 +161,11 @@ static inline void soc_dpcm_debugfs_add(struct 
snd_soc_pcm_runtime *rtd)
 }
 #endif
 
-int dpcm_path_get(struct snd_soc_pcm_runtime *fe,
-   int stream, struct snd_soc_dapm_widget_list **list_);
+int dpcm_path_get(struct snd_soc_pcm_runtime *fe, int stream,
+   struct snd_soc_dapm_widget_list **list_);
 void dpcm_path_put(struct snd_soc_dapm_widget_list **list);
-int dpcm_process_paths(struct snd_soc_pcm_runtime *fe,
-   int stream, struct snd_soc_dapm_widget_list **list, int new);
+int dpcm_process_paths(struct snd_soc_pcm_runtime *fe, int stream,
+   struct snd_soc_dapm_widget_list **list, bool new, bool force_prune);
 int dpcm_be_dai_startup(struct snd_soc_pcm_runtime *fe, int stream);
 int dpcm_be_dai_shutdown(struct snd_soc_pcm_runtime *fe, int stream);
 void dpcm_be_disconnect(struct snd_soc_pcm_runtime *fe, int stream);
diff --git a/sound/soc/soc-compress.c b/sound/soc/soc-compress.c
index 62ece72..c9539b8 100644
--- a/sound/soc/soc-compress.c
+++ b/sound/soc/soc-compress.c
@@ -155,7 +155,7 @@ static int soc_compr_open_fe(struct snd_compr_stream 
*cstream)
dev_dbg(fe->dev, "Compress ASoC: %s no valid %s route\n",
fe->dai_link->name, stream ? "capture" : "playback");
/* calculate valid and active FE <-> BE dpcms */
-   dpcm_process_paths(fe, stream, , 1);
+   dpcm_process_paths(fe, stream, , true, false);
fe->dpcm[stream].runtime = fe_substream->runtime;
 
fe->dpcm[stream].runtime_update = SND_SOC_DPCM_UPDATE_FE;
diff --git a/sound/soc/soc-dapm.c b/sound/soc/soc-dapm.c
index a4de3e4..e27d93d 100644
--- a/sound/soc/soc-dapm.c
+++ b/sound/soc/soc-dapm.c
@@ -2311,7 +2311,7 @@ int snd_soc_dapm_mux_update_power(struct 
snd_soc_dapm_context *dapm,
card->update = NULL;
mutex_unlock(>dapm_mutex);
if (ret > 0)
-   snd_soc_dpcm_runtime_update(card);
+   snd_soc_dpcm_runtime_update(card, SND_SOC_DPCM_UPDATE_FULL);
return ret;
 }
 EXPORT_SYMBOL_GPL(snd_soc_dapm_mux_update_power);
@@ -2376,7 +2376,7 @@ int snd_soc_dapm_mixer_update_power(struct 
snd_soc_dapm_context *dapm,

[RFC 08/12] ASoC: SOF: add a vhost driver: sound part

[Guennadi Liakhovetski]

The SOF VirtIO driver uses a vhost RPMsg driver as a counterpart to
communicate with the DSP. This patch adds a sound interface of the
vhost driver.

Signed-off-by: Guennadi Liakhovetski 
---
 include/sound/soc-topology.h |3 +
 include/sound/sof/rpmsg.h|   72 +++
 include/uapi/linux/vhost.h   |5 +
 include/uapi/linux/vhost_types.h |7 +
 sound/soc/soc-pcm.c  |   31 +-
 sound/soc/sof/Makefile   |6 +-
 sound/soc/sof/core.c |6 +
 sound/soc/sof/ipc.c  |5 +
 sound/soc/sof/pcm.c  |4 +-
 sound/soc/sof/pm.c   |4 +
 sound/soc/sof/sof-audio.c|9 +
 sound/soc/sof/sof-audio.h|   16 +
 sound/soc/sof/sof-priv.h |   16 +
 sound/soc/sof/topology.c |   54 +-
 sound/soc/sof/vhost-vbe.c| 1102 ++
 15 files changed, 1324 insertions(+), 16 deletions(-)
 create mode 100644 sound/soc/sof/vhost-vbe.c

diff --git a/include/sound/soc-topology.h b/include/sound/soc-topology.h
index 5223896..ea0c2a64 100644
--- a/include/sound/soc-topology.h
+++ b/include/sound/soc-topology.h
@@ -34,6 +34,9 @@
 /* object scan be loaded and unloaded in groups with identfying indexes */
 #define SND_SOC_TPLG_INDEX_ALL 0   /* ID that matches all FW objects */
 
+#define SOC_VIRT_DAI_PLAYBACK "VM FE Playback"
+#define SOC_VIRT_DAI_CAPTURE "VM FE Capture"
+
 /* dynamic object type */
 enum snd_soc_dobj_type {
SND_SOC_DOBJ_NONE   = 0,/* object is not dynamic */
diff --git a/include/sound/sof/rpmsg.h b/include/sound/sof/rpmsg.h
index 73dc34c..ce522c6 100644
--- a/include/sound/sof/rpmsg.h
+++ b/include/sound/sof/rpmsg.h
@@ -11,6 +11,7 @@
 #ifndef _SOF_RPMSG_H
 #define _SOF_RPMSG_H
 
+#include 
 #include 
 
 #include 
@@ -117,4 +118,75 @@ struct sof_rpmsg_ipc_req {
u8 ipc_msg[SOF_IPC_MSG_MAX_SIZE];
 } __packed;
 
+struct snd_sof_dev;
+struct sof_ipc_stream_posn;
+
+#if IS_ENABLED(CONFIG_VHOST_SOF)
+struct firmware;
+
+struct vhost_dsp;
+struct sof_vhost_ops {
+   int (*update_posn)(struct vhost_dsp *dsp,
+  struct sof_ipc_stream_posn *posn);
+};
+
+struct sof_vhost_client {
+   const struct firmware *fw;
+   struct snd_sof_dev *sdev;
+   /* List of guest endpoints, connecting to the host mixer or demux */
+   struct list_head pipe_conn;
+   /* List of vhost instances on a DSP */
+   struct list_head list;
+
+   /* Component ID range index in the bitmap */
+   unsigned int id;
+
+   /* the comp_ids for this vm audio */
+   int comp_id_begin;
+   int comp_id_end;
+
+   unsigned int reset_count;
+
+   struct vhost_dsp *vhost;
+};
+
+/* The below functions are only referenced when VHOST_SOF is selected */
+struct device;
+void sof_vhost_client_release(struct sof_vhost_client *client);
+struct sof_vhost_client *sof_vhost_client_add(struct snd_sof_dev *sdev,
+ struct vhost_dsp *dsp);
+struct device *sof_vhost_dev_init(const struct sof_vhost_ops *ops);
+struct vhost_adsp_topology;
+int sof_vhost_set_tplg(struct sof_vhost_client *client,
+  const struct vhost_adsp_topology *tplg);
+/* Copy audio data between DMA and VirtQueue */
+void *sof_vhost_stream_data(struct sof_vhost_client *client,
+   const struct sof_rpmsg_data_req *req,
+   struct sof_rpmsg_data_resp *resp);
+/* Forward an IPC message from a guest to the DSP */
+int sof_vhost_ipc_fwd(struct sof_vhost_client *client,
+ void *ipc_buf, void *reply_buf,
+ size_t count, size_t reply_sz);
+
+/* The below functions are always referenced, they need dummy counterparts */
+int sof_vhost_update_guest_posn(struct snd_sof_dev *sdev,
+   struct sof_ipc_stream_posn *posn);
+void sof_vhost_suspend(struct snd_sof_dev *sdev);
+void sof_vhost_dev_set(struct snd_sof_dev *sdev);
+#else
+static inline int sof_vhost_update_guest_posn(struct snd_sof_dev *sdev,
+ struct sof_ipc_stream_posn *posn)
+{
+   return 0;
+}
+
+static inline void sof_vhost_suspend(struct snd_sof_dev *sdev)
+{
+}
+
+static inline void sof_vhost_dev_set(struct snd_sof_dev *sdev)
+{
+}
+#endif
+
 #endif
diff --git a/include/uapi/linux/vhost.h b/include/uapi/linux/vhost.h
index b54af9d..aa258e2 100644
--- a/include/uapi/linux/vhost.h
+++ b/include/uapi/linux/vhost.h
@@ -142,4 +142,9 @@
 /* Get the max ring size. */
 #define VHOST_VDPA_GET_VRING_NUM   _IOR(VHOST_VIRTIO, 0x76, __u16)
 
+/* VHOST_ADSP specific defines */
+
+#define VHOST_ADSP_SET_GUEST_TPLG  _IOW(VHOST_VIRTIO, 0x80,\
+   struct vhost_adsp_topology)
+
 #endif
diff --git a/include/uapi/linux/vhost_types.h b/include/uapi/linux/vhost_types.h
index 669457c..6364bc8 100644
--- a/include/uapi/linux

[RFC 03/12] ASoC: SOF: support IPC with immediate response

[Guennadi Liakhovetski]

Usually when an IPC message is sent, we have to wait for a reply from
the DSP or from the host in the VirtIO case. However, sometimes in
the VirtIO case a response is available immediately. Skip sleeping in
such cases.

Signed-off-by: Guennadi Liakhovetski 
---
 sound/soc/sof/ipc.c | 11 +++
 sound/soc/sof/ops.h | 10 +-
 2 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/sound/soc/sof/ipc.c b/sound/soc/sof/ipc.c
index f7a0353..b3e1587 100644
--- a/sound/soc/sof/ipc.c
+++ b/sound/soc/sof/ipc.c
@@ -262,6 +262,12 @@ static int sof_ipc_tx_message_unlocked(struct snd_sof_ipc 
*ipc, u32 header,
 
sdev->msg = msg;
 
+   /*
+* If snd_sof_dsp_send_msg() returns a positive number it means, that a
+* response is already available, no need to sleep waiting for it. In
+* such a case msg->ipc_complete will stay true and tx_wait_done() will
+* return immediately.
+*/
ret = snd_sof_dsp_send_msg(sdev, msg);
/* Next reply that we receive will be related to this message */
if (!ret)
@@ -279,10 +285,7 @@ static int sof_ipc_tx_message_unlocked(struct snd_sof_ipc 
*ipc, u32 header,
ipc_log_header(sdev->dev, "ipc tx", msg->header);
 
/* now wait for completion */
-   if (!ret)
-   ret = tx_wait_done(ipc, msg, reply_data);
-
-   return ret;
+   return tx_wait_done(ipc, msg, reply_data);
 }
 
 /* send IPC message from host to DSP */
diff --git a/sound/soc/sof/ops.h b/sound/soc/sof/ops.h
index b21632f..bf91467 100644
--- a/sound/soc/sof/ops.h
+++ b/sound/soc/sof/ops.h
@@ -274,7 +274,15 @@ static inline void snd_sof_dsp_block_write(struct 
snd_sof_dev *sdev, u32 bar,
sof_ops(sdev)->block_write(sdev, bar, offset, src, bytes);
 }
 
-/* ipc */
+/**
+ * snd_sof_dsp_send_msg - call sdev ops to send a message
+ * @sdev:  sdev context
+ * @msg:   message to send
+ *
+ * Returns < 0 - an error code
+ *   0 - the message has been sent, wait for a reply
+ * > 0 - the message has been sent, a reply is already available
+ */
 static inline int snd_sof_dsp_send_msg(struct snd_sof_dev *sdev,
   struct snd_sof_ipc_msg *msg)
 {
-- 
1.9.3

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[RFC 09/12] ASoC: SOF: VirtIO: free guest pipelines upon termination

[Guennadi Liakhovetski]

Currently the SOF driver switches off the DSP every time runtime or
system-wide suspend is entered. After the DSP is turned off, next
time it's turned on, the firmware and topology have to be re-sent to
it.

When a guest SOF instance restarts it sends its topology to the host,
which then forwards it to the DSP. This is correct if the DSP was
suspended during that time and lost the guest's topology. However, if
the DSP stayed active during that entire time, sending duplicate
components to it produces errors. To prevent this from happening this
patch adds freeing of components during guest shut down.

Signed-off-by: Guennadi Liakhovetski 
---
 include/sound/sof/rpmsg.h |   4 ++
 sound/soc/sof/vhost-vbe.c | 158 +-
 2 files changed, 161 insertions(+), 1 deletion(-)

diff --git a/include/sound/sof/rpmsg.h b/include/sound/sof/rpmsg.h
index ce522c6..7f907e6 100644
--- a/include/sound/sof/rpmsg.h
+++ b/include/sound/sof/rpmsg.h
@@ -137,6 +137,9 @@ struct sof_vhost_client {
struct list_head pipe_conn;
/* List of vhost instances on a DSP */
struct list_head list;
+   /* List of widgets to free for tear-down */
+   struct list_head comp_list;
+   struct list_head pipe_list;
 
/* Component ID range index in the bitmap */
unsigned int id;
@@ -167,6 +170,7 @@ void *sof_vhost_stream_data(struct sof_vhost_client *client,
 int sof_vhost_ipc_fwd(struct sof_vhost_client *client,
  void *ipc_buf, void *reply_buf,
  size_t count, size_t reply_sz);
+void sof_vhost_topology_purge(struct sof_vhost_client *client);
 
 /* The below functions are always referenced, they need dummy counterparts */
 int sof_vhost_update_guest_posn(struct snd_sof_dev *sdev,
diff --git a/sound/soc/sof/vhost-vbe.c b/sound/soc/sof/vhost-vbe.c
index 8056e25..3887bba 100644
--- a/sound/soc/sof/vhost-vbe.c
+++ b/sound/soc/sof/vhost-vbe.c
@@ -43,6 +43,18 @@ struct dsp_pipeline_connect {
struct list_head list;
 };
 
+struct sof_vhost_comp_list {
+   struct list_head list;
+   uint32_t comp_id;
+   enum sof_comp_type comp_type;
+};
+
+struct sof_vhost_pipe_list {
+   struct list_head list;
+   uint32_t comp_id;
+   uint32_t pipe_id;
+};
+
 static const char dsp_pcm_name[] = "VHost PCM";
 
 /*
@@ -446,6 +458,75 @@ static int sof_vhost_ipc_comp(struct sof_vhost_client 
*client,
cdata->comp_id >= client->comp_id_end ? -EINVAL : 0;
 }
 
+void sof_vhost_topology_purge(struct sof_vhost_client *client)
+{
+   struct snd_sof_dev *sdev = client->sdev;
+   struct sof_ipc_free fcomp = {
+   .hdr = {
+   .size = sizeof(fcomp),
+   },
+   };
+   struct sof_ipc_reply reply;
+   struct sof_vhost_comp_list *citem, *ctmp;
+   struct sof_vhost_pipe_list *pitem, *ptmp;
+   int ret;
+
+   pm_runtime_get_sync(sdev->dev);
+
+   /* First free all pipelines */
+   list_for_each_entry_safe(pitem, ptmp, >pipe_list, list) {
+   fcomp.id = pitem->comp_id;
+   fcomp.hdr.cmd = SOF_IPC_GLB_TPLG_MSG |
+   SOF_IPC_TPLG_PIPE_FREE;
+
+   dev_dbg(sdev->dev, "tplg: unload component ID: %d pipe %u\n",
+   fcomp.id, pitem->pipe_id);
+
+   /* send IPC to the DSP */
+   ret = sof_ipc_tx_message(sdev->ipc,
+fcomp.hdr.cmd, , sizeof(fcomp),
+, sizeof(reply));
+   if (ret < 0)
+   dev_err(sdev->dev, "error: %d unloading component %d\n",
+   ret, fcomp.id);
+
+   list_del(>list);
+   kfree(pitem);
+   }
+
+   /* Then free all individual components */
+   list_for_each_entry_safe(citem, ctmp, >comp_list, list) {
+   fcomp.id = citem->comp_id;
+   switch (citem->comp_type) {
+   case SOF_COMP_BUFFER:
+   fcomp.hdr.cmd = SOF_IPC_GLB_TPLG_MSG |
+   SOF_IPC_TPLG_BUFFER_FREE;
+   break;
+   default:
+   fcomp.hdr.cmd = SOF_IPC_GLB_TPLG_MSG |
+   SOF_IPC_TPLG_COMP_FREE;
+   }
+
+   dev_dbg(sdev->dev, "tplg: unload component ID: %d type %u\n",
+   fcomp.id, citem->comp_type);
+
+   /* send IPC to the DSP */
+   ret = sof_ipc_tx_message(sdev->ipc,
+fcomp.hdr.cmd, , sizeof(fcomp),
+, sizeof(reply));
+   if (ret < 0)
+   dev_err(sdev->dev, "error: %d unloading component %d\n",
+   ret, fcomp.id);
+
+

[RFC 10/12] vhost: add an SOF Audio DSP driver

[Guennadi Liakhovetski]

The SOF ADSP vhost driver consists of two parts: a sound and a vhost
part. This patch implements the vhost part of the driver. It handles
QEMU communication with the vhost misc device and virtual queues to
any VirtIO RPMsg guests.

Signed-off-by: Guennadi Liakhovetski 
---
 drivers/vhost/Kconfig  |  10 +
 drivers/vhost/Makefile |   3 +
 drivers/vhost/adsp.c   | 618 +
 3 files changed, 631 insertions(+)
 create mode 100644 drivers/vhost/adsp.c

diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
index 8b91f3e..ef3e459 100644
--- a/drivers/vhost/Kconfig
+++ b/drivers/vhost/Kconfig
@@ -54,6 +54,16 @@ config VHOST_SCSI
Say M here to enable the vhost_scsi TCM fabric module
for use with virtio-scsi guests
 
+config VHOST_SOF
+   tristate "Vhost SOF driver"
+   depends on SND_SOC_SOF
+   select VHOST
+   select VHOST_RPMSG
+   default n
+   help
+ SOF vhost VirtIO driver. It exports the same IPC interface, as the
+ one, used for Audio DSP communication, to Linux VirtIO guests.
+
 config VHOST_VSOCK
tristate "vhost virtio-vsock driver"
depends on VSOCKETS && EVENTFD
diff --git a/drivers/vhost/Makefile b/drivers/vhost/Makefile
index 9cf459d..86cbd12 100644
--- a/drivers/vhost/Makefile
+++ b/drivers/vhost/Makefile
@@ -8,6 +8,9 @@ vhost_rpmsg-y := rpmsg.o
 obj-$(CONFIG_VHOST_SCSI) += vhost_scsi.o
 vhost_scsi-y := scsi.o
 
+obj-$(CONFIG_VHOST_SOF) += vhost_sof.o
+vhost_sof-y := adsp.o
+
 obj-$(CONFIG_VHOST_VSOCK) += vhost_vsock.o
 vhost_vsock-y := vsock.o
 
diff --git a/drivers/vhost/adsp.c b/drivers/vhost/adsp.c
new file mode 100644
index ..c0a496f
--- /dev/null
+++ b/drivers/vhost/adsp.c
@@ -0,0 +1,618 @@
+// SPDX-License-Identifier: GPL-2.0 OR BSD-3-Clause
+/*
+ * Copyright(c) 2019-2020 Intel Corporation. All rights reserved.
+ *
+ * Author: Guennadi Liakhovetski 
+ *
+ * vhost-SOF VirtIO interface
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "vhost.h"
+#include "vhost_rpmsg.h"
+
+#define VHOST_DSP_FEATURES (VHOST_FEATURES | (1ULL << VIRTIO_RPMSG_F_NS))
+
+struct snd_sof_dev;
+struct sof_vhost_client;
+
+struct vhost_dsp {
+   struct vhost_rpmsg vrdev;
+
+   struct sof_vhost_client *snd;
+
+   bool active;
+
+   /* RPMsg address of the position update endpoint */
+   u32 posn_addr;
+   /* position update buffer and work */
+   struct vhost_work posn_work;
+   struct sof_ipc_stream_posn posn;
+
+   /* IPC request buffer */
+   struct sof_rpmsg_ipc_req ipc_buf;
+   /* IPC response buffer */
+   u8 reply_buf[SOF_IPC_MSG_MAX_SIZE];
+   /*
+* data response header, captured audio data is copied directly from the
+* DMA buffer
+*/
+   struct sof_rpmsg_data_resp data_resp;
+};
+
+/* A guest is booting */
+static int vhost_dsp_activate(struct vhost_dsp *dsp)
+{
+   unsigned int i;
+   int ret = 0;
+
+   mutex_lock(>vrdev.dev.mutex);
+
+   /* Wait until all the VirtQueues have been initialised */
+   if (!dsp->active) {
+   struct vhost_virtqueue *vq;
+
+   for (i = 0, vq = dsp->vrdev.vq;
+i < ARRAY_SIZE(dsp->vrdev.vq);
+i++, vq++) {
+   /* .private_data is required != NULL */
+   vhost_vq_set_backend(vq, dsp);
+   /* needed for re-initialisation upon guest reboot */
+   ret = vhost_vq_init_access(vq);
+   if (ret)
+   vq_err(vq,
+  "%s(): error %d initialising vq #%d\n",
+  __func__, ret, i);
+   }
+
+   /* Send an RPMsg namespace announcement */
+   if (!ret && !vhost_rpmsg_ns_announce(>vrdev, "sof_rpmsg",
+SOF_RPMSG_ADDR_IPC))
+   dsp->active = true;
+   }
+
+   mutex_unlock(>vrdev.dev.mutex);
+
+   return ret;
+}
+
+/* A guest is powered off or reset */
+static void vhost_dsp_deactivate(struct vhost_dsp *dsp)
+{
+   unsigned int i;
+
+   mutex_lock(>vrdev.dev.mutex);
+
+   if (dsp->active) {
+   struct vhost_virtqueue *vq;
+
+   dsp->active = false;
+
+   /* If a VM reboots sof_vhost_client_release() isn't called */
+   sof_vhost_topology_purge(dsp->snd);
+
+   /* signal, that we're inactive */
+   for (i = 0, vq = dsp->vrdev.vq;
+i < ARRAY_SIZE(dsp->vrdev.vq);
+i++, vq++) {
+   mutex_lock(>mutex);
+ 

[RFC 05/12] ASoC: SOF: add two helper lookup functions

[Guennadi Liakhovetski]

Add two helper lookup functions for finding a widget by its component
ID and a DAI by a pipeline ID.

Signed-off-by: Guennadi Liakhovetski 
---
 sound/soc/sof/sof-audio.c | 24 
 sound/soc/sof/sof-audio.h |  5 +
 sound/soc/sof/topology.c  |  1 +
 3 files changed, 30 insertions(+)

diff --git a/sound/soc/sof/sof-audio.c b/sound/soc/sof/sof-audio.c
index 1c7698f..92fa6a8 100644
--- a/sound/soc/sof/sof-audio.c
+++ b/sound/soc/sof/sof-audio.c
@@ -395,6 +395,30 @@ struct snd_sof_dai *snd_sof_find_dai(struct 
snd_soc_component *scomp,
return NULL;
 }
 
+struct snd_sof_widget *snd_sof_find_swidget_id(struct snd_sof_dev *sdev,
+  unsigned int comp_id)
+{
+   struct snd_sof_widget *swidget;
+
+   list_for_each_entry(swidget, >widget_list, list)
+   if (swidget->comp_id == comp_id)
+   return swidget;
+
+   return NULL;
+}
+
+struct snd_sof_dai *snd_sof_find_dai_pipe(struct snd_sof_dev *sdev,
+ unsigned int pipeline_id)
+{
+   struct snd_sof_dai *dai;
+
+   list_for_each_entry(dai, >dai_list, list)
+   if (dai->pipeline_id == pipeline_id)
+   return dai;
+
+   return NULL;
+}
+
 /*
  * SOF Driver enumeration.
  */
diff --git a/sound/soc/sof/sof-audio.h b/sound/soc/sof/sof-audio.h
index 9629994..8054e48 100644
--- a/sound/soc/sof/sof-audio.h
+++ b/sound/soc/sof/sof-audio.h
@@ -106,6 +106,7 @@ struct snd_sof_dai {
struct snd_soc_component *scomp;
const char *name;
const char *cpu_dai_name;
+   unsigned int pipeline_id;
 
struct sof_ipc_comp_dai comp_dai;
struct sof_ipc_dai_config *dai_config;
@@ -190,6 +191,10 @@ struct snd_sof_pcm *snd_sof_find_spcm_comp(struct 
snd_soc_component *scomp,
   int *direction);
 struct snd_sof_pcm *snd_sof_find_spcm_pcm_id(struct snd_soc_component *scomp,
 unsigned int pcm_id);
+struct snd_sof_widget *snd_sof_find_swidget_id(struct snd_sof_dev *sdev,
+  unsigned int comp_id);
+struct snd_sof_dai *snd_sof_find_dai_pipe(struct snd_sof_dev *sdev,
+ unsigned int pipeline_id);
 void snd_sof_pcm_period_elapsed(struct snd_pcm_substream *substream);
 void snd_sof_pcm_period_elapsed_work(struct work_struct *work);
 
diff --git a/sound/soc/sof/topology.c b/sound/soc/sof/topology.c
index 6a9703e..5a65dcf 100644
--- a/sound/soc/sof/topology.c
+++ b/sound/soc/sof/topology.c
@@ -1406,6 +1406,7 @@ static int sof_widget_load_dai(struct snd_soc_component 
*scomp, int index,
 
if (ret == 0 && dai) {
dai->scomp = scomp;
+   dai->pipeline_id = swidget->pipeline_id;
memcpy(>comp_dai, _dai, sizeof(comp_dai));
}
 
-- 
1.9.3

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[RFC 07/12] ASoC: SOF: use a macro instead of a hard-coded value

[Guennadi Liakhovetski]

target_stats in sof_suspend should contain one of SOF_DSP_PM_* power
state macros, not a hard-coded value 0.

Signed-off-by: Guennadi Liakhovetski 
---
 sound/soc/sof/pm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/sof/pm.c b/sound/soc/sof/pm.c
index 5e804a7..c7aa2cf 100644
--- a/sound/soc/sof/pm.c
+++ b/sound/soc/sof/pm.c
@@ -174,7 +174,7 @@ static int sof_resume(struct device *dev, bool 
runtime_resume)
 static int sof_suspend(struct device *dev, bool runtime_suspend)
 {
struct snd_sof_dev *sdev = dev_get_drvdata(dev);
-   u32 target_state = 0;
+   u32 target_state = SOF_DSP_PM_D0;
int ret;
 
/* do nothing if dsp suspend callback is not set */
-- 
1.9.3

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[RFC 02/12] ASoC: SOF: extract firmware-related operation into a function

[Guennadi Liakhovetski]

In the VirtIO guest case the SOF will not be dealing with the
firmware directly. Extract related functionality into a function to
make the separation easier.

Signed-off-by: Guennadi Liakhovetski 
---
 sound/soc/sof/core.c | 85 ++--
 1 file changed, 49 insertions(+), 36 deletions(-)

diff --git a/sound/soc/sof/core.c b/sound/soc/sof/core.c
index 339c493..17f264f 100644
--- a/sound/soc/sof/core.c
+++ b/sound/soc/sof/core.c
@@ -135,6 +135,53 @@ void snd_sof_get_status(struct snd_sof_dev *sdev, u32 
panic_code,
  * (System Suspend/Runtime Suspend)
  */
 
+static int sof_load_and_run_firmware(struct snd_sof_dev *sdev)
+{
+   /* load the firmware */
+   int ret = snd_sof_load_firmware(sdev);
+   if (ret < 0) {
+   dev_err(sdev->dev, "error: failed to load DSP firmware %d\n",
+   ret);
+   return ret;
+   }
+
+   sdev->fw_state = SOF_FW_BOOT_IN_PROGRESS;
+
+   /*
+* Boot the firmware. The FW boot status will be modified
+* in snd_sof_run_firmware() depending on the outcome.
+*/
+   ret = snd_sof_run_firmware(sdev);
+   if (ret < 0) {
+   dev_err(sdev->dev, "error: failed to boot DSP firmware %d\n",
+   ret);
+   goto fw_run_err;
+   }
+
+   if (IS_ENABLED(CONFIG_SND_SOC_SOF_DEBUG_ENABLE_FIRMWARE_TRACE) ||
+   (sof_core_debug & SOF_DBG_ENABLE_TRACE)) {
+   sdev->dtrace_is_supported = true;
+
+   /* init DMA trace */
+   ret = snd_sof_init_trace(sdev);
+   if (ret < 0) {
+   /* non fatal */
+   dev_warn(sdev->dev,
+"warning: failed to initialize trace %d\n",
+ret);
+   }
+   } else {
+   dev_dbg(sdev->dev, "SOF firmware trace disabled\n");
+   }
+
+   return 0;
+
+fw_run_err:
+   snd_sof_fw_unload(sdev);
+
+   return ret;
+}
+
 static int sof_probe_continue(struct snd_sof_dev *sdev)
 {
struct snd_sof_pdata *plat_data = sdev->pdata;
@@ -181,42 +228,9 @@ static int sof_probe_continue(struct snd_sof_dev *sdev)
goto ipc_err;
}
 
-   /* load the firmware */
-   ret = snd_sof_load_firmware(sdev);
-   if (ret < 0) {
-   dev_err(sdev->dev, "error: failed to load DSP firmware %d\n",
-   ret);
+   ret = sof_load_and_run_firmware(sdev);
+   if (ret < 0)
goto fw_load_err;
-   }
-
-   sdev->fw_state = SOF_FW_BOOT_IN_PROGRESS;
-
-   /*
-* Boot the firmware. The FW boot status will be modified
-* in snd_sof_run_firmware() depending on the outcome.
-*/
-   ret = snd_sof_run_firmware(sdev);
-   if (ret < 0) {
-   dev_err(sdev->dev, "error: failed to boot DSP firmware %d\n",
-   ret);
-   goto fw_run_err;
-   }
-
-   if (IS_ENABLED(CONFIG_SND_SOC_SOF_DEBUG_ENABLE_FIRMWARE_TRACE) ||
-   (sof_core_debug & SOF_DBG_ENABLE_TRACE)) {
-   sdev->dtrace_is_supported = true;
-
-   /* init DMA trace */
-   ret = snd_sof_init_trace(sdev);
-   if (ret < 0) {
-   /* non fatal */
-   dev_warn(sdev->dev,
-"warning: failed to initialize trace %d\n",
-ret);
-   }
-   } else {
-   dev_dbg(sdev->dev, "SOF firmware trace disabled\n");
-   }
 
/* hereafter all FW boot flows are for PM reasons */
sdev->first_boot = false;
@@ -250,7 +264,6 @@ static int sof_probe_continue(struct snd_sof_dev *sdev)
 
 fw_trace_err:
snd_sof_free_trace(sdev);
-fw_run_err:
snd_sof_fw_unload(sdev);
 fw_load_err:
snd_sof_ipc_free(sdev);
-- 
1.9.3

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[RFC 00/12] Audio DSP VirtIO and vhost drivers

[Guennadi Liakhovetski]

This patch set is a follow up to "Add a vhost RPMsg API" [1], it is
marked as an RFC because firstly it depends on the RPMsg API series
and secondly it is currently being reviewed on ALSA and SOF mailing
lists, but any early comments from virtualisation developers would be
highly appreciated too!

Thanks
Guennadi

[1] 
https://mailman.alsa-project.org/pipermail/sound-open-firmware/2020-May/003879.html

Guennadi Liakhovetski (12):
  ASoC: add function parameters to enable forced path pruning
  ASoC: SOF: extract firmware-related operation into a function
  ASoC: SOF: support IPC with immediate response
  ASoC: SOF: add a power status IPC
  ASoC: SOF: add two helper lookup functions
  ASoC: SOF: add an RPMsg VirtIO DSP driver
  ASoC: SOF: use a macro instead of a hard-coded value
  ASoC: SOF: add a vhost driver: sound part
  ASoC: SOF: VirtIO: free guest pipelines upon termination
  vhost: add an SOF Audio DSP driver
  rpmsg: increase buffer size and reduce buffer number
  rpmsg: add a device ID to also bind to the ADSP device

 drivers/rpmsg/virtio_rpmsg_bus.c |1 +
 drivers/vhost/Kconfig|   10 +
 drivers/vhost/Makefile   |3 +
 drivers/vhost/adsp.c |  618 +++
 include/linux/virtio_rpmsg.h |4 +-
 include/sound/soc-dpcm.h |   28 +-
 include/sound/soc-topology.h |3 +
 include/sound/sof.h  |4 +
 include/sound/sof/header.h   |3 +
 include/sound/sof/rpmsg.h|  196 ++
 include/sound/sof/topology.h |9 +-
 include/uapi/linux/vhost.h   |5 +
 include/uapi/linux/vhost_types.h |7 +
 include/uapi/linux/virtio_ids.h  |1 +
 sound/soc/soc-compress.c |2 +-
 sound/soc/soc-dapm.c |8 +-
 sound/soc/soc-pcm.c  |   98 ++-
 sound/soc/sof/Kconfig|7 +
 sound/soc/sof/Makefile   |2 +
 sound/soc/sof/core.c |  114 ++--
 sound/soc/sof/ipc.c  |   34 +-
 sound/soc/sof/loader.c   |4 +
 sound/soc/sof/ops.h  |   10 +-
 sound/soc/sof/pcm.c  |   13 +-
 sound/soc/sof/pm.c   |6 +-
 sound/soc/sof/rpmsg-vfe.c|  881 ++
 sound/soc/sof/sof-audio.c|   33 +
 sound/soc/sof/sof-audio.h|   21 +
 sound/soc/sof/sof-priv.h |   48 ++
 sound/soc/sof/topology.c |   71 ++-
 sound/soc/sof/vhost-vbe.c| 1258 ++
 31 files changed, 3391 insertions(+), 111 deletions(-)
 create mode 100644 drivers/vhost/adsp.c
 create mode 100644 include/sound/sof/rpmsg.h
 create mode 100644 sound/soc/sof/rpmsg-vfe.c
 create mode 100644 sound/soc/sof/vhost-vbe.c

-- 
1.9.3

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v3 0/5] Add a vhost RPMsg API

[Guennadi Liakhovetski]

Hi Jason,

On Fri, May 29, 2020 at 02:01:53PM +0800, Jason Wang wrote:
> 
> On 2020/5/28 上午2:05, Guennadi Liakhovetski wrote:
> > 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. 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, ready
> > for review and submission, available at
> > https://github.com/thesofproject/linux/pull/1501/commits
> > A further patch for the ADSP vhost RPMsg driver will be sent
> > separately for review only since it cannot be merged without audio
> > patches being upstreamed first.
> 
> 
> Hi:
> 
> It would be hard to evaluate this series without a real user. So if
> possible, I suggest to post the actual user for vhost rpmsg API.

Sure, the whole series is available at 
https://github.com/thesofproject/linux/pull/1501/commits or would you 
prefer the missing patches posted to the lists too?

Thanks
Guennadi
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH v3 4/5] rpmsg: update documentation

[Guennadi Liakhovetski]

rpmsg_create_ept() takes struct rpmsg_channel_info chinfo as its last
argument, not a u32 value. The first two arguments are also updated.

Signed-off-by: Guennadi Liakhovetski 
---
 Documentation/rpmsg.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/rpmsg.txt b/Documentation/rpmsg.txt
index 24b7a9e..1ce353c 100644
--- a/Documentation/rpmsg.txt
+++ b/Documentation/rpmsg.txt
@@ -192,9 +192,9 @@ Returns 0 on success and an appropriate error value on 
failure.
 
 ::
 
-  struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_channel *rpdev,
-   void (*cb)(struct rpmsg_channel *, void *, int, void *, u32),
-   void *priv, u32 addr);
+  struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_device *rpdev,
+ rpmsg_rx_cb_t cb, void *priv,
+ struct rpmsg_channel_info chinfo);
 
 every rpmsg address in the system is bound to an rx callback (so when
 inbound messages arrive, they are dispatched by the rpmsg bus using the
-- 
1.9.3

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH v3 1/5] vhost: convert VHOST_VSOCK_SET_RUNNING to a generic ioctl

[Guennadi Liakhovetski]

VHOST_VSOCK_SET_RUNNING is used by the vhost vsock driver to perform
crucial VirtQueue initialisation, like assigning .private fields and
calling vhost_vq_init_access(), and clean up. However, this ioctl is
actually extremely useful for any vhost driver, that doesn't have a
side channel to inform it of a status change, e.g. upon a guest
reboot. This patch makes that ioctl generic, while preserving its
numeric value and also keeping the original alias.

Signed-off-by: Guennadi Liakhovetski 
---
 include/uapi/linux/vhost.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/vhost.h b/include/uapi/linux/vhost.h
index 9fe72e4..b54af9d 100644
--- a/include/uapi/linux/vhost.h
+++ b/include/uapi/linux/vhost.h
@@ -93,6 +93,8 @@
 #define VHOST_SET_BACKEND_FEATURES _IOW(VHOST_VIRTIO, 0x25, __u64)
 #define VHOST_GET_BACKEND_FEATURES _IOR(VHOST_VIRTIO, 0x26, __u64)
 
+#define VHOST_SET_RUNNING _IOW(VHOST_VIRTIO, 0x61, int)
+
 /* VHOST_NET specific defines */
 
 /* Attach virtio net ring to a raw socket, or tap device.
@@ -114,7 +116,7 @@
 /* VHOST_VSOCK specific defines */
 
 #define VHOST_VSOCK_SET_GUEST_CID  _IOW(VHOST_VIRTIO, 0x60, __u64)
-#define VHOST_VSOCK_SET_RUNNING_IOW(VHOST_VIRTIO, 0x61, int)
+#define VHOST_VSOCK_SET_RUNNINGVHOST_SET_RUNNING
 
 /* VHOST_VDPA specific defines */
 
-- 
1.9.3

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH v3 0/5] Add a vhost RPMsg API

[Guennadi Liakhovetski]

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. 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, ready
for review and submission, available at
https://github.com/thesofproject/linux/pull/1501/commits
A further patch for the ADSP vhost RPMsg driver will be sent
separately for review only since it cannot be merged without audio
patches being upstreamed first.

Thanks
Guennadi

Guennadi Liakhovetski (5):
  vhost: convert VHOST_VSOCK_SET_RUNNING to a generic ioctl
  vhost: (cosmetic) remove a superfluous variable initialisation
  rpmsg: move common structures and defines to headers
  rpmsg: update documentation
  vhost: add an RPMsg API

 Documentation/rpmsg.txt  |   6 +-
 drivers/rpmsg/virtio_rpmsg_bus.c |  78 +---
 drivers/vhost/Kconfig|   7 +
 drivers/vhost/Makefile   |   3 +
 drivers/vhost/rpmsg.c| 382 +++
 drivers/vhost/vhost.c|   2 +-
 drivers/vhost/vhost_rpmsg.h  |  74 
 include/linux/virtio_rpmsg.h |  81 +
 include/uapi/linux/rpmsg.h   |   3 +
 include/uapi/linux/vhost.h   |   4 +-
 10 files changed, 559 insertions(+), 81 deletions(-)
 create mode 100644 drivers/vhost/rpmsg.c
 create mode 100644 drivers/vhost/vhost_rpmsg.h
 create mode 100644 include/linux/virtio_rpmsg.h

-- 
1.9.3

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH v3 5/5] vhost: add an RPMsg API

[Guennadi Liakhovetski]

Linux supports running the RPMsg protocol over the VirtIO transport
protocol, but currently there is only support for VirtIO clients and
no support for a VirtIO server. This patch adds a vhost-based RPMsg
server implementation.

Signed-off-by: Guennadi Liakhovetski 
---
 drivers/vhost/Kconfig   |   7 +
 drivers/vhost/Makefile  |   3 +
 drivers/vhost/rpmsg.c   | 382 
 drivers/vhost/vhost_rpmsg.h |  74 +
 4 files changed, 466 insertions(+)
 create mode 100644 drivers/vhost/rpmsg.c
 create mode 100644 drivers/vhost/vhost_rpmsg.h

diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
index 2c75d16..8b91f3e 100644
--- a/drivers/vhost/Kconfig
+++ b/drivers/vhost/Kconfig
@@ -38,6 +38,13 @@ config VHOST_NET
  To compile this driver as a module, choose M here: the module will
  be called vhost_net.
 
+config VHOST_RPMSG
+   tristate
+   depends on VHOST
+   help
+ Vhost RPMsg API allows vhost drivers to communicate with VirtIO
+ drivers, using the RPMsg over VirtIO protocol.
+
 config VHOST_SCSI
tristate "VHOST_SCSI TCM fabric driver"
depends on TARGET_CORE && EVENTFD
diff --git a/drivers/vhost/Makefile b/drivers/vhost/Makefile
index f3e1897..9cf459d 100644
--- a/drivers/vhost/Makefile
+++ b/drivers/vhost/Makefile
@@ -2,6 +2,9 @@
 obj-$(CONFIG_VHOST_NET) += vhost_net.o
 vhost_net-y := net.o
 
+obj-$(CONFIG_VHOST_RPMSG) += vhost_rpmsg.o
+vhost_rpmsg-y := rpmsg.o
+
 obj-$(CONFIG_VHOST_SCSI) += vhost_scsi.o
 vhost_scsi-y := scsi.o
 
diff --git a/drivers/vhost/rpmsg.c b/drivers/vhost/rpmsg.c
new file mode 100644
index ..ea77e1f
--- /dev/null
+++ b/drivers/vhost/rpmsg.c
@@ -0,0 +1,382 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright(c) 2020 Intel Corporation. All rights reserved.
+ *
+ * Author: Guennadi Liakhovetski 
+ *
+ * Vhost RPMsg VirtIO interface. It provides a set of functions to match the
+ * guest side RPMsg VirtIO API, provided by drivers/rpmsg/virtio_rpmsg_bus.c
+ * These functions handle creation of 2 virtual queues, handling of endpoint
+ * addresses, sending a name-space announcement to the guest as well as any
+ * user messages. This API can be used by any vhost driver to handle RPMsg
+ * specific processing.
+ * Specific vhost drivers, using this API will use their own VirtIO device
+ * IDs, that should then also be added to the ID table in virtio_rpmsg_bus.c
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "vhost.h"
+#include "vhost_rpmsg.h"
+
+/*
+ * All virtio-rpmsg virtual queue kicks always come with just one buffer -
+ * either input or output
+ */
+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),
+, , 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 == >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 == >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 return the buffer using vhost_add_used()
+* or vhost_discard_vq_desc(). vhost_discard_vq_desc() is
+* described as "being useful for error handling," but it makes
+* the thus discarded buffers "unseen," so next time we look we
+* retrieve them again?
+*/
+   return -EINVAL;
+}
+
+static const struct vhost_rpmsg_ept *vhost_rpmsg_ept_find(
+   struct vhost_rpmsg *vr, int addr)
+{
+   unsigned int i;
+
+   for (i = 0; i < vr->n_epts; i++)
+   if (vr->ept[i].addr == addr)
+   return vr->ept + i;
+
+   return NULL;
+}
+
+/*
+ * if len < 0, then for reading a request, the complete virtual queue buffer
+ * size is prepared, for sending a response, the length in the iterator is used
+ */
+int vhost_rpmsg_start_lock(struct vhost_rpmsg *vr,
+  struct vhost_rpmsg_iter *iter,
+  unsigned int

[PATCH v3 3/5] rpmsg: move common structures and defines to headers

[Guennadi Liakhovetski]

virtio_rpmsg_bus.c keeps RPMsg protocol structure declarations and
common defines like the ones, needed for name-space announcements,
internal. Move them to common headers instead.

Reviewed-by: Mathieu Poirier 
Signed-off-by: Guennadi Liakhovetski 
---
 drivers/rpmsg/virtio_rpmsg_bus.c | 78 +-
 include/linux/virtio_rpmsg.h | 81 
 include/uapi/linux/rpmsg.h   |  3 ++
 3 files changed, 86 insertions(+), 76 deletions(-)
 create mode 100644 include/linux/virtio_rpmsg.h

diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index 07d4f33..f3bd050 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -25,7 +25,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 
 #include "rpmsg_internal.h"
 
@@ -69,58 +71,6 @@ struct virtproc_info {
struct rpmsg_endpoint *ns_ept;
 };
 
-/* The feature bitmap for virtio rpmsg */
-#define VIRTIO_RPMSG_F_NS  0 /* RP supports name service notifications */
-
-/**
- * struct rpmsg_hdr - common header for all rpmsg messages
- * @src: source address
- * @dst: destination address
- * @reserved: reserved for future use
- * @len: length of payload (in bytes)
- * @flags: message flags
- * @data: @len bytes of message payload data
- *
- * Every message sent(/received) on the rpmsg bus begins with this header.
- */
-struct rpmsg_hdr {
-   u32 src;
-   u32 dst;
-   u32 reserved;
-   u16 len;
-   u16 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 to publish a new service, or announce
- * about its removal. When we receive these messages, an appropriate
- * rpmsg channel (i.e device) is created/destroyed. In turn, the ->probe()
- * or ->remove() handler of the appropriate rpmsg driver will be invoked
- * (if/as-soon-as one is registered).
- */
-struct rpmsg_ns_msg {
-   char name[RPMSG_NAME_SIZE];
-   u32 addr;
-   u32 flags;
-} __packed;
-
-/**
- * enum rpmsg_ns_flags - dynamic name service announcement flags
- *
- * @RPMSG_NS_CREATE: a new remote service was just created
- * @RPMSG_NS_DESTROY: a known remote service was just destroyed
- */
-enum rpmsg_ns_flags {
-   RPMSG_NS_CREATE = 0,
-   RPMSG_NS_DESTROY= 1,
-};
-
 /**
  * @vrp: the remote processor this channel belongs to
  */
@@ -134,36 +84,12 @@ struct virtio_rpmsg_channel {
container_of(_rpdev, struct virtio_rpmsg_channel, rpdev)
 
 /*
- * We're allocating buffers of 512 bytes each for communications. The
- * number of buffers will be computed from the number of buffers supported
- * by the vring, upto a maximum of 512 buffers (256 in each direction).
- *
- * Each buffer will have 16 bytes for the msg header and 496 bytes for
- * the payload.
- *
- * This will utilize a maximum total space of 256KB for the buffers.
- *
- * We might also want to add support for user-provided buffers in time.
- * This will allow bigger buffer size flexibility, and can also be used
- * to achieve zero-copy messaging.
- *
- * Note that these numbers are purely a decision of this driver - we
- * can change this without changing anything in the firmware of the remote
- * processor.
- */
-#define MAX_RPMSG_NUM_BUFS (512)
-#define MAX_RPMSG_BUF_SIZE (512)
-
-/*
  * Local addresses are dynamically allocated on-demand.
  * We do not dynamically assign addresses from the low 1024 range,
  * in order to reserve that address range for predefined services.
  */
 #define RPMSG_RESERVED_ADDRESSES   (1024)
 
-/* Address 53 is reserved for advertising remote services */
-#define RPMSG_NS_ADDR  (53)
-
 static void virtio_rpmsg_destroy_ept(struct rpmsg_endpoint *ept);
 static int virtio_rpmsg_send(struct rpmsg_endpoint *ept, void *data, int len);
 static int virtio_rpmsg_sendto(struct rpmsg_endpoint *ept, void *data, int len,
diff --git a/include/linux/virtio_rpmsg.h b/include/linux/virtio_rpmsg.h
new file mode 100644
index ..679be8b
--- /dev/null
+++ b/include/linux/virtio_rpmsg.h
@@ -0,0 +1,81 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _LINUX_VIRTIO_RPMSG_H
+#define _LINUX_VIRTIO_RPMSG_H
+
+#include 
+
+/**
+ * struct rpmsg_hdr - common header for all rpmsg messages
+ * @src: source address
+ * @dst: destination address
+ * @reserved: reserved for future use
+ * @len: length of payload (in bytes)
+ * @flags: message flags
+ * @data: @len bytes of message payload data
+ *
+ * Every message sent(/received) on the rpmsg bus begins with this header.
+ */
+struct rpmsg_hdr {
+   u32 src;
+   u32 dst;
+   u32 reserved;
+   u16 len;
+   u16 flags;
+   u8 data[];
+} __packed;
+

[PATCH v3 2/5] vhost: (cosmetic) remove a superfluous variable initialisation

[Guennadi Liakhovetski]

Even the compiler is able to figure out that in this case the
initialisation is superfluous.

Signed-off-by: Guennadi Liakhovetski 
---
 drivers/vhost/vhost.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 2f4383bb..2b9ad8a 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -895,7 +895,7 @@ static inline void __user *__vhost_get_user(struct 
vhost_virtqueue *vq,
 
 #define vhost_put_user(vq, x, ptr) \
 ({ \
-   int ret = -EFAULT; \
+   int ret; \
if (!vq->iotlb) { \
ret = __put_user(x, ptr); \
} else { \
-- 
1.9.3

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [PATCH v2 5/5] vhost: add an RPMsg API

[Guennadi Liakhovetski]

Hi Mathieu,

On Tue, May 26, 2020 at 02:50:39PM -0600, Mathieu Poirier wrote:
> Hi Guennadi,
> 
> On Mon, May 25, 2020 at 04:44:58PM +0200, Guennadi Liakhovetski wrote:
> > Linux supports running the RPMsg protocol over the VirtIO transport
> > protocol, but currently there is only support for VirtIO clients and
> > no support for a VirtIO server. This patch adds a vhost-based RPMsg
> > server implementation.
> > 
> > Signed-off-by: Guennadi Liakhovetski 
> > ---
> >  drivers/vhost/Kconfig   |   7 +
> >  drivers/vhost/Makefile  |   3 +
> >  drivers/vhost/rpmsg.c   | 372 
> > 
> >  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() */
> > +   },
> > +   };
> > +   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 that will match that device to the virtio_ipc_driver.  Otherwise the
> connection between them is very difficult to establish.

In fact you don't want to use just one ID, as you add more drivers, using RPMsg 
over VirtIO, you'll add more IDs to the ID table in virtio_rpmsg_bus.c. I am 
adding a comment at the top of this file to explain that.

Thanks
Guennadi

> Aside from the checkpatch warning I already pointed out, I don't have much 
> else.
> 
> Thanks,
> Mathieu
> 
> > +   int ret = vhost_rpmsg_start_lock(vr, , VIRTIO_RPMSG_RESPONSE,
> > +sizeof(ns));
> > +
> > +   if (ret < 0)
> > +   return ret;
> > +
> > +   strlcpy(ns.name, name, sizeof(ns.name));
> > +
> > +   ret = vhost_rpmsg_copy(vr, , , sizeof(ns));
> > +   if (ret != sizeof(ns))
> > +   vq_err(iter.vq, "%s(): added %d instead of %zu bytes\n",
> > +  __func__, ret, sizeof(ns));
> > +
> > +   ret = vhost_rpmsg_finish_unlock(vr, );
> > +   if (ret < 0)
> > +   vq_err(iter.vq, "%s(): namespace announcement failed: %d\n",
> > +  __func__, ret);
> > +
> > +   return ret;
> > +}
> > +EXPORT_SYMBOL_GPL(vhost_rpmsg_ns_announce);
> > +
> > +MODULE_LICENSE("GPL v2");
> > +MODULE_AUTHOR("Intel, Inc.");
> > +MODULE_DESCRIPTION("Vhost RPMsg API");
> > diff --git a/drivers/vhost/vhost_rpmsg.h b/drivers/vhost/vhost_rpmsg.h
> > new file mode 100644
> > index ..5248ac9
> > --- /dev/null
> > +++ b/drivers/vhost/vhost_rpmsg.h
> > @@ -0,0 +1,74 @@
> > +/* SPDX-License-Identifier: (GPL-2.0) */
> > +/*
> > + * Copyright(c) 2020 Intel Corporation. All rights reserved.
> > + *
> > + * Author: Guennadi Liakhovetski 
> > + */
> > +
> > +#ifndef VHOST_RPMSG_H
> > +#define VHOST_RPMSG_H
> > +
> > +#include 
> > +#include 
> > +
> > +#include "vhost.h"
> > +
> > +/* RPMsg uses two VirtQueues: one for each direction */
> > +enum {
> > +   VIRTIO_RPMSG_RESPONSE,  /* RPMsg response (host->guest) buffers */
> > +   VIRTIO_RPMSG_REQUEST,   /* RPMsg request (guest->host) buffers */
> > +   /* Keep last */
> > +   VIRTIO_RPMSG_NUM_OF_VQS,
> > +};
> > +
> > +struct vhost_rpmsg_ept;
> > +
> > +struct vhost_rpmsg_iter {
> > +   struct iov_iter iov_iter;
> > +   struct rpmsg_hdr rhdr;
> > +   struct vhost_virtqueue *vq;
> > +   const struct vhost_rpmsg_ept *ept;
> > +   int head;
> > +   void *priv;
> > +};
> > +
> > +struct vhost_rpmsg {
> > +   struct vhost_dev dev;
> > +   struct vhost_virtqueue vq[VIRTIO_RPMSG_NUM_OF_VQS];
> > +   struct vhost_virtqueue *vq_p[VIRTIO_RPMSG_NUM_OF_VQS];
> > +   const struct vhost_rpmsg_ept *ept;
> > +   unsigned int n_epts;
> > +};
> > +
> > +struct vhost_rpmsg_ept {
> >

Re: [Sound-open-firmware] [PATCH 5/6] vhost: add an rpmsg API

[Guennadi Liakhovetski]

Hi Pierre,

On Tue, May 26, 2020 at 01:30:24PM -0500, Pierre-Louis Bossart wrote:
> 
> 
> On 5/25/20 8:53 AM, Guennadi Liakhovetski wrote:
> > Hi Pierre,
> > 
> > On Sat, May 16, 2020 at 12:00:35PM -0500, Pierre-Louis Bossart wrote:
> > > 
> > > > +config VHOST_RPMSG
> > > > +   tristate
> > > > +   depends on VHOST
> > > 
> > > depends on RPMSG_VIRTIO?
> > 
> > No, RPMSG_VIRTIO is used on the guest side, VHOST_RPMSG (as well as
> > all other vhost drivers) on the host side.
> 
> I vaguely recalled something about sockets, and was wondering if there isn't
> a dependency on this:
> 
> config VHOST_VSOCK
>   tristate "vhost virtio-vsock driver"
>   depends on VSOCKETS && EVENTFD && VHOST_DPN
>   select VHOST

You probably are thinking about the first patch in the series "vhost: convert 
VHOST_VSOCK_SET_RUNNING to a generic ioctl." But no, this RPMsg driver 
doesn't depend on vsock, on the contrary, it takes a (albeit tiny) piece of 
functionality from vsock and makes it global.

Thanks
Guennadi
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH v2 3/5] rpmsg: move common structures and defines to headers

[Guennadi Liakhovetski]

virtio_rpmsg_bus.c keeps RPMsg protocol structure declarations and
common defines like the ones, needed for name-space announcements,
internal. Move them to common headers instead.

Signed-off-by: Guennadi Liakhovetski 
---
 drivers/rpmsg/virtio_rpmsg_bus.c | 78 +-
 include/linux/virtio_rpmsg.h | 81 
 include/uapi/linux/rpmsg.h   |  3 ++
 3 files changed, 86 insertions(+), 76 deletions(-)
 create mode 100644 include/linux/virtio_rpmsg.h

diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index 07d4f33..f3bd050 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -25,7 +25,9 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
 
 #include "rpmsg_internal.h"
 
@@ -69,58 +71,6 @@ struct virtproc_info {
struct rpmsg_endpoint *ns_ept;
 };
 
-/* The feature bitmap for virtio rpmsg */
-#define VIRTIO_RPMSG_F_NS  0 /* RP supports name service notifications */
-
-/**
- * struct rpmsg_hdr - common header for all rpmsg messages
- * @src: source address
- * @dst: destination address
- * @reserved: reserved for future use
- * @len: length of payload (in bytes)
- * @flags: message flags
- * @data: @len bytes of message payload data
- *
- * Every message sent(/received) on the rpmsg bus begins with this header.
- */
-struct rpmsg_hdr {
-   u32 src;
-   u32 dst;
-   u32 reserved;
-   u16 len;
-   u16 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 to publish a new service, or announce
- * about its removal. When we receive these messages, an appropriate
- * rpmsg channel (i.e device) is created/destroyed. In turn, the ->probe()
- * or ->remove() handler of the appropriate rpmsg driver will be invoked
- * (if/as-soon-as one is registered).
- */
-struct rpmsg_ns_msg {
-   char name[RPMSG_NAME_SIZE];
-   u32 addr;
-   u32 flags;
-} __packed;
-
-/**
- * enum rpmsg_ns_flags - dynamic name service announcement flags
- *
- * @RPMSG_NS_CREATE: a new remote service was just created
- * @RPMSG_NS_DESTROY: a known remote service was just destroyed
- */
-enum rpmsg_ns_flags {
-   RPMSG_NS_CREATE = 0,
-   RPMSG_NS_DESTROY= 1,
-};
-
 /**
  * @vrp: the remote processor this channel belongs to
  */
@@ -134,36 +84,12 @@ struct virtio_rpmsg_channel {
container_of(_rpdev, struct virtio_rpmsg_channel, rpdev)
 
 /*
- * We're allocating buffers of 512 bytes each for communications. The
- * number of buffers will be computed from the number of buffers supported
- * by the vring, upto a maximum of 512 buffers (256 in each direction).
- *
- * Each buffer will have 16 bytes for the msg header and 496 bytes for
- * the payload.
- *
- * This will utilize a maximum total space of 256KB for the buffers.
- *
- * We might also want to add support for user-provided buffers in time.
- * This will allow bigger buffer size flexibility, and can also be used
- * to achieve zero-copy messaging.
- *
- * Note that these numbers are purely a decision of this driver - we
- * can change this without changing anything in the firmware of the remote
- * processor.
- */
-#define MAX_RPMSG_NUM_BUFS (512)
-#define MAX_RPMSG_BUF_SIZE (512)
-
-/*
  * Local addresses are dynamically allocated on-demand.
  * We do not dynamically assign addresses from the low 1024 range,
  * in order to reserve that address range for predefined services.
  */
 #define RPMSG_RESERVED_ADDRESSES   (1024)
 
-/* Address 53 is reserved for advertising remote services */
-#define RPMSG_NS_ADDR  (53)
-
 static void virtio_rpmsg_destroy_ept(struct rpmsg_endpoint *ept);
 static int virtio_rpmsg_send(struct rpmsg_endpoint *ept, void *data, int len);
 static int virtio_rpmsg_sendto(struct rpmsg_endpoint *ept, void *data, int len,
diff --git a/include/linux/virtio_rpmsg.h b/include/linux/virtio_rpmsg.h
new file mode 100644
index ..bf2fd69
--- /dev/null
+++ b/include/linux/virtio_rpmsg.h
@@ -0,0 +1,81 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#ifndef _LINUX_VIRTIO_RPMSG_H
+#define _LINUX_VIRTIO_RPMSG_H
+
+#include 
+
+/* Address 53 is reserved for advertising remote services */
+#define RPMSG_NS_ADDR  (53)
+
+/*
+ * We're allocating buffers of 512 bytes each for communications. The
+ * number of buffers will be computed from the number of buffers supported
+ * by the vring, upto a maximum of 512 buffers (256 in each direction).
+ *
+ * Each buffer will have 16 bytes for the msg header and 496 bytes for
+ * the payload.
+ *
+ * This will utilize a maximum total space of 256KB for the buffers.
+ *
+ * We might also want to add support f

[PATCH v2 4/5] rpmsg: update documentation

[Guennadi Liakhovetski]

rpmsg_create_ept() takes struct rpmsg_channel_info chinfo as its last
argument, not a u32 value.

Signed-off-by: Guennadi Liakhovetski 
---
 Documentation/rpmsg.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/rpmsg.txt b/Documentation/rpmsg.txt
index 24b7a9e..4f9bc4f 100644
--- a/Documentation/rpmsg.txt
+++ b/Documentation/rpmsg.txt
@@ -194,7 +194,7 @@ Returns 0 on success and an appropriate error value on 
failure.
 
   struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_channel *rpdev,
void (*cb)(struct rpmsg_channel *, void *, int, void *, u32),
-   void *priv, u32 addr);
+   void *priv, struct rpmsg_channel_info chinfo);
 
 every rpmsg address in the system is bound to an rx callback (so when
 inbound messages arrive, they are dispatched by the rpmsg bus using the
-- 
1.9.3

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH v2 5/5] vhost: add an RPMsg API

[Guennadi Liakhovetski]

Linux supports running the RPMsg protocol over the VirtIO transport
protocol, but currently there is only support for VirtIO clients and
no support for a VirtIO server. This patch adds a vhost-based RPMsg
server implementation.

Signed-off-by: Guennadi Liakhovetski 
---
 drivers/vhost/Kconfig   |   7 +
 drivers/vhost/Makefile  |   3 +
 drivers/vhost/rpmsg.c   | 372 
 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

diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
index 2c75d16..c2113db 100644
--- a/drivers/vhost/Kconfig
+++ b/drivers/vhost/Kconfig
@@ -38,6 +38,13 @@ config VHOST_NET
  To compile this driver as a module, choose M here: the module will
  be called vhost_net.
 
+config VHOST_RPMSG
+   tristate
+   depends on VHOST
+   ---help---
+ Vhost RPMsg API allows vhost drivers to communicate with VirtIO
+ drivers, using the RPMsg over VirtIO protocol.
+
 config VHOST_SCSI
tristate "VHOST_SCSI TCM fabric driver"
depends on TARGET_CORE && EVENTFD
diff --git a/drivers/vhost/Makefile b/drivers/vhost/Makefile
index f3e1897..9cf459d 100644
--- a/drivers/vhost/Makefile
+++ b/drivers/vhost/Makefile
@@ -2,6 +2,9 @@
 obj-$(CONFIG_VHOST_NET) += vhost_net.o
 vhost_net-y := net.o
 
+obj-$(CONFIG_VHOST_RPMSG) += vhost_rpmsg.o
+vhost_rpmsg-y := rpmsg.o
+
 obj-$(CONFIG_VHOST_SCSI) += vhost_scsi.o
 vhost_scsi-y := scsi.o
 
diff --git a/drivers/vhost/rpmsg.c b/drivers/vhost/rpmsg.c
new file mode 100644
index ..609b9cf
--- /dev/null
+++ b/drivers/vhost/rpmsg.c
@@ -0,0 +1,372 @@
+/* SPDX-License-Identifier: (GPL-2.0-only) */
+/*
+ * Copyright(c) 2020 Intel Corporation. All rights reserved.
+ *
+ * Author: Guennadi Liakhovetski 
+ *
+ * vhost-RPMsg VirtIO interface
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "vhost.h"
+#include "vhost_rpmsg.h"
+
+/*
+ * All virtio-rpmsg virtual queue kicks always come with just one buffer -
+ * either input or output
+ */
+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),
+, , 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 == >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 == >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 return the buffer using vhost_add_used()
+* or vhost_discard_vq_desc(). vhost_discard_vq_desc() is
+* described as "being useful for error handling," but it makes
+* the thus discarded buffers "unseen," so next time we look we
+* retrieve them again?
+*/
+   return -EINVAL;
+}
+
+static const struct vhost_rpmsg_ept *vhost_rpmsg_ept_find(struct vhost_rpmsg 
*vr,
+ int addr)
+{
+   unsigned int i;
+
+   for (i = 0; i < vr->n_epts; i++)
+   if (vr->ept[i].addr == addr)
+   return vr->ept + i;
+
+   return NULL;
+}
+
+/*
+ * if len < 0, then for reading a request, the complete virtual queue buffer
+ * size is prepared, for sending a response, the length in the iterator is used
+ */
+int vhost_rpmsg_start_lock(struct vhost_rpmsg *vr,
+  struct vhost_rpmsg_iter *iter,
+  unsigned int qid, ssize_t len)
+   __acquires(vq->mutex)
+{
+   struct vhost_virtqueue *vq = vr->vq + qid;
+   size_t tmp;
+
+   if (qid >= VIRTIO_RPMSG_NUM_OF_VQS)
+   return -EINVAL;
+
+   iter->vq = vq;
+
+   mutex_lock(>mutex);
+   vhost_disable_notify(>dev, vq);
+
+   iter->head = vhost_rpmsg_get_single(vq);
+   if (iter->head == vq->num)
+   iter->head = -EAGAIN;
+
+   if (iter->head < 0)
+   goto unlock;

[PATCH v2 0/5] Add a vhost RPMsg API

[Guennadi Liakhovetski]

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 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, ready
for review and submission, available at
https://github.com/thesofproject/linux/pull/1501/commits
A further patch for the ADSP vhost RPMsg driver will be sent
separately for review only since it cannot be merged without audio
patches being upstreamed first.

Thanks
Guennadi

Guennadi Liakhovetski (5):
  vhost: convert VHOST_VSOCK_SET_RUNNING to a generic ioctl
  vhost: (cosmetic) remove a superfluous variable initialisation
  rpmsg: move common structures and defines to headers
  rpmsg: update documentation
  vhost: add an rpmsg API

 Documentation/rpmsg.txt  |   2 +-
 drivers/rpmsg/virtio_rpmsg_bus.c |  78 +---
 drivers/vhost/Kconfig|   7 +
 drivers/vhost/Makefile   |   3 +
 drivers/vhost/rpmsg.c| 372 +++
 drivers/vhost/vhost.c|   2 +-
 drivers/vhost/vhost_rpmsg.h  |  74 
 include/linux/virtio_rpmsg.h |  81 +
 include/uapi/linux/rpmsg.h   |   3 +
 include/uapi/linux/vhost.h   |   4 +-
 10 files changed, 547 insertions(+), 79 deletions(-)
 create mode 100644 drivers/vhost/rpmsg.c
 create mode 100644 drivers/vhost/vhost_rpmsg.h
 create mode 100644 include/linux/virtio_rpmsg.h

-- 
1.9.3

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH v2 1/5] vhost: convert VHOST_VSOCK_SET_RUNNING to a generic ioctl

[Guennadi Liakhovetski]

VHOST_VSOCK_SET_RUNNING is used by the vhost vsock driver to perform
crucial VirtQueue initialisation, like assigning .private fields and
calling vhost_vq_init_access(), and clean up. However, this ioctl is
actually extremely useful for any vhost driver, that doesn't have a
side channel to inform it of a status change, e.g. upon a guest
reboot. This patch makes that ioctl generic, while preserving its
numeric value and also keeping the original alias.

Signed-off-by: Guennadi Liakhovetski 
---
 include/uapi/linux/vhost.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/vhost.h b/include/uapi/linux/vhost.h
index 9fe72e4..b54af9d 100644
--- a/include/uapi/linux/vhost.h
+++ b/include/uapi/linux/vhost.h
@@ -93,6 +93,8 @@
 #define VHOST_SET_BACKEND_FEATURES _IOW(VHOST_VIRTIO, 0x25, __u64)
 #define VHOST_GET_BACKEND_FEATURES _IOR(VHOST_VIRTIO, 0x26, __u64)
 
+#define VHOST_SET_RUNNING _IOW(VHOST_VIRTIO, 0x61, int)
+
 /* VHOST_NET specific defines */
 
 /* Attach virtio net ring to a raw socket, or tap device.
@@ -114,7 +116,7 @@
 /* VHOST_VSOCK specific defines */
 
 #define VHOST_VSOCK_SET_GUEST_CID  _IOW(VHOST_VIRTIO, 0x60, __u64)
-#define VHOST_VSOCK_SET_RUNNING_IOW(VHOST_VIRTIO, 0x61, int)
+#define VHOST_VSOCK_SET_RUNNINGVHOST_SET_RUNNING
 
 /* VHOST_VDPA specific defines */
 
-- 
1.9.3

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH v2 2/5] vhost: (cosmetic) remove a superfluous variable initialisation

[Guennadi Liakhovetski]

Even the compiler is able to figure out that in this case the
initialisation is superfluous.

Signed-off-by: Guennadi Liakhovetski 
---
 drivers/vhost/vhost.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 2f4383bb..2b9ad8a 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -895,7 +895,7 @@ static inline void __user *__vhost_get_user(struct 
vhost_virtqueue *vq,
 
 #define vhost_put_user(vq, x, ptr) \
 ({ \
-   int ret = -EFAULT; \
+   int ret; \
if (!vq->iotlb) { \
ret = __put_user(x, ptr); \
} else { \
-- 
1.9.3

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [Sound-open-firmware] [PATCH 5/6] vhost: add an rpmsg API

[Guennadi Liakhovetski]

Hi Pierre,

On Sat, May 16, 2020 at 12:00:35PM -0500, Pierre-Louis Bossart wrote:
> 
> > +config VHOST_RPMSG
> > +   tristate
> > +   depends on VHOST
> 
> depends on RPMSG_VIRTIO?

No, RPMSG_VIRTIO is used on the guest side, VHOST_RPMSG (as well as 
all other vhost drivers) on the host side.

> > +   default n
> 
> not needed

Ok, will remove.

Thanks
Guennadi
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Re: [Sound-open-firmware] [PATCH RFC] vhost: add an SOF Audio DSP driver

[Guennadi Liakhovetski]

Hi Pierre,

Thanks for the review!

On Sat, May 16, 2020 at 11:50:48AM -0500, Pierre-Louis Bossart wrote:
> 
> 
> 
> > +config VHOST_SOF
> > +   tristate "Vhost SOF driver"
> > +   depends on SND_SOC_SOF
> 
> you probably want to make sure VHOST_SOF and SND_SOC_SOF are both built-in
> or module. Without constraints you are likely to trigger errors with
> randconfig. It's a classic.

"depends on" guarantees, that I cannot build VHOST_SOF into the kernel while 
SND_SOC_SOF is configured as a module and that I cannot enable VHOST_SOF 
while SND_SOC_SOF is disabled, isn't it enough? Is there a problem if 
VHOST_SOF is a module and SND_SOC_SOF is built into the kernel?

> > +   select VHOST
> > +   select VHOST_RPMSG
> > +   default n
> 
> not needed, default is always no.

Ok, thanks, will remove.

> > +   ---help---
> > + SOF vhost VirtIO driver. It exports the same IPC interface, as the
> > + one, used for Audio DSP communication, to Linux VirtIO guests.
> 
> [...]
> 
> > +struct vhost_dsp {
> > +   struct vhost_rpmsg vrdev;
> > +
> > +   struct sof_vhost_client *snd;
> > +
> > +   bool active;
> 
> I am struggling with this definition, it seems to be a local flag but how is
> it aligned to the actual DSP status?
> In other words, can you have cases where the dsp is considered 'active' here
> but might be pm_runtime suspended?
> I am sure you've thought of it based on previous threads, it'd be worth
> adding comments.

Yes, it might be a bit confusing, I'll add comments. This flag has nothing to 
do with the DSP state. Its purpose is to track reboots of the client, that has 
opened the misc devices. Normally the vhost driver doesn't get notified when 
that happens.

> > +
> > +   /* RPMsg address of the position update endpoint */
> > +   u32 posn_addr;
> > +   /* position update buffer and work */
> > +   struct vhost_work posn_work;
> > +   struct sof_ipc_stream_posn posn;
> > +
> > +   /* IPC request buffer */
> > +   struct sof_rpmsg_ipc_req ipc_buf;
> > +   /* IPC response buffer */
> > +   u8 reply_buf[SOF_IPC_MSG_MAX_SIZE];
> > +   /*
> > +* data response header, captured audio data is copied directly from the
> > +* DMA buffer
> 
> so zero-copy is not supported for now, right?

Not yet, no, the infrastructure isn't in the mainline yet.

> > +*/
> > +   struct sof_rpmsg_data_resp data_resp;
> > +};
> > +
> > +/* A guest is booting */
> > +static int vhost_dsp_activate(struct vhost_dsp *dsp)
> > +{
> > +   unsigned int i;
> > +   int ret = 0;
> > +
> > +   mutex_lock(>vrdev.dev.mutex);
> > +
> > +   /* Wait until all the VirtQueues have been initialised */
> > +   if (!dsp->active) {
> > +   struct vhost_virtqueue *vq;
> > +
> > +   for (i = 0, vq = dsp->vrdev.vq;
> > +i < ARRAY_SIZE(dsp->vrdev.vq);
> > +i++, vq++) {
> > +   /* .private_data is required != NULL */
> > +   vq->private_data = vq;
> > +   /* needed for re-initialisation upon guest reboot */
> > +   ret = vhost_vq_init_access(vq);
> > +   if (ret)
> > +   vq_err(vq,
> > +  "%s(): error %d initialising vq #%d\n",
> > +  __func__, ret, i);
> > +   }
> > +
> > +   /* Send an RPMsg namespace announcement */
> > +   if (!ret && !vhost_rpmsg_ns_announce(>vrdev, "sof_rpmsg",
> > +SOF_RPMSG_ADDR_IPC))
> > +   dsp->active = true;
> > +   }
> > +
> > +   mutex_unlock(>vrdev.dev.mutex);
> > +
> > +   return ret;
> > +}
> > +
> > +/* A guest is powered off or reset */
> > +static void vhost_dsp_deactivate(struct vhost_dsp *dsp)
> > +{
> > +   unsigned int i;
> > +
> > +   mutex_lock(>vrdev.dev.mutex);
> > +
> > +   if (dsp->active) {
> > +   struct vhost_virtqueue *vq;
> > +
> > +   dsp->active = false;
> 
> can you explain why this is not symmetrical with _activate above: there is
> no rmpsg communication here?

No, none is needed here. You only need to announce the name-space once when 
initialising, there's nothing to be done when cleaning up.

> > +
> > +   /* If a VM reboots sof_vhost_client_release() isn't called */
> > +   sof_vhost_topology_purge(dsp->snd);
> > +
> > +   /* signal, that we're inactive */
> > +   for (i = 0, vq = dsp->vrdev.vq;
> > +i < ARRAY_SIZE(dsp->vrdev.vq);
> > +i++, vq++) {
> > +   mutex_lock(>mutex);
> > +   vq->private_data = NULL;
> > +   mutex_unlock(>mutex);
> > +   }
> > +   }
> > +
> > +   mutex_unlock(>vrdev.dev.mutex);
> > +}
> > +
> 
> [...]
> 
> > +/* .ioctl(): we only use VHOST_SET_RUNNING in a non-default way */
> > +static long vhost_dsp_ioctl(struct file *filp, unsigned int ioctl,
> > +   unsigned long arg)
> > +{
> > +   struct 

[PATCH RFC] vhost: add an SOF Audio DSP driver

[Guennadi Liakhovetski]

The SOF ADSP vhost driver consists of two parts: a sound and a vhost
part. This patch implements the vhost part of the driver. It handles
QEMU communication with the vhost misc device and virtual queues to
any VirtIO RPMsg guests.

Signed-off-by: Guennadi Liakhovetski 
---

This is marked as an RFC / request for review, since it depends on other
patches, that haven't been merged yet. It uses the vhost RPMsg API, submitted
minutes ago to the lists
https://lists.linuxfoundation.org/pipermail/virtualization/2020-May/047669.html
and is a part of the SOF virtualisation project
https://github.com/thesofproject/linux/pull/1501/commits

Thanks
Guennadi

 drivers/vhost/Kconfig  |  10 +
 drivers/vhost/Makefile |   3 +
 drivers/vhost/adsp.c   | 618 +
 3 files changed, 631 insertions(+)
 create mode 100644 drivers/vhost/adsp.c

diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
index 4021522..2aff7c1 100644
--- a/drivers/vhost/Kconfig
+++ b/drivers/vhost/Kconfig
@@ -28,6 +28,16 @@ config VHOST_SCSI
Say M here to enable the vhost_scsi TCM fabric module
for use with virtio-scsi guests
 
+config VHOST_SOF
+   tristate "Vhost SOF driver"
+   depends on SND_SOC_SOF
+   select VHOST
+   select VHOST_RPMSG
+   default n
+   ---help---
+ SOF vhost VirtIO driver. It exports the same IPC interface, as the
+ one, used for Audio DSP communication, to Linux VirtIO guests.
+
 config VHOST_VSOCK
tristate "vhost virtio-vsock driver"
depends on VSOCKETS && EVENTFD
diff --git a/drivers/vhost/Makefile b/drivers/vhost/Makefile
index 29b8115..3de5e08 100644
--- a/drivers/vhost/Makefile
+++ b/drivers/vhost/Makefile
@@ -8,6 +8,9 @@ vhost_rpmsg-y := rpmsg.o
 obj-$(CONFIG_VHOST_SCSI) += vhost_scsi.o
 vhost_scsi-y := scsi.o
 
+obj-$(CONFIG_VHOST_SOF) += vhost_sof.o
+vhost_sof-y := adsp.o
+
 obj-$(CONFIG_VHOST_VSOCK) += vhost_vsock.o
 vhost_vsock-y := vsock.o
 
diff --git a/drivers/vhost/adsp.c b/drivers/vhost/adsp.c
new file mode 100644
index ..c386cf3
--- /dev/null
+++ b/drivers/vhost/adsp.c
@@ -0,0 +1,618 @@
+/* SPDX-License-Identifier: (GPL-2.0 OR BSD-3-Clause) */
+/*
+ * Copyright(c) 2019-2020 Intel Corporation. All rights reserved.
+ *
+ * Author: Guennadi Liakhovetski 
+ *
+ * vhost-SOF VirtIO interface
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+#include "vhost.h"
+#include "vhost_rpmsg.h"
+
+#define VHOST_DSP_FEATURES (VHOST_FEATURES | (1ULL << VIRTIO_RPMSG_F_NS))
+
+struct snd_sof_dev;
+struct sof_vhost_client;
+
+struct vhost_dsp {
+   struct vhost_rpmsg vrdev;
+
+   struct sof_vhost_client *snd;
+
+   bool active;
+
+   /* RPMsg address of the position update endpoint */
+   u32 posn_addr;
+   /* position update buffer and work */
+   struct vhost_work posn_work;
+   struct sof_ipc_stream_posn posn;
+
+   /* IPC request buffer */
+   struct sof_rpmsg_ipc_req ipc_buf;
+   /* IPC response buffer */
+   u8 reply_buf[SOF_IPC_MSG_MAX_SIZE];
+   /*
+* data response header, captured audio data is copied directly from the
+* DMA buffer
+*/
+   struct sof_rpmsg_data_resp data_resp;
+};
+
+/* A guest is booting */
+static int vhost_dsp_activate(struct vhost_dsp *dsp)
+{
+   unsigned int i;
+   int ret = 0;
+
+   mutex_lock(>vrdev.dev.mutex);
+
+   /* Wait until all the VirtQueues have been initialised */
+   if (!dsp->active) {
+   struct vhost_virtqueue *vq;
+
+   for (i = 0, vq = dsp->vrdev.vq;
+i < ARRAY_SIZE(dsp->vrdev.vq);
+i++, vq++) {
+   /* .private_data is required != NULL */
+   vq->private_data = vq;
+   /* needed for re-initialisation upon guest reboot */
+   ret = vhost_vq_init_access(vq);
+   if (ret)
+   vq_err(vq,
+  "%s(): error %d initialising vq #%d\n",
+  __func__, ret, i);
+   }
+
+   /* Send an RPMsg namespace announcement */
+   if (!ret && !vhost_rpmsg_ns_announce(>vrdev, "sof_rpmsg",
+SOF_RPMSG_ADDR_IPC))
+   dsp->active = true;
+   }
+
+   mutex_unlock(>vrdev.dev.mutex);
+
+   return ret;
+}
+
+/* A guest is powered off or reset */
+static void vhost_dsp_deactivate(struct vhost_dsp *dsp)
+{
+   unsigned int i;
+
+   mutex_lock(>vrdev.dev.mutex);
+
+   if (dsp->active) {
+   struct vhost_virtqueue *vq;
+
+   dsp->active = false;
+
+

[PATCH 6/6] rpmsg: add a device ID to also bind to the ADSP device

[Guennadi Liakhovetski]

The ADSP device uses the RPMsg API to connect vhost and VirtIO SOF
Audio DSP drivers on KVM host and guest.

Signed-off-by: Guennadi Liakhovetski 
---
 drivers/rpmsg/virtio_rpmsg_bus.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/rpmsg/virtio_rpmsg_bus.c b/drivers/rpmsg/virtio_rpmsg_bus.c
index f3bd050..ebe3f19 100644
--- a/drivers/rpmsg/virtio_rpmsg_bus.c
+++ b/drivers/rpmsg/virtio_rpmsg_bus.c
@@ -949,6 +949,7 @@ static void rpmsg_remove(struct virtio_device *vdev)
 
 static struct virtio_device_id id_table[] = {
{ VIRTIO_ID_RPMSG, VIRTIO_DEV_ANY_ID },
+   { VIRTIO_ID_ADSP, VIRTIO_DEV_ANY_ID },
{ 0 },
 };
 
-- 
1.9.3

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH 5/6] vhost: add an rpmsg API

[Guennadi Liakhovetski]

Linux supports running the RPMsg protocol over the VirtIO transport
protocol, but currently there is only support for VirtIO clients and
no support for a VirtIO server. This patch adds a vhost-based RPMsg
server implementation.

Signed-off-by: Guennadi Liakhovetski 
---
 drivers/vhost/Kconfig   |   8 +
 drivers/vhost/Makefile  |   3 +
 drivers/vhost/rpmsg.c   | 372 
 drivers/vhost/vhost_rpmsg.h |  74 +
 4 files changed, 457 insertions(+)
 create mode 100644 drivers/vhost/rpmsg.c
 create mode 100644 drivers/vhost/vhost_rpmsg.h

diff --git a/drivers/vhost/Kconfig b/drivers/vhost/Kconfig
index 2c75d16..4ebc871 100644
--- a/drivers/vhost/Kconfig
+++ b/drivers/vhost/Kconfig
@@ -38,6 +38,14 @@ config VHOST_NET
  To compile this driver as a module, choose M here: the module will
  be called vhost_net.
 
+config VHOST_RPMSG
+   tristate
+   depends on VHOST
+   default n
+   ---help---
+ Vhost RPMSG API allows vhost drivers to communicate with VirtIO
+ drivers, using the RPMsg over VirtIO protocol.
+
 config VHOST_SCSI
tristate "VHOST_SCSI TCM fabric driver"
depends on TARGET_CORE && EVENTFD
diff --git a/drivers/vhost/Makefile b/drivers/vhost/Makefile
index f3e1897..9cf459d 100644
--- a/drivers/vhost/Makefile
+++ b/drivers/vhost/Makefile
@@ -2,6 +2,9 @@
 obj-$(CONFIG_VHOST_NET) += vhost_net.o
 vhost_net-y := net.o
 
+obj-$(CONFIG_VHOST_RPMSG) += vhost_rpmsg.o
+vhost_rpmsg-y := rpmsg.o
+
 obj-$(CONFIG_VHOST_SCSI) += vhost_scsi.o
 vhost_scsi-y := scsi.o
 
diff --git a/drivers/vhost/rpmsg.c b/drivers/vhost/rpmsg.c
new file mode 100644
index ..2fa82bd
--- /dev/null
+++ b/drivers/vhost/rpmsg.c
@@ -0,0 +1,372 @@
+/* SPDX-License-Identifier: (GPL-2.0-only) */
+/*
+ * Copyright(c) 2020 Intel Corporation. All rights reserved.
+ *
+ * Author: Guennadi Liakhovetski 
+ *
+ * vhost-RPMsg VirtIO interface
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "vhost.h"
+#include "vhost_rpmsg.h"
+
+/*
+ * All virtio-rpmsg virtual queue kicks always come with just one buffer -
+ * either input or output
+ */
+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),
+, , 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 == >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 == >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 return the buffer using vhost_add_used()
+* or vhost_discard_vq_desc(). vhost_discard_vq_desc() is
+* described as "being useful for error handling," but it makes
+* the thus discarded buffers "unseen," so next time we look we
+* retrieve them again?
+*/
+   return -EINVAL;
+}
+
+static const struct vhost_rpmsg_ept *vhost_rpmsg_ept_find(struct vhost_rpmsg 
*vr,
+ int addr)
+{
+   unsigned int i;
+
+   for (i = 0; i < vr->n_epts; i++)
+   if (vr->ept[i].addr == addr)
+   return vr->ept + i;
+
+   return NULL;
+}
+
+/*
+ * if len < 0, then for reading a request, the complete virtual queue buffer
+ * size is prepared, for sending a response, the length in the iterator is used
+ */
+int vhost_rpmsg_start_lock(struct vhost_rpmsg *vr,
+  struct vhost_rpmsg_iter *iter,
+  unsigned int qid, ssize_t len)
+   __acquires(vq->mutex)
+{
+   struct vhost_virtqueue *vq = vr->vq + qid;
+   size_t tmp;
+
+   if (qid >= VIRTIO_RPMSG_NUM_OF_VQS)
+   return -EINVAL;
+
+   iter->vq = vq;
+
+   mutex_lock(>mutex);
+   vhost_disable_notify(>dev, vq);
+
+   iter->head = vhost_rpmsg_get_single(vq);
+   if (iter->head == vq->num)
+   iter->head = -EAGAIN;
+
+   if (iter->head < 0)

[PATCH 4/6] rpmsg: update documentation

[Guennadi Liakhovetski]

rpmsg_create_ept() takes struct rpmsg_channel_info chinfo as its last
argument, not a u32 value.

Signed-off-by: Guennadi Liakhovetski 
---
 Documentation/rpmsg.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/rpmsg.txt b/Documentation/rpmsg.txt
index 24b7a9e..4f9bc4f 100644
--- a/Documentation/rpmsg.txt
+++ b/Documentation/rpmsg.txt
@@ -194,7 +194,7 @@ Returns 0 on success and an appropriate error value on 
failure.
 
   struct rpmsg_endpoint *rpmsg_create_ept(struct rpmsg_channel *rpdev,
void (*cb)(struct rpmsg_channel *, void *, int, void *, u32),
-   void *priv, u32 addr);
+   void *priv, struct rpmsg_channel_info chinfo);
 
 every rpmsg address in the system is bound to an rx callback (so when
 inbound messages arrive, they are dispatched by the rpmsg bus using the
-- 
1.9.3

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH 0/6] Add a vhost RPMsg API

[Guennadi Liakhovetski]

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, ready
for review and submission, available at
https://github.com/thesofproject/linux/pull/1501/commits
A further patch for the ADSP vhost RPMsg driver will be sent
separately for review only since it cannot be merged without audio
patches being upstreamed first.

Thanks
Guennadi

Guennadi Liakhovetski (6):
  vhost: convert VHOST_VSOCK_SET_RUNNING to a generic ioctl
  vhost: (cosmetic) remove a superfluous variable initialisation
  rpmsg: move common structures and defines to headers
  rpmsg: update documentation
  vhost: add an rpmsg API
  rpmsg: add a device ID to also bind to the ADSP device

 Documentation/rpmsg.txt  |   2 +-
 drivers/rpmsg/virtio_rpmsg_bus.c |  79 +
 drivers/vhost/Kconfig|   8 +
 drivers/vhost/Makefile   |   3 +
 drivers/vhost/rpmsg.c| 372 +++
 drivers/vhost/vhost.c|   2 +-
 drivers/vhost/vhost_rpmsg.h  |  74 
 include/linux/virtio_rpmsg.h |  81 +
 include/uapi/linux/rpmsg.h   |   3 +
 include/uapi/linux/vhost.h   |   4 +-
 10 files changed, 549 insertions(+), 79 deletions(-)
 create mode 100644 drivers/vhost/rpmsg.c
 create mode 100644 drivers/vhost/vhost_rpmsg.h
 create mode 100644 include/linux/virtio_rpmsg.h

-- 
1.9.3

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH 2/6] vhost: (cosmetic) remove a superfluous variable initialisation

[Guennadi Liakhovetski]

Even the compiler is able to figure out that in this case the
initialisation is superfluous.

Signed-off-by: Guennadi Liakhovetski 
---
 drivers/vhost/vhost.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 47060d8..e22d4a9 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -895,7 +895,7 @@ static inline void __user *__vhost_get_user(struct 
vhost_virtqueue *vq,
 
 #define vhost_put_user(vq, x, ptr) \
 ({ \
-   int ret = -EFAULT; \
+   int ret; \
if (!vq->iotlb) { \
ret = __put_user(x, ptr); \
} else { \
-- 
1.9.3

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

[PATCH 1/6] vhost: convert VHOST_VSOCK_SET_RUNNING to a generic ioctl

[Guennadi Liakhovetski]

VHOST_VSOCK_SET_RUNNING is used by the vhost vsock driver to perform
crucial VirtQueue initialisation, like assigning .private fields and
calling vhost_vq_init_access(), and clean up. However, this ioctl is
actually extremely useful for any vhost driver, that doesn't have a
side channel to inform it of a status change, e.g. upon a guest
reboot. This patch makes that ioctl generic, while preserving its
numeric value and also keeping the original alias.

Signed-off-by: Guennadi Liakhovetski 
---
 include/uapi/linux/vhost.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/vhost.h b/include/uapi/linux/vhost.h
index 9fe72e4..b54af9d 100644
--- a/include/uapi/linux/vhost.h
+++ b/include/uapi/linux/vhost.h
@@ -93,6 +93,8 @@
 #define VHOST_SET_BACKEND_FEATURES _IOW(VHOST_VIRTIO, 0x25, __u64)
 #define VHOST_GET_BACKEND_FEATURES _IOR(VHOST_VIRTIO, 0x26, __u64)
 
+#define VHOST_SET_RUNNING _IOW(VHOST_VIRTIO, 0x61, int)
+
 /* VHOST_NET specific defines */
 
 /* Attach virtio net ring to a raw socket, or tap device.
@@ -114,7 +116,7 @@
 /* VHOST_VSOCK specific defines */
 
 #define VHOST_VSOCK_SET_GUEST_CID  _IOW(VHOST_VIRTIO, 0x60, __u64)
-#define VHOST_VSOCK_SET_RUNNING_IOW(VHOST_VIRTIO, 0x61, int)
+#define VHOST_VSOCK_SET_RUNNINGVHOST_SET_RUNNING
 
 /* VHOST_VDPA specific defines */
 
-- 
1.9.3

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization