Skip to content
Snippets Groups Projects
  1. Jul 07, 2015
  2. Jun 12, 2015
  3. Jun 11, 2015
  4. May 29, 2015
  5. May 18, 2015
  6. May 11, 2015
    • Scott Feldman's avatar
      rocker: add new rocker switch device · dc488f88
      Scott Feldman authored
      
      Rocker is a simulated ethernet switch device.  The device supports up to 62
      front-panel ports and supports L2 switching and L3 routing functions, as well
      as L2/L3/L4 ACLs.  The device presents a single PCI device for each switch,
      with a memory-mapped register space for device driver access.
      
      Rocker device is invoked with -device, for example a 4-port switch:
      
        -device rocker,name=sw1,len-ports=4,ports[0]=dev0,ports[1]=dev1, \
               ports[2]=dev2,ports[3]=dev3
      
      Each port is a netdev and can be paired with using -netdev id=<port name>.
      
      Signed-off-by: default avatarScott Feldman <sfeldma@gmail.com>
      Signed-off-by: default avatarJiri Pirko <jiri@resnulli.us>
      Acked-by: default avatarScott Feldman <sfeldma@gmail.com>
      Acked-by: default avatarJiri Pirko <jiri@resnulli.us>
      Signed-off-by: default avatarDavid Ahern <dsahern@gmail.com>
      Message-id: 1426306173-24884-7-git-send-email-sfeldma@gmail.com
      
      rocker: fix clang compiler errors
      
      Consolidate all forward typedef declarations to rocker.h.
      
      Signed-off-by: default avatarDavid Ahern <dsahern@gmail.com>
      Acked-by: default avatarScott Feldman <sfeldma@gmail.com>
      Acked-by: default avatarJiri Pirko <jiri@resnulli.us>
      
      rocker: add support for flow modification
      
      We had support for flow add/del.  This adds support for flow mod.  I needed
      this for L3 support where an existing route is modified using NLM_F_REPLACE.
      For example:
      
        ip route add 12.0.0.0/30 nexthop via 11.0.0.1 dev swp1
        ip route change 12.0.0.0/30 nexthop via 11.0.0.9 dev swp2
      
      The first cmd adds the route.  The second cmd changes the existing route by
      changing its nexthop info.
      
      In the device, a mod operation results in the matching flow enty being modified
      with the new settings.  This is atomic to the device.
      
      Signed-off-by: default avatarScott Feldman <sfeldma@gmail.com>
      Signed-off-by: default avatarStefan Hajnoczi <stefanha@redhat.com>
      dc488f88
  7. Apr 30, 2015
  8. Mar 18, 2015
  9. Mar 16, 2015
  10. Mar 12, 2015
  11. Mar 11, 2015
  12. Mar 09, 2015
  13. Mar 01, 2015
  14. Feb 27, 2015
    • David Gibson's avatar
      Give ivshmem its own config option · 8af738b3
      David Gibson authored
      
      Currently the ivshmem device is built whenever both PCI and KVM support are
      included.  This patch gives it its own config option to allow easier
      customization of whether to include it.  It's enabled by default in the
      same circumstances as now - when both PCI and KVM are available.
      
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      Reviewed-by: default avatarPeter Crosthwaite <peter.crosthwaite@xilinx.com>
      Message-Id: <1425017077-18487-4-git-send-email-david@gibson.dropbear.id.au>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      8af738b3
    • David Gibson's avatar
      Create specific config option for "platform-bus" · 22965942
      David Gibson authored
      
      Currently the "platform-bus" device is included for all softmmu builds.
      This bridge is intended for use on any platforms that require dynamic
      creation of sysbus devices.  However, at present it is used only for the
      PPC E500 target, with plans for the ARM "virt" target in the immediate
      future.
      
      To avoid a not-very-useful entry appearing in "qemu -device ?" output on
      other targets, this patch makes a specific config option for platform-bus
      and enables it (for now) only on ppc configurations which include E500
      and on ARM (which always includes the "virt" target).
      
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      Message-Id: <1425017077-18487-3-git-send-email-david@gibson.dropbear.id.au>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      22965942
    • David Gibson's avatar
      Add specific config options for PCI-E bridges · 46818675
      David Gibson authored
      
      The i82801b11, ioh3420 and xio3130 PCI Express devices are currently
      included in the build unconditionally.
      
      While they could theoretically appear on any target platform with PCI-E,
      they're pretty unlikely to appear on platforms that aren't Intel derived.
      
      Therefore, to avoid presenting unlikely-to-be-relevant devices to the user,
      add config options to enable these components, and enable them by default
      only on x86 and arm platforms.
      
      (Note that this patch does include these for aarch64, via its inclusion of
      arm-softmmu.mak).
      
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      Reviewed-by: default avatarPeter Crosthwaite <peter.crosthwaite@xilinx.com>
      Message-Id: <1425017077-18487-2-git-send-email-david@gibson.dropbear.id.au>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      46818675
  15. Feb 18, 2015
  16. Feb 13, 2015
  17. Jan 26, 2015
  18. Jan 12, 2015
  19. Dec 15, 2014
  20. Nov 07, 2014
  21. Sep 08, 2014
    • Alexander Graf's avatar
      PPC: Fix default config ordering and add eTSEC for ppc64 · 4a761ffa
      Alexander Graf authored
      
      We messed up the ordering in our default configs for PPC. The top entries
      are generic entries, then come sections that indicate that features are only
      in because of a special feature (such as PReP).
      
      Fix the ordering again and while at it add eTSEC support to the ppc64 target
      so that we can spawn eTSEC adapters with qemu-system-ppc64.
      
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      4a761ffa
  22. Sep 01, 2014
  23. Jun 19, 2014
  24. Jun 16, 2014
  25. May 20, 2014
  26. Apr 23, 2014
    • Gerd Hoffmann's avatar
      usb: mtp filesharing · 840a178c
      Gerd Hoffmann authored
      
      Implementation of a USB Media Transfer Device device for easy
      filesharing.  Read-only.  No access control inside qemu, it will
      happily export any file it is able to open to the guest, i.e.
      standard unix access rights for the qemu process apply.
      
      Signed-off-by: default avatarGerd Hoffmann <kraxel@redhat.com>
      840a178c
  27. Mar 05, 2014
  28. Feb 27, 2014
  29. Feb 13, 2014
Loading