Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu
切换分支/标签
  1. 27 5月, 2015 2 次提交
    • M
      net: Permit incremental conversion of init functions to Error · a30ecde6
      由 Markus Armbruster 提交于 
      Error reporting for netdev_add is broken: the net_client_init_fun[]
report the actual errors with (at best) error_report(), and their
caller net_client_init1() makes up a generic error on top.

For command line and HMP, this produces an mildly ugly error cascade.

In QMP, the actual errors go to stderr, and the generic error becomes
the command's error reply.

To fix this, we need to convert the net_client_init_fun[] to Error.

To permit fixing them one by one, add an Error ** parameter to the
net_client_init_fun[].  If the call fails without returning an Error,
make up the same generic Error as before.  But if it returns one, use
that instead.  Since none of them does so far, no functional change.
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Message-id: 1431691143-1015-3-git-send-email-armbru@redhat.com
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      a30ecde6
    • M
      net: Improve error message for -net hubport a bit · ca7eb184
      由 Markus Armbruster 提交于 
      Type "hubport" is valid only with -netdev.  Unfortunately, that's
detected late and the error message doesn't explain why:

    $ qemu-system-i386 -net hubport,id=foo,hubid=0
    qemu-system-i386: -net hubport,id=foo,hubid=0: Device 'hubport' could not be initialized

Improve the error message to "Parameter 'type' expects a net type".

Not fixed: -net hubport without the parameters required by -netdev
hubport still asks for those parameters:

    $ qemu-system-i386 -net hubport
    qemu-system-i386: -net hubport: Parameter 'hubid' is missing
Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
Reviewed-by: NEric Blake <eblake@redhat.com>
Message-id: 1431691143-1015-2-git-send-email-armbru@redhat.com
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      ca7eb184
  3. 06 2月, 2015 2 次提交
  5. 19 6月, 2014 1 次提交
  7. 06 9月, 2013 1 次提交
  9. 27 2月, 2013 1 次提交
    • L
      net: fix qemu_flush_queued_packets() in presence of a hub · 199ee608
      由 Luigi Rizzo 提交于 
      When frontend and backend are connected through a hub as below
(showing only one direction), and the frontend (or in general, all
output ports of the hub) cannot accept more traffic, the backend
queues packets in queue-A.

When the frontend (or in general, one output port) becomes ready again,
quemu tries to flush packets from queue-B, which is unfortunately empty.

  e1000.0 <--[queue B]-- hub0port0(hub)hub0port1 <--[queue A]-- tap.0

To fix this i propose to introduce a new function net_hub_flush()
which is called when trying to flush a queue connected to a hub.
Signed-off-by: NLuigi Rizzo <rizzo@iet.unipi.it>
Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      199ee608
  11. 19 12月, 2012 3 次提交
  13. 18 12月, 2012 1 次提交
  15. 08 10月, 2012 1 次提交
    • P
      net: consolidate NetClientState header files into one · a245fc18
      由 Paolo Bonzini 提交于 
      This patch doesn't seem much useful alone, I must admit.  However,
it makes sense as part of the upcoming directory reorganization,
where I want to have include/net/tap.h as the net<->hw interface
for tap.  Then having both net/tap.h and include/net/tap.h does
not work.  "Fixed" by moving all the init functions to a single
header file net/clients.h.

The patch also adopts a uniform style for including net/*.h files
from net/*.c, without the net/ path.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NStefan Hajnoczi <stefanha@gmail.com>
      a245fc18
  17. 14 9月, 2012 1 次提交
    • 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
  19. 01 8月, 2012 9 次提交