1. 18 7月, 2014 1 次提交
  2. 12 7月, 2014 1 次提交
  3. 29 6月, 2014 1 次提交
  4. 23 6月, 2014 2 次提交
  5. 19 6月, 2014 4 次提交
  6. 28 5月, 2014 1 次提交
  7. 07 5月, 2014 1 次提交
  8. 05 5月, 2014 3 次提交
  9. 14 3月, 2014 2 次提交
  10. 11 3月, 2014 1 次提交
    • M
      pc: avoid duplicate names for ROM MRs · ac41881b
      Michael S. Tsirkin 提交于
      Since
      commit 04920fc0
          loader: store FW CFG ROM files in RAM
      RAM MRs including ROM files in FW CFGs are created
      and named using the file basename.
      
      This becomes problematic if these names are
      supplied by user, since the basename might not
      be unique.
      
      There are two cases we care about:
      - option-rom flag.
      - option ROM for devices. This triggers e.g. when
        using rombar=0.
      
      At the moment we get an assert. E.g
      qemu -option-rom /usr/share/ipxe/8086100e.rom -option-rom
      /usr/share/ipxe.efi/8086100e.rom
      RAMBlock "/rom@genroms/8086100e.rom" already registered, abort!
      
      This is a regression from 1.6.
      
      For now let's keep it simple and just avoid creating the
      MRs in case of option ROMs.
      
      when using 1.7 machine types, enable
      option ROMs in RAM to match that version.
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      ac41881b
  11. 10 3月, 2014 1 次提交
  12. 05 3月, 2014 1 次提交
    • A
      qdev: Keep global allocation counter per bus · 61de3676
      Alexander Graf 提交于
      When we have 2 separate qdev devices that both create a qbus of the
      same type without specifying a bus name or device name, we end up
      with two buses of the same name, such as ide.0 on the Mac machines:
      
        dev: macio-ide, id ""
          bus: ide.0
            type IDE
        dev: macio-ide, id ""
          bus: ide.0
            type IDE
      
      If we now spawn a device that connects to a ide.0 the last created
      bus gets the device, with the first created bus inaccessible to the
      command line.
      
      After some discussion on IRC we concluded that the best quick fix way
      forward for this is to make automated bus-class type based allocation
      count a global counter. That's what this patch implements. With this
      we instead get
      
        dev: macio-ide, id ""
          bus: ide.1
            type IDE
        dev: macio-ide, id ""
          bus: ide.0
            type IDE
      
      on the example mentioned above.
      
      This also means that if you did -device ...,bus=ide.0 you got a device
      on the first bus (the last created one) before this patch and get that
      device on the second one (the first created one) now.  Breaks
      migration unless you change bus=ide.0 to bus=ide.1 on the destination.
      
      This is intended and makes the bus enumeration work as expected.
      
      As per review request follows a list of otherwise affected boards and
      the reasoning for the conclusion that they are ok:
      
         target      machine         bus id              times
         ------      -------         ------              -----
      
         aarch64     n800            i2c-bus.0           2
         aarch64     n810            i2c-bus.0           2
         arm         n800            i2c-bus.0           2
         arm         n810            i2c-bus.0           2
      
      -> Devices are only created explicitly on one of the two buses, using
         s->mpu->i2c[0], so no change to the guest.
      
         aarch64     vexpress-a15    virtio-mmio-bus.0   4
         aarch64     vexpress-a9     virtio-mmio-bus.0   4
         aarch64     virt            virtio-mmio-bus.0   32
         arm         vexpress-a15    virtio-mmio-bus.0   4
         arm         vexpress-a9     virtio-mmio-bus.0   4
         arm         virt            virtio-mmio-bus.0   32
      
      -> Makes -device bus= work for all virtio-mmio buses.  Breaks
         migration.  Workaround for migration from old to new: specify
         virtio-mmio-bus.4 or .32 respectively rather than .0 on the
         destination.
      
         aarch64     xilinx-zynq-a9  usb-bus.0           2
         arm         xilinx-zynq-a9  usb-bus.0           2
         mips64el    fulong2e        usb-bus.0           2
      
      -> Normal USB operation not affected. Migration driver needs command
         line to use the other bus.
      
         i386        isapc           ide.0               2
         x86_64      isapc           ide.0               2
         mips        mips            ide.0               2
         mips64      mips            ide.0               2
         mips64el    mips            ide.0               2
         mipsel      mips            ide.0               2
         ppc         g3beige         ide.0               2
         ppc         mac99           ide.0               2
         ppc         prep            ide.0               2
         ppc64       g3beige         ide.0               2
         ppc64       mac99           ide.0               2
         ppc64       prep            ide.0               2
      
      -> Makes -device bus= work for all IDE buses.  Breaks migration.
         Workaround for migration from old to new: specify ide.1 rather than
         ide.0 on the destination.
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: NAndreas Faerber <afaerber@suse.de>
      Signed-off-by: NAlexander Graf <agraf@suse.de>
      61de3676
  13. 14 2月, 2014 1 次提交
  14. 05 2月, 2014 1 次提交
  15. 16 1月, 2014 1 次提交
    • G
      usb: add support for microsoft os descriptors · 5319dc7b
      Gerd Hoffmann 提交于
      This patch adds support for special usb descriptors used by microsoft
      windows.  They allow more fine-grained control over driver binding and
      adding entries to the registry for configuration.
      
      As this is a guest-visible change the "msos-desc" compat property
      has been added to turn this off for 1.7 + older
      Signed-off-by: NGerd Hoffmann <kraxel@redhat.com>
      5319dc7b
  16. 24 12月, 2013 1 次提交
  17. 23 12月, 2013 2 次提交
  18. 12 12月, 2013 1 次提交
  19. 10 12月, 2013 3 次提交
  20. 06 12月, 2013 1 次提交
  21. 02 12月, 2013 1 次提交
  22. 22 11月, 2013 1 次提交
    • P
      pc: get rid of builtin pvpanic for "-M pc-1.5" · 7839ff59
      Paolo Bonzini 提交于
      This causes two slight backwards-incompatibilities between "-M pc-1.5"
      and 1.5's "-M pc":
      
      (1) a fw_cfg file is removed with this patch.  This is only a problem
      if migration stops the virtual machine exactly during fw_cfg enumeration.
      
      (2) after migration, a VM created without an explicit "-device pvpanic"
      will stop reporting panics to management.
      
      The first problem only occurs if migration is done at a very, very
      early point (and I'm not sure it can happen in practice for reasonable-size
      VMs, since it will likely take more time to send the RAM to destination,
      than it will take for BIOS to scan fw_cfg).
      
      The second problem only occurs if the guest panics _and_ has a guest
      driver _and_ management knows to look at the crash event, so it is
      mostly theoretical at this point in time.
      
      Thus keep the code simple, and pretend it was never broken.
      Reviewed-by: NEric Blake <eblake@redhat.com>
      Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
      7839ff59
  23. 14 11月, 2013 1 次提交
  24. 04 11月, 2013 1 次提交
  25. 14 10月, 2013 1 次提交
  26. 26 9月, 2013 1 次提交
  27. 10 9月, 2013 1 次提交
  28. 06 9月, 2013 1 次提交
    • V
      e1000: add interrupt mitigation support · e9845f09
      Vincenzo Maffione 提交于
      This patch partially implements the e1000 interrupt mitigation mechanisms.
      Using a single QEMUTimer, it emulates the ITR register (which is the newer
      mitigation register, recommended by Intel) and approximately emulates
      RADV and TADV registers. TIDV and RDTR register functionalities are not
      emulated (RDTR is only used to validate RADV, according to the e1000 specs).
      
      RADV, TADV, TIDV and RDTR registers make up the older e1000 mitigation
      mechanism and would need a timer each to be completely emulated. However,
      a single timer has been used in order to reach a good compromise between
      emulation accuracy and simplicity/efficiency.
      
      The implemented mechanism can be enabled/disabled specifying the command
      line e1000-specific boolean parameter "mitigation", e.g.
      
          qemu-system-x86_64 -device e1000,mitigation=on,... ...
      
      For more information, see the Software developer's manual at
      http://download.intel.com/design/network/manuals/8254x_GBe_SDM.pdf.
      
      Interrupt mitigation boosts performance when the guest suffers from
      an high interrupt rate (i.e. receiving short UDP packets at high packet
      rate). For some numerical results see the following link
      http://info.iet.unipi.it/~luigi/papers/20130520-rizzo-vm.pdfSigned-off-by: NVincenzo Maffione <v.maffione@gmail.com>
      Reviewed-by: Andreas Färber <afaerber@suse.de> (for pc-* machines)
      Signed-off-by: NStefan Hajnoczi <stefanha@redhat.com>
      e9845f09
  29. 01 9月, 2013 1 次提交
    • M
      pc: reduce duplication, fix PIIX descriptions · a0dba644
      Michael S. Tsirkin 提交于
      We have a lot of code duplication between machine types,
      this increases with each new machine type
      and each new field.
      
      This has already introduced a minor bug: description
      for pc-1.3 says "Standard PC" while description for
      pc-1.4 is "Standard PC (i440FX + PIIX, 1996)"
      which makes you think 1.3 is somehow more standard,
      or newer, while in fact it's a revision of the same PC.
      
      This patch addresses this issue by using macros, along
      the lines used by PC_COMPAT_X_X - only for
      non-property options.
      
      The approach can extend to non-PC machine types.
      
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      a0dba644
  30. 28 8月, 2013 1 次提交
    • M
      hw: Clean up bogus default boot order · c1654732
      Markus Armbruster 提交于
      We set default boot order "cad" in every single machine definition
      except "pseries" and "moxiesim", even though very few boards actually
      care for boot order, and "cad" makes sense for even fewer.
      
      Machines that care:
      
      * pc and its variants
      
        Accept up to three letters 'a', 'b' (undocumented alias for 'a'),
        'c', 'd' and 'n'.  Reject all others (fatal with -boot).
      
      * nseries (n800, n810)
      
        Check whether order starts with 'n'.  Silently ignored otherwise.
      
      * prep, g3beige, mac99
      
        Extract the first character the machine understands (subset of
        'a'..'f').  Silently ignored otherwise.
      
      * spapr
      
        Accept an arbitrary string (vl.c restricts it to contain only
        'a'..'p', no duplicates).
      
      * sun4[mdc]
      
        Use the first character.  Silently ignored otherwise.
      
      Strip characters these machines ignore from their default boot order.
      
      For all other machines, remove the unused default boot order
      alltogether.
      
      Note that my rename of QEMUMachine member boot_order to
      default_boot_order and QEMUMachineInitArgs member boot_device to
      boot_order has a welcome side effect: it makes every use of boot
      orders visible in this patch, for easy review.
      Signed-off-by: NMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      c1654732