Skip to content
Snippets Groups Projects
Select Git revision
  • feature/libtcg-rebase default protected
1 result
Search by author
  • Any Author
  • Anton Anton anjo
1 author
  1. Jun 25, 2021
  3. Mar 11, 2020
  5. Jun 12, 2019
  7. Jun 02, 2017
  9. Jan 31, 2017
  11. Feb 26, 2015
  13. Feb 25, 2014
  15. Feb 01, 2013
    • Jason Wang's avatar
      tap: multiqueue support · 264986e2
      Jason Wang authored 
      
Recently, linux support multiqueue tap which could let userspace call TUNSETIFF
for a signle device many times to create multiple file descriptors as
independent queues. User could also enable/disabe a specific queue through
TUNSETQUEUE.

The patch adds the generic infrastructure to create multiqueue taps. To achieve
this a new parameter "queues" were introduced to specify how many queues were
expected to be created for tap by qemu itself. Alternatively, management could
also pass multiple pre-created tap file descriptors separated with ':' through a
new parameter fds like -netdev tap,id=hn0,fds="X:Y:..:Z". Multiple vhost file
descriptors could also be passed in this way.

Each TAPState were still associated to a tap fd, which mean multiple TAPStates
were created when user needs multiqueue taps. Since each TAPState contains one
NetClientState, with the multiqueue nic support, an N peers of NetClientState
were built up.

A new parameter, mq_required were introduce in tap_open() to create multiqueue
tap fds.

Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      264986e2
    • Jason Wang's avatar
      tap: introduce a helper to get the name of an interface · e5dc0b40
      Jason Wang authored 
      
This patch introduces a helper tap_get_ifname() to get the device name of tap
device. This is needed when ifname is unspecified in the command line and qemu
were asked to create tap device by itself. In this situation, the name were
allocated by kernel, so if multiqueue is asked, we need to fetch its name after
creating the first queue.

Only linux has this support since it's the only platform that supports
multiqueue tap.

Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      e5dc0b40
    • Jason Wang's avatar
      tap: support enabling or disabling a queue · 16dbaf90
      Jason Wang authored 
      
This patch introduce a new bit - enabled in TAPState which tracks whether a
specific queue/fd is enabled. The tap/fd is enabled during initialization and
could be enabled/disabled by tap_enalbe() and tap_disable() which calls platform
specific helpers to do the real work. Polling of a tap fd can only done when
the tap was enabled.

Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      16dbaf90
    • Jason Wang's avatar
      net: tap: using bool instead of bitfield · ec45f083
      Jason Wang authored 
      
Signed-off-by: default avatarJason Wang <jasowang@redhat.com>
Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      ec45f083
  17. Dec 19, 2012
    • Paolo Bonzini's avatar
      net: reorganize headers · 1422e32d
      Paolo Bonzini authored 
      
Move public headers to include/net, and leave private headers in net/.
Put the virtio headers in include/net/tap.h, removing the multiple copies
that existed.  Leave include/net/tap.h as the interface for NICs, and
net/tap_int.h as the interface for OS-specific parts of the tap backend.

Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      1422e32d
  19. Oct 08, 2012
    • Paolo Bonzini's avatar
      net: consolidate NetClientState header files into one · a245fc18
      Paolo Bonzini authored 
      
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: default avatarPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: default avatarStefan Hajnoczi <stefanha@gmail.com>
      a245fc18
  21. Aug 01, 2012
  23. Jul 23, 2012
    • Laszlo Ersek's avatar
      remove unused QemuOpts parameter from net init functions · 1a0c0958
      Laszlo Ersek authored 
      
v1->v2:
- unchanged

v2->v3:
- keep "qemu-option.h" included in "net/slirp.h"

Signed-off-by: default avatarLaszlo Ersek <lersek@redhat.com>
Signed-off-by: default avatarStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
      1a0c0958
    • Laszlo Ersek's avatar
      convert net_init_tap() to NetClientOptions · 08c573a8
      Laszlo Ersek authored 
      
Signed-off-by: default avatarLaszlo Ersek <lersek@redhat.com>
Signed-off-by: default avatarStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
      08c573a8
    • Laszlo Ersek's avatar
      convert net_client_init() to OptsVisitor · 6687b79d
      Laszlo Ersek authored 
      
The net_client_init() prototype is kept intact.

