similar to: [PATCH] virtio_net: don't require ANY_LAYOUT with VERSION_1

From: "Michael S. Tsirkin" <mst at redhat.com> Date: Wed, 15 Jul 2015 15:26:19 +0300 > ANY_LAYOUT is a compatibility feature. It's implied > for VERSION_1 devices, and non-transitional devices > might not offer it. Change code to behave accordingly. > > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> Applied.

"Michael S. Tsirkin" <mst at redhat.com> writes: > On Thu, Jul 04, 2013 at 10:49:42AM +0300, Michael S. Tsirkin wrote: >> > case). >> > >> > Regrettably, initial driver implementations used simple layouts >> > and devices came to rely on it, despite this specification >> > wording. It is thus recommended that drivers be conservative

"Michael S. Tsirkin" <mst at redhat.com> writes: > On Thu, Jul 04, 2013 at 10:49:42AM +0300, Michael S. Tsirkin wrote: >> > case). >> > >> > Regrettably, initial driver implementations used simple layouts >> > and devices came to rely on it, despite this specification >> > wording. It is thus recommended that drivers be conservative

On Tue, Jul 02, 2013 at 03:34:09PM +0930, Rusty Russell wrote: > Paolo Bonzini <pbonzini at redhat.com> writes: > > Il 01/07/2013 01:47, Rusty Russell ha scritto: > >> > > > >> > > Mainly because I'm not sure that *all* devices are now safe. Are they? > >> > > >> > virtio-scsi's implementation in QEMU is not safe (been

On Tue, Jul 02, 2013 at 03:34:09PM +0930, Rusty Russell wrote: > Paolo Bonzini <pbonzini at redhat.com> writes: > > Il 01/07/2013 01:47, Rusty Russell ha scritto: > >> > > > >> > > Mainly because I'm not sure that *all* devices are now safe. Are they? > >> > > >> > virtio-scsi's implementation in QEMU is not safe (been

This feature bit is duplicated with VIRTIO_F_ANY_LAYOUT, this means if a userpsace want to enable VRITIO_F_ANY_LAYOUT, VHOST_NET_F_VIRTIO_NET_HDR will be implied too. This is wrong and will break networking. Fixing this by safely removing VHOST_NET_F_VIRTIO_NET_HDR support. There should be very few or even no userspace can use this. Further cleanups could be done for -net-next for safety. In the

This feature bit is duplicated with VIRTIO_F_ANY_LAYOUT, this means if a userpsace want to enable VRITIO_F_ANY_LAYOUT, VHOST_NET_F_VIRTIO_NET_HDR will be implied too. This is wrong and will break networking. Fixing this by safely removing VHOST_NET_F_VIRTIO_NET_HDR support. There should be very few or even no userspace can use this. Further cleanups could be done for -net-next for safety. In the

On 2018?06?08? 12:46, Michael S. Tsirkin wrote: > On Fri, Jun 08, 2018 at 11:50:42AM +0800, Jason Wang wrote: >> This feature bit is duplicated with VIRTIO_F_ANY_LAYOUT, this means if >> a userpsace want to enable VRITIO_F_ANY_LAYOUT, >> VHOST_NET_F_VIRTIO_NET_HDR will be implied too. This is wrong and will >> break networking. > What breaks networking exactly?

On 2018?06?08? 12:46, Michael S. Tsirkin wrote: > On Fri, Jun 08, 2018 at 11:50:42AM +0800, Jason Wang wrote: >> This feature bit is duplicated with VIRTIO_F_ANY_LAYOUT, this means if >> a userpsace want to enable VRITIO_F_ANY_LAYOUT, >> VHOST_NET_F_VIRTIO_NET_HDR will be implied too. This is wrong and will >> break networking. > What breaks networking exactly?

On Thu, Dec 11, 2014 at 02:25:21PM +0100, Cornelia Huck wrote: > Wire up virtio-blk to provide different feature bit sets depending > on whether legacy or v1.0 has been requested. > > Note that VERSION_1 is still disabled due to missing ANY_LAYOUT support. > > Signed-off-by: Cornelia Huck <cornelia.huck at de.ibm.com> So we need some way for devices to tell transports

On Thu, Dec 11, 2014 at 02:25:21PM +0100, Cornelia Huck wrote: > Wire up virtio-blk to provide different feature bit sets depending > on whether legacy or v1.0 has been requested. > > Note that VERSION_1 is still disabled due to missing ANY_LAYOUT support. > > Signed-off-by: Cornelia Huck <cornelia.huck at de.ibm.com> So we need some way for devices to tell transports

On 2018?06?11? 10:12, Michael S. Tsirkin wrote: > On Fri, Jun 08, 2018 at 01:07:09PM +0800, Jason Wang wrote: >> >> On 2018?06?08? 12:46, Michael S. Tsirkin wrote: >>> On Fri, Jun 08, 2018 at 11:50:42AM +0800, Jason Wang wrote: >>>> This feature bit is duplicated with VIRTIO_F_ANY_LAYOUT, this means if >>>> a userpsace want to enable

This adds a flag to enable/disable bypassing the IOMMU by virtio devices. This is on top of patch http://article.gmane.org/gmane.comp.emulators.qemu/403467 virtio: convert to use DMA api Tested with patchset http://article.gmane.org/gmane.linux.kernel.virtualization/27545 virtio-pci: iommu support (note: bit number has been kept at 34 intentionally to match posted guest code. a non-RFC version

This adds a flag to enable/disable bypassing the IOMMU by virtio devices. This is on top of patch http://article.gmane.org/gmane.comp.emulators.qemu/403467 virtio: convert to use DMA api Tested with patchset http://article.gmane.org/gmane.linux.kernel.virtualization/27545 virtio-pci: iommu support (note: bit number has been kept at 34 intentionally to match posted guest code. a non-RFC version

For small packets we can simplify xmit processing by linearizing buffers with the header: most packets seem to have enough head room we can use for this purpose. Since existing hypervisors require that header is the first s/g element, we need a feature bit for this. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Note: this needs to be applied on top of patch defining

For small packets we can simplify xmit processing by linearizing buffers with the header: most packets seem to have enough head room we can use for this purpose. Since existing hypervisors require that header is the first s/g element, we need a feature bit for this. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- Note: this needs to be applied on top of patch defining

On Thu, Jun 02, 2016 at 11:43:31AM -0400, Aaron Conole wrote: > This patch checks the feature bit for the VIRTIO_NET_F_MTU feature. If it > exists, read the advised MTU and use it. > > No proper error handling is provided for the case where a user changes the > negotiated MTU. A future commit will add proper error handling. Instead, a > warning is emitted if the guest changes

On Thu, Jun 02, 2016 at 11:43:31AM -0400, Aaron Conole wrote: > This patch checks the feature bit for the VIRTIO_NET_F_MTU feature. If it > exists, read the advised MTU and use it. > > No proper error handling is provided for the case where a user changes the > negotiated MTU. A future commit will add proper error handling. Instead, a > warning is emitted if the guest changes

With VERSION_1 virtio_net uses same header size whether mergeable buffers are enabled or not. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/net/virtio_net.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index 098f443..a0e64cf 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c

With VERSION_1 virtio_net uses same header size whether mergeable buffers are enabled or not. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> Reviewed-by: Cornelia Huck <cornelia.huck at de.ibm.com> --- drivers/net/virtio_net.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index 098f443..a0e64cf 100644