search for: virtio_id_rpmsg

...ivers/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

...> 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?"...

...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 > > &gt...

...ter_virtio_driver(&virtio_rproc_serial); class_destroy(pdrvdata.class); if (pdrvdata.debugfs_dir) diff --git a/include/linux/virtio_ids.h b/include/linux/virtio_ids.h index 270fb22..07cf6f7 100644 --- a/include/linux/virtio_ids.h +++ b/include/linux/virtio_ids.h @@ -37,5 +37,6 @@ #define VIRTIO_ID_RPMSG 7 /* virtio remote processor messaging */ #define VIRTIO_ID_SCSI 8 /* virtio scsi */ #define VIRTIO_ID_9P 9 /* 9p virtio console */ +#define VIRTIO_ID_RPROC_SERIAL 0xB /* virtio remoteproc serial link */ #endif /* _LINUX_VIRTIO_IDS_H */ -- 1.7.9.5

...ter_virtio_driver(&virtio_rproc_serial); class_destroy(pdrvdata.class); if (pdrvdata.debugfs_dir) diff --git a/include/linux/virtio_ids.h b/include/linux/virtio_ids.h index 270fb22..07cf6f7 100644 --- a/include/linux/virtio_ids.h +++ b/include/linux/virtio_ids.h @@ -37,5 +37,6 @@ #define VIRTIO_ID_RPMSG 7 /* virtio remote processor messaging */ #define VIRTIO_ID_SCSI 8 /* virtio scsi */ #define VIRTIO_ID_9P 9 /* 9p virtio console */ +#define VIRTIO_ID_RPROC_SERIAL 0xB /* virtio remoteproc serial link */ #endif /* _LINUX_VIRTIO_IDS_H */ -- 1.7.9.5

...> > + 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_rpms...

Hi Rusty, These are a few fixes for the virtio-rng driver. These were tested using the not-yet-upstream virtio-rng device patch to qemu: http://thread.gmane.org/gmane.comp.emulators.qemu/152668 Please apply. Amit Shah (5): virtio ids: fix comment for virtio-rng virtio: rng: allow tasks to be killed that are waiting for rng input virtio: rng: don't wait on host when module is going

Hi Rusty, These are a few fixes for the virtio-rng driver. These were tested using the not-yet-upstream virtio-rng device patch to qemu: http://thread.gmane.org/gmane.comp.emulators.qemu/152668 Please apply. Amit Shah (5): virtio ids: fix comment for virtio-rng virtio: rng: allow tasks to be killed that are waiting for rng input virtio: rng: don't wait on host when module is going

...ter_virtio_driver(&virtio_rproc_serial); class_destroy(pdrvdata.class); if (pdrvdata.debugfs_dir) diff --git a/include/linux/virtio_ids.h b/include/linux/virtio_ids.h index 270fb22..07cf6f7 100644 --- a/include/linux/virtio_ids.h +++ b/include/linux/virtio_ids.h @@ -37,5 +37,6 @@ #define VIRTIO_ID_RPMSG 7 /* virtio remote processor messaging */ #define VIRTIO_ID_SCSI 8 /* virtio scsi */ #define VIRTIO_ID_9P 9 /* 9p virtio console */ +#define VIRTIO_ID_RPROC_SERIAL 0xB /* virtio remoteproc serial link */ #endif /* _LINUX_VIRTIO_IDS_H */ -- 1.7.5.4

...ter_virtio_driver(&virtio_rproc_serial); class_destroy(pdrvdata.class); if (pdrvdata.debugfs_dir) diff --git a/include/linux/virtio_ids.h b/include/linux/virtio_ids.h index 270fb22..07cf6f7 100644 --- a/include/linux/virtio_ids.h +++ b/include/linux/virtio_ids.h @@ -37,5 +37,6 @@ #define VIRTIO_ID_RPMSG 7 /* virtio remote processor messaging */ #define VIRTIO_ID_SCSI 8 /* virtio scsi */ #define VIRTIO_ID_9P 9 /* 9p virtio console */ +#define VIRTIO_ID_RPROC_SERIAL 0xB /* virtio remoteproc serial link */ #endif /* _LINUX_VIRTIO_IDS_H */ -- 1.7.5.4

Linux supports RPMsg over VirtIO for "remote processor" /AMP use cases. It can however also be used for virtualisation scenarios, e.g. when using KVM to run Linux on both the host and the guests. This patch set adds a wrapper API to facilitate writing vhost drivers for such RPMsg-based solutions. The first use case is an audio DSP virtualisation project, currently under development,

