similar to: [PATCH v2 net 3/3] virtio_net: sparse annotation fix

Programming vids (adding or removing them) still passes guest-endian values in the DMA buffer. That's wrong if guest is big-endian and when virtio 1 is enabled. Note: this is on top of a previous patch: virtio_net: split out ctrl buffer Fixes: 9465a7a6f ("virtio_net: enable v1.0 support") Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/net/virtio_net.c | 6

Programming vids (adding or removing them) still passes guest-endian values in the DMA buffer. That's wrong if guest is big-endian and when virtio 1 is enabled. Note: this is on top of a previous patch: virtio_net: split out ctrl buffer Fixes: 9465a7a6f ("virtio_net: enable v1.0 support") Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/net/virtio_net.c | 6

When sending control commands, virtio net sets up several buffers for DMA. The buffers are all part of the net device which means it's actually allocated by kvmalloc so it's in theory (on extreme memory pressure) possible to get a vmalloc'ed buffer which on some platforms means we can't DMA there. Fix up by moving the DMA buffers into a separate structure. Reported-by: Mikulas

When sending control commands, virtio net sets up several buffers for DMA. The buffers are all part of the net device which means it's actually allocated by kvmalloc so in theory (on extreme memory pressure) it's possible to get a vmalloc'ed buffer which on some platforms means we can't DMA there. Fix up by moving the DMA buffers out into a separate structure. Reported-by:

On Mon, Jun 05, 2023 at 12:59:25PM -0700, Brett Creeley wrote: > Commit 699b045a8e43 ("net: virtio_net: notifications coalescing > support") added coalescing command support for virtio_net. However, > the coalesce commands are using buffers on the stack, which is causing > the device to see DMA errors. There should also be a complaint from > check_for_stack() in

From: Andy Lutomirski <luto at amacapital.net> Once virtio starts using the DMA API, we won't be able to safely DMA from the stack. virtio-net does a couple of config DMA requests from small stack buffers -- switch to using dynamically-allocated memory. This should have no effect on any performance-critical code paths. Cc: netdev at vger.kernel.org Cc: "Michael S. Tsirkin"

From: Andy Lutomirski <luto at amacapital.net> Once virtio starts using the DMA API, we won't be able to safely DMA from the stack. virtio-net does a couple of config DMA requests from small stack buffers -- switch to using dynamically-allocated memory. This should have no effect on any performance-critical code paths. Cc: netdev at vger.kernel.org Cc: "Michael S. Tsirkin"

