similar to: [PATCH] virtio-spec: add an rpmsg appendix

Displaying 20 results from an estimated 2000 matches similar to: "[PATCH] virtio-spec: add an rpmsg appendix"

2012 Feb 05
1
[PATCH v3] Add virtio-scsi to the virtio spec
Hi Rusty, here is the specification for a virtio-based SCSI host (controller, HBA, you name it) so that you can apply it to the spec document and publish it. I changed the index from 7 to 8 to account for the rpmsg device, and added a feature bit to tell the guest in advance whether the host supports hotplug. Otherwise there is no change from v2. Paolo --- virtio-spec.lyx.saved 2011-11-29
2012 Feb 05
1
[PATCH v3] Add virtio-scsi to the virtio spec
Hi Rusty, here is the specification for a virtio-based SCSI host (controller, HBA, you name it) so that you can apply it to the spec document and publish it. I changed the index from 7 to 8 to account for the rpmsg device, and added a feature bit to tell the guest in advance whether the host supports hotplug. Otherwise there is no change from v2. Paolo --- virtio-spec.lyx.saved 2011-11-29
2011 Dec 05
1
[PATCH v2] Add virtio-scsi to the virtio spec
Hi all, here is the specification for a virtio-based SCSI host (controller, HBA, you name it). The virtio SCSI host is the basis of an alternative storage stack for KVM. This stack would overcome several limitations of the current solution, virtio-blk: 1) scalability limitations: virtio-blk-over-PCI puts a strong upper limit on the number of devices that can be added to a guest. Common
2011 Dec 05
1
[PATCH v2] Add virtio-scsi to the virtio spec
Hi all, here is the specification for a virtio-based SCSI host (controller, HBA, you name it). The virtio SCSI host is the basis of an alternative storage stack for KVM. This stack would overcome several limitations of the current solution, virtio-blk: 1) scalability limitations: virtio-blk-over-PCI puts a strong upper limit on the number of devices that can be added to a guest. Common
2013 May 28
0
[PATCH v2 2/2] virtio-balloon spec: reintroduce "silent deflation" feature
The original idea of the VIRTIO_BALLOON_F_MUST_TELL_HOST feature was to let drivers skip usage of the deflate queue when leaking the balloon ("silent deflation"). Guests may benefit from silent deflate by aggressively inflating the balloon; they know that they will be able to use ballooned pages without issuing a (blocking) request to the device. The previous patch redefined the
2011 Nov 30
2
[PATCH] Add virtio-scsi to the virtio spec
Hi all, here is the specification for a virtio-based SCSI host (controller, HBA, you name it). The virtio SCSI host is the basis of an alternative storage stack for KVM. This stack would overcome several limitations of the current solution, virtio-blk: 1) scalability limitations: virtio-blk-over-PCI puts a strong upper limit on the number of devices that can be added to a guest. Common
2011 Nov 30
2
[PATCH] Add virtio-scsi to the virtio spec
Hi all, here is the specification for a virtio-based SCSI host (controller, HBA, you name it). The virtio SCSI host is the basis of an alternative storage stack for KVM. This stack would overcome several limitations of the current solution, virtio-blk: 1) scalability limitations: virtio-blk-over-PCI puts a strong upper limit on the number of devices that can be added to a guest. Common
2013 May 08
1
[PATCH] virtio-balloon spec: rework VIRTIO_BALLOON_F_MUST_TELL_HOST feature, support silent deflation
The idea of the VIRTIO_BALLOON_F_MUST_TELL_HOST feature is to let drivers skip usage of the deflate queue when leaking the balloon ("silent deflation"). Guests may benefit from silent deflate by aggressively inflating the balloon; they know that they will be able to use ballooned pages without issuing a (blocking) request to the device. The problem is that this feature is a
2013 May 08
1
[PATCH] virtio-balloon spec: rework VIRTIO_BALLOON_F_MUST_TELL_HOST feature, support silent deflation
The idea of the VIRTIO_BALLOON_F_MUST_TELL_HOST feature is to let drivers skip usage of the deflate queue when leaking the balloon ("silent deflation"). Guests may benefit from silent deflate by aggressively inflating the balloon; they know that they will be able to use ballooned pages without issuing a (blocking) request to the device. The problem is that this feature is a
2012 Aug 20
1
[PATCH] virtio-scsi spec: add per-LUN parameter query
Each virtio scsi HBA has global request queue limits. But the passthrough LUNs (scsi-generic) come from different host HBAs may have different request queue limits. If the guest sends commands that exceed the host limits, the commands will be rejected by host HAB. To address this issue, this patch adds a per-LUN parameter query via the control queue, and defines some parameter query types. The
2012 Aug 20
1
[PATCH] virtio-scsi spec: add per-LUN parameter query
Each virtio scsi HBA has global request queue limits. But the passthrough LUNs (scsi-generic) come from different host HBAs may have different request queue limits. If the guest sends commands that exceed the host limits, the commands will be rejected by host HAB. To address this issue, this patch adds a per-LUN parameter query via the control queue, and defines some parameter query types. The
2013 May 29
2
[PATCH v2 2/2] virtio-balloon spec: reintroduce "silent deflation" feature
On Tue, May 28, 2013 at 07:40:18PM +0200, Paolo Bonzini wrote: > The original idea of the VIRTIO_BALLOON_F_MUST_TELL_HOST feature was to > let drivers skip usage of the deflate queue when leaking the balloon > ("silent deflation"). Guests may benefit from silent deflate by > aggressively inflating the balloon; they know that they will be able to > use ballooned pages
2011 May 04
1
[PATCHv2] virtio-spec: 64 bit features, used/avail event
I'm working on a patchset (to follow shortly) that modified the notificatin hand-off in virtio to be basically like Xen: each side published an index, the other side only triggers an event when it crosses that index value (Xen event indexes start at 1, ours start at 0 for backward-compatiblity, but that's minor). Especially for testing, it is very convenient to have separate feature bits
2011 May 04
1
[PATCHv2] virtio-spec: 64 bit features, used/avail event
I'm working on a patchset (to follow shortly) that modified the notificatin hand-off in virtio to be basically like Xen: each side published an index, the other side only triggers an event when it crosses that index value (Xen event indexes start at 1, ours start at 0 for backward-compatiblity, but that's minor). Especially for testing, it is very convenient to have separate feature bits
2011 Jun 01
3
[PATCHv3] virtio-spec: 64 bit features, used/avail event, fixes
Add an option to modify the notificatin hand-off in virtio to be basically like Xen: each side published an index, the other side only triggers an event when it crosses that index value (Xen event indexes start at 1, ours start at 0 for backward-compatiblity, but that's minor). Since we've run out of bits in the 32 bit field, I added another 32 bit and bit 31 enables that. I started with
2011 Jun 01
3
[PATCHv3] virtio-spec: 64 bit features, used/avail event, fixes
Add an option to modify the notificatin hand-off in virtio to be basically like Xen: each side published an index, the other side only triggers an event when it crosses that index value (Xen event indexes start at 1, ours start at 0 for backward-compatiblity, but that's minor). Since we've run out of bits in the 32 bit field, I added another 32 bit and bit 31 enables that. I started with
2012 Sep 06
2
[PATCHv3] virtio-spec: virtio network device multiqueue support
Add multiqueue support to virtio network device. Add a new feature flag VIRTIO_NET_F_MULTIQUEUE for this feature, a new configuration field max_virtqueue_pairs to detect supported number of virtqueues as well as a new command VIRTIO_NET_CTRL_STEERING to program packet steering. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> -- Changes from v2: Address Jason's comments on v2: -
2012 Sep 06
2
[PATCHv3] virtio-spec: virtio network device multiqueue support
Add multiqueue support to virtio network device. Add a new feature flag VIRTIO_NET_F_MULTIQUEUE for this feature, a new configuration field max_virtqueue_pairs to detect supported number of virtqueues as well as a new command VIRTIO_NET_CTRL_STEERING to program packet steering. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> -- Changes from v2: Address Jason's comments on v2: -
2012 Jun 26
0
[rfc] virtio-spec: introduce VIRTIO_NET_F_MULTIQUEUE
This patch introduces the multiqueue capabilities to virtio net devices. The number of tx/rx queue pairs available in the device were exposed through config space, and driver could negotiate the number of pairs it wish to use through ctrl vq. Signed-off-by: Jason Wang <jasowang at redhat.com> --- virtio-0.9.5.lyx | 180 ++++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file
2012 Jun 26
0
[rfc] virtio-spec: introduce VIRTIO_NET_F_MULTIQUEUE
This patch introduces the multiqueue capabilities to virtio net devices. The number of tx/rx queue pairs available in the device were exposed through config space, and driver could negotiate the number of pairs it wish to use through ctrl vq. Signed-off-by: Jason Wang <jasowang at redhat.com> --- virtio-0.9.5.lyx | 180 ++++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file