Linux supports RPMsg over VirtIO for "remote processor" /AMP use cases. It can however also be used for virtualisation scenarios, e.g. when using KVM to run Linux on both the host and the guests. This patch set adds a wrapper API to facilitate writing vhost drivers for such RPMsg-based solutions. The first use case is an audio DSP virtualisation project, currently under development,

...ter_virtio_driver(&virtio_rproc_serial); class_destroy(pdrvdata.class); if (pdrvdata.debugfs_dir) diff --git a/include/linux/virtio_ids.h b/include/linux/virtio_ids.h index 270fb22..cb28b52 100644 --- a/include/linux/virtio_ids.h +++ b/include/linux/virtio_ids.h @@ -37,5 +37,6 @@ #define VIRTIO_ID_RPMSG 7 /* virtio remote processor messaging */ #define VIRTIO_ID_SCSI 8 /* virtio scsi */ #define VIRTIO_ID_9P 9 /* 9p virtio console */ +#define VIRTIO_ID_RPROC_SERIAL 11 /* virtio remoteproc serial link */ #endif /* _LINUX_VIRTIO_IDS_H */ -- 1.7.5.4

...ter_virtio_driver(&virtio_rproc_serial); class_destroy(pdrvdata.class); if (pdrvdata.debugfs_dir) diff --git a/include/linux/virtio_ids.h b/include/linux/virtio_ids.h index 270fb22..cb28b52 100644 --- a/include/linux/virtio_ids.h +++ b/include/linux/virtio_ids.h @@ -37,5 +37,6 @@ #define VIRTIO_ID_RPMSG 7 /* virtio remote processor messaging */ #define VIRTIO_ID_SCSI 8 /* virtio scsi */ #define VIRTIO_ID_9P 9 /* 9p virtio console */ +#define VIRTIO_ID_RPROC_SERIAL 11 /* virtio remoteproc serial link */ #endif /* _LINUX_VIRTIO_IDS_H */ -- 1.7.5.4

...er 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,...

...+ __le32 need_stats; +#endif }; #define VIRTIO_BALLOON_S_SWAP_IN 0 /* Amount of memory swapped in */ diff --git a/include/linux/virtio_ids.h b/include/linux/virtio_ids.h index 7529b85..2f081d7 100644 --- a/include/linux/virtio_ids.h +++ b/include/linux/virtio_ids.h @@ -37,5 +37,6 @@ #define VIRTIO_ID_RPMSG 7 /* virtio remote processor messaging */ #define VIRTIO_ID_SCSI 8 /* virtio scsi */ #define VIRTIO_ID_9P 9 /* 9p virtio console */ +#define VIRTIO_ID_FILE_BALLOON 10 /* virtio file-backed balloon */ #endif /* _LINUX_VIRTIO_IDS_H */ -- 1.7.7.3

...+ __le32 need_stats; +#endif }; #define VIRTIO_BALLOON_S_SWAP_IN 0 /* Amount of memory swapped in */ diff --git a/include/linux/virtio_ids.h b/include/linux/virtio_ids.h index 7529b85..2f081d7 100644 --- a/include/linux/virtio_ids.h +++ b/include/linux/virtio_ids.h @@ -37,5 +37,6 @@ #define VIRTIO_ID_RPMSG 7 /* virtio remote processor messaging */ #define VIRTIO_ID_SCSI 8 /* virtio scsi */ #define VIRTIO_ID_9P 9 /* 9p virtio console */ +#define VIRTIO_ID_FILE_BALLOON 10 /* virtio file-backed balloon */ #endif /* _LINUX_VIRTIO_IDS_H */ -- 1.7.7.3

This patch-set introduces a new virtio type "rproc_serial" for communicating with remote processors over shared memory. The driver depends on the the remoteproc framework. As preparation for introducing "rproc_serial" I've done a refactoring of the transmit buffer handling. NOTE: These two patches are identical to first two patches of the V8 patch-set, but are rebased to

This patch-set introduces a new virtio type "rproc_serial" for communicating with remote processors over shared memory. The driver depends on the the remoteproc framework. As preparation for introducing "rproc_serial" I've done a refactoring of the transmit buffer handling. NOTE: These two patches are identical to first two patches of the V8 patch-set, but are rebased to

As it was discussed recently, there's currently no way for the guest to notify the host about panics. Further more, there's no reasonable way to notify the host of other critical events such as an OOM kill. This short patch series introduces a new device named virtio-notifier which does two simple things: 1. Provide a simple interface for the guest to notify the host of critical