1. 14 9月, 2012 11 次提交
    • S
      net: asynchronous send/receive infrastructure for net/socket.c · 863f678f
      Stefan Hajnoczi 提交于
      The net/socket.c net client is not truly asynchronous.  This patch
      borrows the qemu_set_fd_handler2() code from net/tap.c as the basis for
      proper asynchronous send/receive.
      
      Only read packets from the socket when the peer is able to receive.
      This avoids needless queuing.
      
      Later patches implement asynchronous send.
      Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
      863f678f
    • S
      net: broadcast hub packets if at least one port can receive · 61518a74
      Stefan Hajnoczi 提交于
      In commit 60c07d93 ("net: fix
      qemu_can_send_packet logic") the "VLAN" broadcast behavior was changed
      to queue packets if any net client cannot receive.  It turns out that
      this was not actually the right fix and just hides the real bug that
      hw/usb/dev-network.c:usbnet_receive() clobbers its receive buffer when
      called multiple times in a row.  The commit also introduced a new bug
      that "VLAN" packets would not be sent if one of multiple net clients was
      down.
      
      The hw/usb/dev-network.c bug has since been fixed, so this patch reverts
      broadcast behavior to send packets as long as one net client can
      receive.  Packets simply get queued for the net clients that are
      temporarily unable to receive.
      Reported-by: NRoy.Li <rongqing.li@windriver.com>
      Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
      61518a74
    • S
      net: fix usbnet_receive() packet drops · 190563f9
      Stefan Hajnoczi 提交于
      The USB network interface has a single buffer which the guest reads
      from.  This patch prevents multiple calls to usbnet_receive() from
      clobbering the input buffer.  Instead we queue packets until buffer
      space becomes available again.
      
      This is inspired by virtio-net and e1000 rxbuf handling.
      Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
      190563f9
    • S
      net: clean up usbnet_receive() · f237ddbb
      Stefan Hajnoczi 提交于
      The USB network interface has two code paths depending on whether or not
      RNDIS mode is enabled.  Refactor usbnet_receive() so that there is a
      common path throughout the function instead of duplicating everything
      across if (is_rndis(s)) ... else ... code paths.
      
      Clean up coding style and 80 character line wrap along the way.
      Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
      f237ddbb
    • S
      net: add -netdev options to man page · 08d12022
      Stefan Hajnoczi 提交于
      Document the -netdev syntax which supercedes the older -net syntax.
      This patch is a first step to making -netdev prominent in the QEMU
      manual.
      Reported-by: NAnatoly Techtonik <techtonik@gmail.com>
      Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
      08d12022
    • S
      net: do not report queued packets as sent · 06b5f36d
      Stefan Hajnoczi 提交于
      Net send functions have a return value where 0 means the packet has not
      been sent and will be queued.  A non-zero value means the packet was
      sent or an error caused the packet to be dropped.
      
      This patch fixes two instances where packets are queued but we return
      their size.  This causes callers to believe the packets were sent.  When
      the caller uses the async send interface this creates a real problem
      because the callback will be invoked for a packet that the caller
      believed to be already sent.  This bug can cause double-frees in the
      caller.
      Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
      06b5f36d
    • S
      net: add receive_disabled logic to iov delivery path · c67f5dc1
      Stefan Hajnoczi 提交于
      This patch adds the missing NetClient->receive_disabled logic in the
      sendv delivery code path.  It seems that commit
      893379ef ("net: disable receiving if
      client returns zero") only added the logic to qemu_deliver_packet() and
      not qemu_deliver_packet_iov().
      
      The receive_disabled flag should be automatically set when .receive(),
      .receive_raw(), or .receive_iov() return 0.  No further packets will be
      delivered to the NetClient until the receive_disabled flag is cleared
      again by calling qemu_flush_queued_packets().
      
      Typically the NetClient will wait until its file descriptor becomes
      writable and then invoke qemu_flush_queued_packets() to resume
      transmission.
      Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
      c67f5dc1
    • B
      eepro100: Fix network hang when rx buffers run out · 1069985f
      Bo Yang 提交于
      This is reported by QA. When installing os with pxe, after the initial
      kernel and initrd are loaded, the procedure tries to copy files from install
      server to local harddisk, the network becomes stall because of running out of
      receive descriptor.
      
      [Whitespace fixes and removed qemu_notify_event() because Paolo's
      earlier net patches have moved it into qemu_flush_queued_packets().
      
      Additional info:
      
      I can reproduce the network hang with a tap device doing a iPXE HTTP
      boot as follows:
      
        $ qemu -enable-kvm -m 1024 \
          -netdev tap,id=netdev0,script=no,downscript=no \
          -device i82559er,netdev=netdev0,romfile=80861209.rom \
          -drive if=virtio,cache=none,file=test.img
        iPXE> ifopen net0
        iPXE> config # set static network configuration
        iPXE> kernel http://mirror.bytemark.co.uk/fedora/linux/releases/17/Fedora/x86_64/os/images/pxeboot/vmlinuz
      
      I needed a vanilla iPXE ROM to get to the iPXE prompt.  I think the boot
      prompt has been disabled in the ROMs that ship with QEMU to reduce boot
      time.
      
      During the vmlinuz HTTP download there is a network hang.  hw/eepro100.c
      has reached the end of the rx descriptor list.  When the iPXE driver
      replenishes the rx descriptor list we don't kick the QEMU net subsystem
      and event loop, thereby leaving the tap netdev without its file
      descriptor in select(2).
      
      Stefan Hajnoczi <stefanha@gmail.com>]
      Signed-off-by: NBo Yang <boyang@suse.com>
      Signed-off-by: NStefan Hajnoczi <stefanha@gmail.com>
      1069985f
    • P
      xen: flush queue when getting an event · a98b1402
      Paolo Bonzini 提交于
      xen does not have a register that, when written, will cause can_receive
      to go from false to true.  However, flushing the queue can be attempted
      whenever the front-end raises its side of the Xen event channel.  There
      is a single event channel for tx and rx.
      
      Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
      Cc: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Reviewed-by: NAmos Kong <akong@redhat.com>
      Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
      a98b1402
    • P
      e1000: flush queue whenever can_receive can go from false to true · e8b4c680
      Paolo Bonzini 提交于
      When the guests replenish the receive ring buffer, the network device
      should flush its queue of pending packets.  This is done with
      qemu_flush_queued_packets.
      
      e1000's can_receive can go from false to true when RCTL or RDT are
      modified.
      Reported-by: NLuigi Rizzo <rizzo@iet.unipi.it>
      Cc: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
      Cc: Jan Kiszka <jan.kiszka@siemens.de>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Reviewed-by: NAmos Kong <akong@redhat.com>
      Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
      e8b4c680
    • P
      net: notify iothread after flushing queue · 987a9b48
      Paolo Bonzini 提交于
      virtio-net has code to flush the queue and notify the iothread
      whenever new receive buffers are added by the guest.  That is
      fine, and indeed we need to do the same in all other drivers.
      However, notifying the iothread should be work for the network
      subsystem.  And since we are at it we can add a little smartness:
      if some of the queued packets already could not be delivered,
      there is no need to notify the iothread.
      Reported-by: NLuigi Rizzo <rizzo@iet.unipi.it>
      Cc: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
      Cc: Jan Kiszka <jan.kiszka@siemens.de>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      Reviewed-by: NAmos Kong <akong@redhat.com>
      Signed-off-by: NStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
      987a9b48
  2. 12 9月, 2012 10 次提交
  3. 11 9月, 2012 19 次提交