1. 03 Feb, 2012 16 commits
  2. 01 Feb, 2012 24 commits
    • Stefan Weil's avatar
      Change license from GPLv2 to GPLv2+ · 4c32fe66
      Stefan Weil authored
      This file only contains code from Red Hat, so it can use GPLv2+.
      Tested with `git blame -M -C net/checksum.c`.
      Signed-off-by: default avatarStefan Weil <sw@weilnetz.de>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      4c32fe66
    • 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
    • Corey Bryant's avatar
      Add cap reduction support to enable use as SUID · 47e98658
      Corey Bryant authored
      The ideal way to use qemu-bridge-helper is to give it an fscap of using:
      
       setcap cap_net_admin=ep qemu-bridge-helper
      
      Unfortunately, most distros still do not have a mechanism to package files
      with fscaps applied.  This means they'll have to SUID the qemu-bridge-helper
      binary.
      
      To improve security, use libcap to reduce our capability set to just
      cap_net_admin, then reduce privileges down to the calling user.  This is
      hopefully close to equivalent to fscap support from a security perspective.
      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>
      47e98658
    • Corey Bryant's avatar
      Add access control support to qemu bridge helper · bdef79a2
      Corey Bryant authored
      We go to great lengths to restrict ourselves to just cap_net_admin as an OS
      enforced security mechanism.  However, we further restrict what we allow users
      to do to simply adding a tap device to a bridge interface by virtue of the fact
      that this is the only functionality we expose.
      
      This is not good enough though.  An administrator is likely to want to restrict
      the bridges that an unprivileged user can access, in particular, to restrict
      an unprivileged user from putting a guest on what should be isolated networks.
      
      This patch implements an ACL mechanism that is enforced by qemu-bridge-helper.
      The ACLs are fairly simple whitelist/blacklist mechanisms with a wildcard of
      'all'.  All users are blacklisted by default, and deny takes precedence over
      allow.
      
      An interesting feature of this ACL mechanism is that you can include external
      ACL files.  The main reason to support this is so that you can set different
      file system permissions on those external ACL files.  This allows an
      administrator to implement rather sophisticated ACL policies based on
      user/group policies via the file system.
      
      As an example:
      
      /etc/qemu/bridge.conf root:qemu 0640
      
       allow br0
       include /etc/qemu/alice.conf
       include /etc/qemu/bob.conf
       include /etc/qemu/charlie.conf
      
      /etc/qemu/alice.conf root:alice 0640
       allow br1
      
      /etc/qemu/bob.conf root:bob 0640
       allow br2
      
      /etc/qemu/charlie.conf root:charlie 0640
       deny all
      
      This ACL pattern allows any user in the qemu group to get a tap device
      connected to br0 (which is bridged to the physical network).
      
      Users in the alice group can additionally get a tap device connected to br1.
      This allows br1 to act as a private bridge for the alice group.
      
      Users in the bob group can additionally get a tap device connected to br2.
      This allows br2 to act as a private bridge for the bob group.
      
      Users in the charlie group cannot get a tap device connected to any bridge.
      
      Under no circumstance can the bob group get access to br1 or can the alice
      group get access to br2.  And under no cicumstance can the charlie group
      get access to any bridge.
      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>
      bdef79a2
    • Corey Bryant's avatar
      Add basic version of bridge helper · 7b93fadf
      Corey Bryant authored
      This patch adds a helper that can be used to create a tap device attached to
      a bridge device.  Since this helper is minimal in what it does, it can be
      given CAP_NET_ADMIN which allows qemu to avoid running as root while still
      satisfying the majority of what users tend to want to do with tap devices.
      
      The way this all works is that qemu launches this helper passing a bridge
      name and the name of an inherited file descriptor.  The descriptor is one
      end of a socketpair() of domain sockets.  This domain socket is used to
      transmit a file descriptor of the opened tap device from the helper to qemu.
      
      The helper can then exit and let qemu use the tap device.
      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>
      7b93fadf
    • Gerhard Wiesinger's avatar
      hw/vmmouse.c: Disable vmmouse after reboot · 069ab0eb
      Gerhard Wiesinger authored
      Bugfix after reboot when vmmouse was enabled and another OS which uses e.g. PS/2
      mouse.
      
      Details:
      When a guest activated the vmmouse followed by a reboot the vmmouse was still
      enabled and the PS/2 mouse was therefore unsusable. When another guest is then
      booted without vmmouse support (e.g. PS/2 mouse) the mouse is not working.
      
      Reason is that VMMouse has priority and disables all other mouse entities
      and therefore must be disabled on reset.
      
      Testscenario:
      1.) Boot e.g. OS with VMMouse support (e.g. Windows with VMMouse tools)
      2.) reboot
      3.) Boot e.g. OS without VMMouse support (e.g. DOS) => PS/2 mouse doesn't work
           any more. Fixes that issue.
      
      Testscenario 2 by Jan Kiszka <jan.kiszka@siemens.com>:
      Confirm that this patch fixes a real issue. Setup: qemu.git,
      opensuse 11.4 guest, SDL graphic, system_reset while guest is using the
      vmmouse. Without the patch, the vmmouse become unusable after the
      reboot. Also, the mouse stays in absolute mode even before X starts again.
      
      Fixed by:
      Disabling the vmmouse in its reset handler.
      Tested-by: default avatarAndreas F=E4rber <afaerber@suse.de>
      Signed-off-by: default avatarGerhard Wiesinger <lists@wiesinger.com>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      069ab0eb
    • Laszlo Ersek's avatar
      keep the PID file locked for the lifetime of the process · 93dd748b
      Laszlo Ersek authored
      The lockf() call in qemu_create_pidfile() aims at ensuring mutual
      exclusion. We shouldn't close the pidfile on success (as introduced by
      commit 1bbd1592), because that drops the lock as well [1]:
      
          "File locks shall be released on first close by the locking process
          of any file descriptor for the file."
      
      Coverity may complain again about the leaked file descriptor; let's
      worry about that later.
      
      v1->v2:
      - add reference to 1bbd1592
      - explain the intentional fd leak in the source
      
      [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/lockf.htmlSigned-off-by: default avatarLaszlo Ersek <lersek@redhat.com>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      93dd748b
    • Michael Roth's avatar
      main-loop: For tools, initialize timers as part of qemu_init_main_loop() · d34e8f6e
      Michael Roth authored
      In some cases initializing the alarm timers can lead to non-negligable
      overhead from programs that link against qemu-tool.o. At least,
      setting a max-resolution WinMM alarm timer via mm_start_timer() (the
      current default for Windows) can increase the "tick rate" on Windows
      OSs and affect frequency scaling, and in the case of tools that run
      in guest OSs such has qemu-ga, the impact can be fairly dramatic
      (+20%/20% user/sys time on a core 2 processor was observed from an idle
      Windows XP guest).
      
      This patch doesn't address the issue directly (not sure what a good
      solution would be for Windows, or what other situations it might be
      noticeable), but it at least limits the scope of the issue to programs
      that "opt-in" to using the main-loop.c functions by only enabling alarm
      timers when qemu_init_main_loop() is called, which is already required
      to make use of those facilities, so existing users shouldn't be
      affected.
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarMichael Roth <mdroth@linux.vnet.ibm.com>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      d34e8f6e
    • Michael Roth's avatar
      main-loop: Fix SetEvent() on uninitialized handle on win32 · ee77dfb2
      Michael Roth authored
      The __attribute__((constructor)) init_main_loop() automatically get
      called if qemu-tool.o is linked in. On win32, this leads to
      a qemu_notify_event() call which attempts to SetEvent() on a HANDLE that
      won't be initialized until qemu_init_main_loop() is manually called,
      breaking qemu-tools.o programs on Windows at runtime.
      
      This patch checks for an initialized event handle before attempting to
      set it, which is analoguous to how we deal with an unitialized
      io_thread_fd in the posix implementation.
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarMichael Roth <mdroth@linux.vnet.ibm.com>
      Signed-off-by: default avatarMichael Roth <mdroth@linux.vnet.ibm.com>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      ee77dfb2
    • Jan Kiszka's avatar
      optionroms: Silence intermediate file removal · 6fbcef29
      Jan Kiszka authored
      The build process of optionroms spits out an "rm ..." line. Moreover, it
      removes all .o files that can be handy for debugging purposes. So
      disable automatic intermediate removal.
      Signed-off-by: default avatarJan Kiszka <jan.kiszka@siemens.com>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      6fbcef29
    • Jan Kiszka's avatar
      sdl: Limit sdl_grab_end in handle_activation to Windows hosts · 02df4d6f
      Jan Kiszka authored
      There are scenarios on Linux with some SDL versions where
      handle_activation is continuous invoked with state = SDL_APPINPUTFOCUS
      and gain = 0 while we grabbed the input. This causes a ping-pong when we
      grab the input after an absolute mouse entered the window.
      
      As this sdl_grab_end was once introduced to work around a Windows-only
      issue (0294ffb9), limit it to that platform.
      
      CC: Erik Rull <erik.rull@rdsoftware.de>
      Signed-off-by: default avatarJan Kiszka <jan.kiszka@siemens.com>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      02df4d6f
    • Jan Kiszka's avatar
      sdl: Grab input on end of non-absolute mouse click · 822f98d2
      Jan Kiszka authored
      By grabbing the input already on button down, we leave the button in
      that state for the host GUI. Thus it takes another click after releasing
      the input again to synchronize the mouse button state.
      
      Avoid this by grabbing on button up.
      Signed-off-by: default avatarJan Kiszka <jan.kiszka@siemens.com>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      822f98d2
    • Jan Kiszka's avatar
      Revert "Handle SDL grabs failing (Mark McLoughlin)" · eaa2e027
      Jan Kiszka authored
      This reverts commit 6bb81603.
      
      SDL_WM_GrabInput does not reliably bail out if grabbing is impossible.
      So if we get here, we already lost and will block. But this can no
      longer happen due to the check in sdl_grab_start. So this patch became
      obsolete.
      
      Conflicts:
      
      	sdl.c
      Signed-off-by: default avatarJan Kiszka <jan.kiszka@siemens.com>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      eaa2e027
    • Jan Kiszka's avatar
      sdl: Fix block prevention of SDL_WM_GrabInput · 85f94f86
      Jan Kiszka authored
      Consistently check for SDL_APPINPUTFOCUS before trying to grab the input
      focus. Just checking for SDL_APPACTIVE doesn't work. Moving the check to
      sdl_grab_start allows for some consolidation.
      Signed-off-by: default avatarJan Kiszka <jan.kiszka@siemens.com>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      85f94f86
    • Jan Kiszka's avatar
      sdl: Do not grab mouse on mode switch while in background · 66596356
      Jan Kiszka authored
      When the mouse mode changes to absolute while the SDL windows is not in
      focus, refrain from grabbing the input. It would steal from some other
      window.
      Signed-off-by: default avatarJan Kiszka <jan.kiszka@siemens.com>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      66596356
    • Jan Kiszka's avatar
      Improve default machine options usability · 25de5935
      Jan Kiszka authored
      So far we overwrite the machine options completely with defaults if no
      accel=value is provided. More user friendly is to fill in only
      unspecified options. The new qemu_opts_set_defaults enables this.
      Signed-off-by: default avatarJan Kiszka <jan.kiszka@siemens.com>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      25de5935
    • Jan Kiszka's avatar
      mc146818rtc: Use lost_tick_policy property · 433acf0d
      Jan Kiszka authored
      Allow to configure the MC146818 RTC via the new lost tick policy
      property and replace rtc_td_hack with this mechanism.
      Signed-off-by: default avatarJan Kiszka <jan.kiszka@siemens.com>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      433acf0d
    • Jan Kiszka's avatar
      qemu-option: Introduce default mechanism · 4f6dd9af
      Jan Kiszka authored
      This adds qemu_opts_set_defaults, an interface provide default values
      for a QemuOpts set. Default options are parsed from a string and then
      prepended to the list of existing options, or they serve as the sole
      QemuOpts set.
      Signed-off-by: default avatarJan Kiszka <jan.kiszka@siemens.com>
      Signed-off-by: default avatarJan Kiszka <jan.kiszka@siemens.com>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      4f6dd9af
    • Jan Kiszka's avatar
      qdev: Introduce lost tick policy property · 4e4fa398
      Jan Kiszka authored
      Potentially tick-generating timer devices will gain a common property:
      lock_tick_policy. It allows to encode 4 different ways how to deal with
      tick events the guest did not process in time:
      
      discard - ignore lost ticks (e.g. if the guest compensates for them
                already)
      delay   - replay all lost ticks in a row once the guest accepts them
                again
      merge   - if multiple ticks are lost, all of them are merged into one
                which is replayed once the guest accepts it again
      slew    - lost ticks are gradually replayed at a higher frequency than
                the original tick
      
      Not all timer device will need to support all modes. However, all need
      to accept the configuration via this common property.
      Signed-off-by: default avatarJan Kiszka <jan.kiszka@siemens.com>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      4e4fa398
    • Peter Maydell's avatar
      Makefile: Remove linux-headers/asm symlink on distclean · 67ed96f9
      Peter Maydell authored
      configure creates a linux-headers/asm symlink. Remove this when
      doing a distclean.
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      67ed96f9
    • Peter Maydell's avatar
      exec.c: Clarify comment about tlb_flush() flush_global parameter · 771124e1
      Peter Maydell authored
      Clarify the comment about tlb_flush()'s flush_global parameter,
      so it is clearer what it does and why it is OK that the implementation
      currently ignores it.
      Reviewed-by: default avatarAndreas F=C3=A4rber <afaerber@suse.de>
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      771124e1
    • Aneesh Kumar K.V's avatar
    • Stefan Weil's avatar
      MAINTAINERS: Add a section for the host OS and a W32 maintainer · 1bdd6874
      Stefan Weil authored
      Up to now, there was no special section for the different
      host operating systems used with QEMU.
      
      scripts/get_maintainer.pl did not show a maintainer for
      OS specific files and patches.
      
      Therefore I added three hosts systems:
      
      * POSIX for the majority of host systems which are supported.
        This includes BSD and Linux host systems.
      
      * LINUX is a special case of POSIX needed for some Linux specific
        files and directories.
      
      * W32, W64 for a well known family of closed source operating systems.
      
      I also added myself as a maintainer for W32, W64.
      Signed-off-by: default avatarStefan Weil <sw@weilnetz.de>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      1bdd6874
    • Sergei Trofimovich's avatar
      ./configure: add link check for nss-smartcard · 5f01e06f
      Sergei Trofimovich authored
      Current './configure --static && make' fails for me:
      
          LINK  qemu-nbd
          /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lssl3
          /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lsmime3
          /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lnssutil3
          /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lnss3
          /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lplds4
          /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lplc4
          /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lnspr4
      
      My system does not provide static libraries for nss, so
      fix autoconfiguration by link checking.
      Signed-off-by: default avatarSergei Trofimovich <slyfox@gentoo.org>
      CC: qemu-trivial <qemu-trivial@nongnu.org>
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      5f01e06f