Based on "is_netdev", the QemuOpts-rooted QemuOpt-list is parsed as a
Netdev or a NetLegacy. The original meat of net_client_init() is moved to
and simplified in net_client_init1():

Fields not common between -net and -netdev are clearly separated. Getting
the name for the init functions is cleaner: Netdev::id is mandatory, and
all init functions handle a NULL NetLegacy::name. NetLegacy::vlan
explicitly depends on -net (see below).

Verifying the "type=" option for -netdev can be turned into a switch.

Format validation with qemu_opts_validate() can be removed because the
visitor covers it. Relatedly, the "net_client_types" array is reduced to
an array of init functions that can be directly indexed by opts->kind.
(Help text is available in the schema JSON.)

The outermost negation in the condition around qemu_find_vlan() was
flattened, because it expresses the dependent code's requirements more
clearly.

VLAN lookup is avoided if there's no init function to pass the VLAN to.

Whenever the value of type=... is needed, we substitute
NetClientOptionsKind_lookup[kind].

The individual init functions are not converted yet, thus the original
QemuOpts instance is passed transparently.

v1->v2:
- NetLegacy::name is optional. Tracked it through all init functions: they
  all handle a NULL name. Updated commit message accordingly.

v2->v3:
- NetLegacy::id is allowed and takes precedence over NetLegacy::name.

Signed-off-by: default avatarLaszlo Ersek <lersek@redhat.com>
Signed-off-by: default avatarStefan Hajnoczi <stefanha@linux.vnet.ibm.com>
      6687b79d
  25. Jun 04, 2012
  27. Feb 01, 2012
    • Corey Bryant's avatar
      Add support for net bridge · a7c36ee4
      Corey Bryant authored 
      
The most common use of -net tap is to connect a tap device to a bridge.  This
requires the use of a script and running qemu as root in order to allocate a
tap device to pass to the script.

This model is great for portability and flexibility but it's incredibly
difficult to eliminate the need to run qemu as root.  The only really viable
mechanism is to use tunctl to create a tap device, attach it to a bridge as
root, and then hand that tap device to qemu.  The problem with this mechanism
is that it requires administrator intervention whenever a user wants to create
a guest.

By essentially writing a helper that implements the most common qemu-ifup
script that can be safely given cap_net_admin, we can dramatically simplify
things for non-privileged users.  We still support existing -net tap options
as a mechanism for advanced users and backwards compatibility.

Currently, this is very Linux centric but there's really no reason why it
couldn't be extended for other Unixes.

A typical invocation would be similar to one of the following:

  qemu linux.img -net bridge -net nic,model=virtio

  qemu linux.img -net tap,helper="/usr/local/libexec/qemu-bridge-helper"
                 -net nic,model=virtio

  qemu linux.img -netdev bridge,id=hn0
                 -device virtio-net-pci,netdev=hn0,id=nic1

  qemu linux.img -netdev tap,helper="/usr/local/libexec/qemu-bridge-helper",id=hn0
                 -device virtio-net-pci,netdev=hn0,id=nic1

The default bridge that we attach to is br0.  The thinking is that a distro
could preconfigure such an interface to allow out-of-the-box bridged networking.

Alternatively, if a user wants to use a different bridge, a typical invocation
would be simliar to one of the following:

  qemu linux.img -net bridge,br=qemubr0 -net nic,model=virtio

  qemu linux.img -net tap,helper="/usr/local/libexec/qemu-bridge-helper --br=qemubr0"
                 -net nic,model=virtio

  qemu linux.img -netdev bridge,br=qemubr0,id=hn0
                 -device virtio-net-pci,netdev=hn0,id=nic1

  qemu linux.img -netdev tap,helper="/usr/local/libexec/qemu-bridge-helper --br=qemubr0",id=hn0
                 -device virtio-net-pci,netdev=hn0,id=nic1

Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
Signed-off-by: default avatarRicha Marwaha <rmarwah@linux.vnet.ibm.com>
Signed-off-by: default avatarCorey Bryant <coreyb@linux.vnet.ibm.com>
Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      a7c36ee4
  29. Sep 07, 2010
  31. Apr 01, 2010
  33. Oct 30, 2009
  35. May 18, 2009
  37. Mar 03, 2009
  39. Apr 08, 2008
  41. Feb 01, 2008
  43. Oct 07, 2007
  45. Sep 16, 2007