On Mon, Oct 16, 2017 at 11:31 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > On Mon, Oct 16, 2017 at 11:03:18AM -0400, Willem de Bruijn wrote: >> >> +static int virtnet_reset(struct virtnet_info *vi) >> >> +{ >> >> + struct virtio_device *dev = vi->vdev; >> >> + int ret; >> >> + >> >> +

On Mon, Oct 16, 2017 at 11:31 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > On Mon, Oct 16, 2017 at 11:03:18AM -0400, Willem de Bruijn wrote: >> >> +static int virtnet_reset(struct virtnet_info *vi) >> >> +{ >> >> + struct virtio_device *dev = vi->vdev; >> >> + int ret; >> >> + >> >> +

On Mon, Oct 16, 2017 at 12:38 PM, Michael S. Tsirkin <mst at redhat.com> wrote: > On Mon, Oct 16, 2017 at 12:04:57PM -0400, Willem de Bruijn wrote: >> On Mon, Oct 16, 2017 at 11:31 AM, Michael S. Tsirkin <mst at redhat.com> wrote: >> > On Mon, Oct 16, 2017 at 11:03:18AM -0400, Willem de Bruijn wrote: >> >> >> +static int virtnet_reset(struct

On Mon, Oct 16, 2017 at 12:38 PM, Michael S. Tsirkin <mst at redhat.com> wrote: > On Mon, Oct 16, 2017 at 12:04:57PM -0400, Willem de Bruijn wrote: >> On Mon, Oct 16, 2017 at 11:31 AM, Michael S. Tsirkin <mst at redhat.com> wrote: >> > On Mon, Oct 16, 2017 at 11:03:18AM -0400, Willem de Bruijn wrote: >> >> >> +static int virtnet_reset(struct

On Tue, Oct 17, 2017 at 11:05:07AM +0800, Jason Wang wrote: > > > On 2017?10?17? 06:34, Willem de Bruijn wrote: > > On Mon, Oct 16, 2017 at 12:38 PM, Michael S. Tsirkin <mst at redhat.com> wrote: > > > On Mon, Oct 16, 2017 at 12:04:57PM -0400, Willem de Bruijn wrote: > > > > On Mon, Oct 16, 2017 at 11:31 AM, Michael S. Tsirkin <mst at redhat.com>

This patch convert rx mode setting to be done in a workqueue, this is a must for allow to sleep when waiting for the cvq command to response since current code is executed under addr spin lock. Signed-off-by: Jason Wang <jasowang at redhat.com> --- Changes since V1: - use RTNL to synchronize rx mode worker --- drivers/net/virtio_net.c | 55 +++++++++++++++++++++++++++++++++++++--- 1 file

>> +static int virtnet_reset(struct virtnet_info *vi) >> +{ >> + struct virtio_device *dev = vi->vdev; >> + int ret; >> + >> + virtio_config_disable(dev); >> + dev->failed = dev->config->get_status(dev) & VIRTIO_CONFIG_S_FAILED; >> + virtnet_freeze_down(dev, true); >> + remove_vq_common(vi); >> +

>> +static int virtnet_reset(struct virtnet_info *vi) >> +{ >> + struct virtio_device *dev = vi->vdev; >> + int ret; >> + >> + virtio_config_disable(dev); >> + dev->failed = dev->config->get_status(dev) & VIRTIO_CONFIG_S_FAILED; >> + virtnet_freeze_down(dev, true); >> + remove_vq_common(vi); >> +

On Fri, Apr 14, 2023 at 3:21?PM Michael S. Tsirkin <mst at redhat.com> wrote: > > On Fri, Apr 14, 2023 at 01:04:15PM +0800, Jason Wang wrote: > > Forget to cc netdev, adding. > > > > On Fri, Apr 14, 2023 at 12:25?AM Michael S. Tsirkin <mst at redhat.com> wrote: > > > > > > On Thu, Apr 13, 2023 at 02:40:26PM +0800, Jason Wang wrote: > >

Hi Laine, Thanks for taking the time to respond to my question. I think I have not described my problem clearly. Let me explain my issue below with the information that you had requested. My assumption according to the information you gave me is that the admin MAC and VF MAC are the same in my case. I see a PF (GE0-0) interface but I don’t see a vfnetdev interface as you mentioned in your

Hi, Whilst doing some QA work on XORP on my desktop, which has fxp0 and msk0, fxp0 got totally hosed. I was running PIM-SM and IGMPv2 router-mode on the box at the time. I wonder if this is related to the problems with fxp multicast transmission I saw back in April. I'm a bit concerned about this as fxp is still a very widespread and useful network chip. I am running

Hi Laine, Yes we are setting the names as GE0-0 manually. We have turned trust ON for host IGB driver. [root@nfvis libvirt]# ip link show GE0-0 3: GE0-0: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 9216<tel:9216> qdisc mq master ovs-system state UP mode DEFAULT qlen 1000<tel:1000> link/ether a0:23:9f:ce:b1:f8 brd ff:ff:ff:ff:ff:ff vf 0 MAC 52:54:00:29:3c:be, spoof checking

On Tue, Oct 27, 2015 at 10:30:19PM -0700, Andy Lutomirski wrote: > From: Andy Lutomirski <luto at amacapital.net> > > Once virtio starts using the DMA API, we won't be able to safely DMA > from the stack. virtio-net does a couple of config DMA requests > from small stack buffers -- switch to using dynamically-allocated > memory. > > This should have no effect