1. 27 Nov, 2014 1 commit
    • Marcel Apfelbaum's avatar
      hmp: fix regression of HMP device_del auto-completion · 4cae4d5a
      Marcel Apfelbaum authored
      The commits:
       - 6a1fa9f5 (monitor: add del completion for peripheral device)
       - 66e56b13
      
       (qdev: add qdev_build_hotpluggable_device_list helper)
      
      cause a QEMU crash when trying to use HMP device_del auto-completion.
      It can be easily reproduced by:
          <qemu-bin> -enable-kvm  ~/images/fedora.qcow2 -monitor stdio -device virtio-net-pci,id=vnet
      
          (qemu) device_del
          /home/mapfelba/git/upstream/qemu/hw/core/qdev.c:941:qdev_build_hotpluggable_device_list: Object 0x7f6ce04e4fe0 is not an instance of type device
          Aborted (core dumped)
      
      The root cause is qdev_build_hotpluggable_device_list going recursively over
      all peripherals and their children assuming all are devices. It doesn't work
      since PCI devices have at least on child which is a memory region (bus master).
      
      Solved by observing that all devices appear as direct children of
      /machine/peripheral container. No need of going recursively
      over all the children.
      
      Signed-off-by: default avatarMarcel Apfelbaum <marcel.a@redhat.com>
      Reported-by: default avatarGal Hammer <ghammer@redhat.com>
      Reviewed-by: default avatarIgor Mammedov <imammedo@redhat.com>
      Message-id: 1417002601-20799-1-git-send-email-marcel.a@redhat.com
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      4cae4d5a
  2. 04 Nov, 2014 1 commit
    • Alexander Graf's avatar
      sysbus: Expose IRQ enumeration helpers · b7973186
      Alexander Graf authored
      
      
      Sysbus devices can get their IRQ lines connected to other devices. It is
      possible to figure out which IRQ line a connection is on and whether a sysbus
      device even provides an IRQ connector at a specific offset.
      
      This patch exposes helpers to make this information publicly accessible. We
      will need it for the platform bus dynamic sysbus enumeration.
      
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      b7973186
  3. 23 Oct, 2014 4 commits
  4. 14 Oct, 2014 6 commits
  5. 18 Sep, 2014 1 commit
  6. 01 Jul, 2014 1 commit
    • Paolo Bonzini's avatar
      qdev: correctly send DEVICE_DELETED for recursively-deleted devices · 352e8da7
      Paolo Bonzini authored
      When a device is unparented (i.e. made completely hidden from management)
      we want to send a DEVICE_DELETED event only if the device actually was
      realized.  This avoids raising DEVICE_DELETED events when device_add
      fails.
      
      However, this does not work right for recursively-deleted
      devices: the whole tree is _first_ unrealized, _then_ unparented.
      Then device_unparent sees realized==false and fails to trigger
      the event.  The solution is simply to move have_realized into
      the DeviceState struct.  If device_add fails, we never set the
      new field to true and DEVICE_DELETED is not sent.
      
      Fixes qemu-iotests testcase 067 (broken by commit 5942a190
      
      , though that
      commit in turn fixed a possible segfault in the same test).
      
      Reported-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      352e8da7
  7. 05 Jun, 2014 1 commit
    • Don Slutz's avatar
      qdev: Display warning about unused -global · 9f9260a3
      Don Slutz authored
      
      
      This can help a user understand why -global was ignored.
      
      For example: with "-vga cirrus"; "-global vga.vgamem_mb=16" is just
      ignored when "-global cirrus-vga.vgamem_mb=16" is not.
      
      This is currently clear when the wrong property is provided:
      
      out/x86_64-softmmu/qemu-system-x86_64 -global cirrus-vga.vram_size_mb=16 -monitor pty -vga cirrus
      char device redirected to /dev/pts/20 (label compat_monitor0)
      qemu-system-x86_64: Property '.vram_size_mb' not found
      Aborted (core dumped)
      
      vs
      
      out/x86_64-softmmu/qemu-system-x86_64 -global vga.vram_size_mb=16 -monitor pty -vga cirrus
      char device redirected to /dev/pts/20 (label compat_monitor0)
      VNC server running on `::1:5900'
      ^Cqemu: terminating on signal 2
      
      Signed-off-by: default avatarDon Slutz <dslutz@verizon.com>
      Acked-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      9f9260a3
  8. 28 May, 2014 1 commit
  9. 12 Mar, 2014 1 commit
  10. 04 Mar, 2014 1 commit
    • Alexander Graf's avatar
      qdev: Keep global allocation counter per bus · 61de3676
      Alexander Graf authored
      
      
      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: default avatarAlexander Graf <agraf@suse.de>
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: default avatarAndreas Faerber <afaerber@suse.de>
      Signed-off-by: default avatarAlexander Graf <agraf@suse.de>
      61de3676
  11. 14 Feb, 2014 1 commit
  12. 10 Feb, 2014 2 commits
    • Igor Mammedov's avatar
      qdev: add "hotpluggable" property to Device · 1a37eca1
      Igor Mammedov authored
      
      
      Currently it's possible to make PCIDevice not hotpluggable
      by using no_hotplug field of PCIDeviceClass. However it
      limits this only to PCI devices and prevents from
      generalizing hotplug code.
      
      So add similar field to DeviceClass so it could be reused
      with other Devices and would allow to replace PCI specific
      hotplug callbacks with generic implementation. Following
      patches will replace PCIDeviceClass.no_hotplug with this
      new property.
      
      In addition expose field as "hotpluggable" readonly property,
      to make it possible to read its value via QOM interface.
      
      Make DeviceClass hotpluggable by default as it was assumed
      before.
      
      Signed-off-by: default avatarIgor Mammedov <imammedo@redhat.com>
      Reviewed-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      1a37eca1
    • Igor Mammedov's avatar
      qdev: add to BusState "hotplug-handler" link · 0ee4de6c
      Igor Mammedov authored
      
      
      It will allow to reuse field with different BUSes,
      reducing code duplication. Field is intended for
      replacing 'hotplug_qdev' field in PCIBus and also
      will allow to avoid adding equivalent field to
      DimmBus with possiblitity to refactor other BUSes
      to use it instead of custom field.
      In addition once all users of allow_hotplug field
      are converted to new API, link could replace
      allow_hotplug field in qdev hotplug code.
      
      Signed-off-by: default avatarIgor Mammedov <imammedo@redhat.com>
      Reviewed-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      0ee4de6c
  13. 24 Dec, 2013 1 commit
  14. 23 Dec, 2013 2 commits
    • Paolo Bonzini's avatar
      qdev: switch reset to post-order · dcc20931
      Paolo Bonzini authored
      
      
      Post-order is the only sensible direction for the reset signals.
      For example, suppose pre-order is used and the parent has some data
      structures that cache children state (for example a list of active
      requests).  When the reset method is invoked on the parent, these caches
      could be in any state.
      
      If post-order is used, on the other hand, these will be in a known state
      when the reset method is invoked on the parent.
      
      This change means that it is no longer possible to block the visit of
      the devices, so the callback is changed to return void.  This is not
      a problem, because PCI was returning 1 exactly in order to achieve the
      same ordering that this patch implements.
      
      PCI can then rely on the qdev core having sent a "reset signal" (whatever
      that means) to the device, and only do the PCI-specific initialization
      with pci_do_device_reset.
      
      MST: fixed up virtio-ccw
      
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      dcc20931
    • Paolo Bonzini's avatar
      qdev: allow both pre- and post-order vists in qdev walking functions · 0293214b
      Paolo Bonzini authored
      
      
      Resetting should be done in post-order, not pre-order.  However,
      qdev_walk_children and qbus_walk_children do not allow this.  Fix
      it by adding two extra arguments to the functions.
      
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      0293214b
  15. 22 Dec, 2013 1 commit
    • Markus Armbruster's avatar
      qdev: Replace no_user by cannot_instantiate_with_device_add_yet · efec3dd6
      Markus Armbruster authored
      In an ideal world, machines can be built by wiring devices together
      with configuration, not code.  Unfortunately, that's not the world we
      live in right now.  We still have quite a few devices that need to be
      wired up by code.  If you try to device_add such a device, it'll fail
      in sometimes mysterious ways.  If you're lucky, you get an
      unmysterious immediate crash.
      
      To protect users from such badness, DeviceClass member no_user used to
      make device models unavailable with -device / device_add, but that
      regressed in commit 18b6dade
      
      .  The device model is still omitted from
      help, but is available anyway.
      
      Attempts to fix the regression have been rejected with the argument
      that the purpose of no_user isn't clear, and it's prone to misuse.
      
      This commit clarifies no_user's purpose.  Anthony suggested to rename
      it cannot_instantiate_with_device_add_yet_due_to_internal_bugs, which
      I shorten somewhat to keep checkpatch happy.  While there, make it
      bool.
      
      Every use of cannot_instantiate_with_device_add_yet gets a FIXME
      comment asking for rationale.  The next few commits will clean them
      all up, either by providing a rationale, or by getting rid of the use.
      
      With that done, the regression fix is hopefully acceptable.
      
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: default avatarMarcel Apfelbaum <marcel.a@redhat.com>
      Signed-off-by: default avatarAndreas Färber <afaerber@suse.de>
      efec3dd6
  16. 05 Nov, 2013 1 commit
  17. 11 Oct, 2013 1 commit
    • Markus Armbruster's avatar
      Mostly revert "qemu-help: Sort devices by logical functionality" · 1fc224b4
      Markus Armbruster authored
      This reverts most of commit 3d1237fb
      
      .
      
      The commit claims to sort the output of "-device help" "by
      functionality rather than alphabetical".  Issues:
      
      * The output was unsorted before, not alphabetically sorted.
        Misleading, but harmless enough.
      
      * The commit doesn't just sort the output of "-device help" as it
        claims, it adds categories to each line of "-device help", and it
        prints devices once per category.  In particular, devices without a
        category aren't shown anymore.  Maybe such devices should not exist,
        but they do.  Regression.
      
      * Categories are also added to the output of "info qdm".  Silent
        change, not nice.  Output remains unsorted, unlike "-device help".
      
      I'm going to reimplement the feature we actually want, without the
      warts.  Reverting the flawed commit first should make it easier to
      review.  However, I can't revert it completely, since DeviceClass
      member categories has been put to use.  So leave that part in.
      
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: default avatarMarcel Apfelbaum <marcel.a@redhat.com>
      Message-id: 1381410021-1538-2-git-send-email-armbru@redhat.com
      Signed-off-by: default avatarAnthony Liguori <aliguori@amazon.com>
      1fc224b4
  18. 30 Aug, 2013 1 commit
  19. 29 Jul, 2013 2 commits
  20. 07 Jun, 2013 1 commit
  21. 15 Apr, 2013 1 commit
    • Andreas Färber's avatar
      qdev: Fix QOM unrealize behavior · fe6c2117
      Andreas Färber authored
      Since commit 249d4172
      
       (qdev: Prepare
      "realized" property) setting realized = true would register the device's
      VMStateDescription, but realized = false would not unregister it. Fix that.
      
      Moving the code from unparenting also revealed that we were calling
      DeviceClass::init through DeviceClass::realize as interim solution but
      DeviceClass::exit still at unparenting time with a realized check.
      Make this symmetrical by implementing DeviceClass::unrealize to call it,
      while we're setting realized = false in the unparenting path.
      The only other unrealize user is mac_nvram, which can safely override it.
      
      Thus, mark DeviceClass::exit as obsolete, new devices should implement
      DeviceClass::unrealize instead.
      
      Cc: qemu-stable@nongnu.org
      Signed-off-by: default avatarAndreas Färber <afaerber@suse.de>
      Signed-off-by: default avatarAndreas Färber <afaerber@suse.de>
      Message-id: 1366043650-9719-1-git-send-email-afaerber@suse.de
      Signed-off-by: default avatarAnthony Liguori <aliguori@us.ibm.com>
      fe6c2117
  22. 08 Apr, 2013 1 commit
    • Paolo Bonzini's avatar
      hw: move headers to include/ · 0d09e41a
      Paolo Bonzini authored
      
      
      Many of these should be cleaned up with proper qdev-/QOM-ification.
      Right now there are many catch-all headers in include/hw/ARCH depending
      on cpu.h, and this makes it necessary to compile these files per-target.
      However, fixing this does not belong in these patches.
      
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      0d09e41a
  23. 15 Mar, 2013 1 commit
    • Peter Maydell's avatar
      qdev: Implement (variable length) array properties · 0be6bfac
      Peter Maydell authored
      
      
      Add support for declaring array properties for qdev devices.
      These work by defining an initial static property 'len-arrayname'
      which the user of the device should set to the desired size
      of the array. When this property is set, memory is allocated
      for the array elements, and dynamic properties "arrayname[0]",
      "arrayname[1]"... are created so the user of the device can
      then set the values of the individual array elements.
      
      Signed-off-by: default avatarPeter Maydell <peter.maydell@linaro.org>
      0be6bfac
  24. 01 Feb, 2013 1 commit
  25. 21 Jan, 2013 1 commit
  26. 17 Jan, 2013 1 commit
  27. 15 Jan, 2013 2 commits
  28. 10 Jan, 2013 1 commit