Skip to content
Snippets Groups Projects
  1. Feb 27, 2020
  2. Feb 25, 2020
  3. Jan 24, 2020
  4. Dec 18, 2019
  5. Oct 29, 2019
    • Jens Freimann's avatar
      migration: allow unplug during migration for failover devices · a1190ab6
      Jens Freimann authored
      
      In "b06424de migration: Disable hotplug/unplug during migration" we
      added a check to disable unplug for all devices until we have figured
      out what works. For failover primary devices qdev_unplug() is called
      from the migration handler, i.e. during migration.
      
      This patch adds a flag to DeviceState which is set to false for all
      devices and makes an exception for PCI devices that are also
      primary devices in a failover pair.
      
      Signed-off-by: default avatarJens Freimann <jfreimann@redhat.com>
      Message-Id: <20191029114905.6856-8-jfreimann@redhat.com>
      Reviewed-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      a1190ab6
    • Jens Freimann's avatar
      qdev/qbus: add hidden device support · f3a85056
      Jens Freimann authored
      This adds support for hiding a device to the qbus and qdev APIs.  The
      first user of this will be the virtio-net failover feature but the API
      introduced with this patch could be used to implement other features as
      well, for example hiding pci devices when a pci bus is powered off.
      
      qdev_device_add() is modified to check for a failover_pair_id
      argument in the option string. A DeviceListener callback
      should_be_hidden() is added. It can be used by a standby device to
      inform qdev that this device should not be added now. The standby device
      handler can store the device options to plug the device in at a later
      point in time.
      
      One reason for hiding the device is that we don't want to expose both
      devices to the guest kernel until the respective virtio feature bit
      VIRTIO_NET_F_STANDBY was negotiated and we know that the devices will be
      handled correctly by the guest.
      
      More information on the kernel feature this is using:
       https://www.kernel.org/doc/html/latest/networking/net_failover.html
      
      
      
      An example where the primary device is a vfio-pci device and the standby
      device is a virtio-net device:
      
      A device is hidden when it has an "failover_pair_id" option, e.g.
      
       -device virtio-net-pci,...,failover=on,...
       -device vfio-pci,...,failover_pair_id=net1,...
      
      Signed-off-by: default avatarJens Freimann <jfreimann@redhat.com>
      Message-Id: <20191029114905.6856-2-jfreimann@redhat.com>
      Reviewed-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      f3a85056
  6. Sep 16, 2019
  7. Aug 21, 2019
  8. Aug 16, 2019
    • Markus Armbruster's avatar
      Clean up inclusion of sysemu/sysemu.h · d5938f29
      Markus Armbruster authored
      
      In my "build everything" tree, changing sysemu/sysemu.h triggers a
      recompile of some 5400 out of 6600 objects (not counting tests and
      objects that don't depend on qemu/osdep.h).
      
      Almost a third of its inclusions are actually superfluous.  Delete
      them.  Downgrade two more to qapi/qapi-types-run-state.h, and move one
      from char/serial.h to char/serial.c.
      
      hw/semihosting/config.c, monitor/monitor.c, qdev-monitor.c, and
      stubs/semihost.c define variables declared in sysemu/sysemu.h without
      including it.  The compiler is cool with that, but include it anyway.
      
      This doesn't reduce actual use much, as it's still included into
      widely included headers.  The next commit will tackle that.
      
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: default avatarAlistair Francis <alistair.francis@wdc.com>
      Message-Id: <20190812052359.30071-27-armbru@redhat.com>
      Reviewed-by: default avatarAlex Bennée <alex.bennee@linaro.org>
      d5938f29
    • Markus Armbruster's avatar
      Include hw/qdev-properties.h less · a27bd6c7
      Markus Armbruster authored
      
      In my "build everything" tree, changing hw/qdev-properties.h triggers
      a recompile of some 2700 out of 6600 objects (not counting tests and
      objects that don't depend on qemu/osdep.h).
      
      Many places including hw/qdev-properties.h (directly or via hw/qdev.h)
      actually need only hw/qdev-core.h.  Include hw/qdev-core.h there
      instead.
      
      hw/qdev.h is actually pointless: all it does is include hw/qdev-core.h
      and hw/qdev-properties.h, which in turn includes hw/qdev-core.h.
      Replace the remaining uses of hw/qdev.h by hw/qdev-properties.h.
      
      While there, delete a few superfluous inclusions of hw/qdev-core.h.
      
      Touching hw/qdev-properties.h now recompiles some 1200 objects.
      
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: "Daniel P. Berrangé" <berrange@redhat.com>
      Cc: Eduardo Habkost <ehabkost@redhat.com>
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Reviewed-by: default avatarEduardo Habkost <ehabkost@redhat.com>
      Message-Id: <20190812052359.30071-22-armbru@redhat.com>
      a27bd6c7
  9. Jul 02, 2019
    • Markus Armbruster's avatar
      qom: Move HMP command handlers to qom/ · 3950a377
      Markus Armbruster authored
      
      Move the HMP command handlers related to QOM handlers from
      monitor/hmp-cmds.c and qdev-monitor.c to new qom/qom-hmp-cmds.c, where
      they are covered by MAINTAINERS section QOM.
      
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: "Daniel P. Berrange" <berrange@redhat.com>
      Cc: Eduardo Habkost <ehabkost@redhat.com>
      Cc: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Message-Id: <20190619201050.19040-7-armbru@redhat.com>
      Reviewed-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
      Reviewed-by: default avatarDr. David Alan Gilbert <dgilbert@redhat.com>
      [Also move hmp_info_qom_tree(), tweak commit message accordingly]
      3950a377
    • Markus Armbruster's avatar
      qapi: Split qom.json and qdev.json off misc.json · c577ff62
      Markus Armbruster authored
      
      Move commands object-add, object-del, qom-get, qom-list,
      qom-list-properties, qom-list-types, and qom-set with their types from
      misc.json to new qom.json.
      
      Move commands device-list-properties, device_add, device-del, and
      event DEVICE_DELETED from misc.json to new qdev.json.
      
      Add both new files to MAINTAINERS section QOM.
      
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: "Daniel P. Berrange" <berrange@redhat.com>
      Cc: Eduardo Habkost <ehabkost@redhat.com>
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Message-Id: <20190619201050.19040-5-armbru@redhat.com>
      Reviewed-by: default avatarDaniel P. Berrangé <berrange@redhat.com>
      [Straightforwardly updated for "MAINTAINERS: Make section "QOM" cover
      qdev as well"]
      c577ff62
  10. Apr 18, 2019
  11. Mar 06, 2019
    • David Hildenbrand's avatar
      qdev: Let the hotplug_handler_unplug() caller delete the device · 07578b0a
      David Hildenbrand authored
      
      When unplugging a device, at one point the device will be destroyed
      via object_unparent(). This will, one the one hand, unrealize the
      removed device hierarchy, and on the other hand, destroy/free the
      device hierarchy.
      
      When chaining hotplug handlers, we want to overwrite a bus hotplug
      handler by the machine hotplug handler, to be able to perform
      some part of the plug/unplug and to forward the calls to the bus hotplug
      handler.
      
      For now, the bus hotplug handler would trigger an object_unparent(), not
      allowing us to perform some unplug action on a device after we forwarded
      the call to the bus hotplug handler. The device would be gone at that
      point.
      
      machine_unplug_handler(dev)
          /* eventually do unplug stuff */
          bus_unplug_handler(dev)
          /* dev is gone, we can't do more unplug stuff */
      
      So move the object_unparent() to the original caller of the unplug. For
      now, keep the unrealize() at the original places of the
      object_unparent(). For implicitly chained hotplug handlers (e.g. pc
      code calling acpi hotplug handlers), the object_unparent() has to be
      done by the outermost caller. So when calling hotplug_handler_unplug()
      from inside an unplug handler, nothing is to be done.
      
      hotplug_handler_unplug(dev) -> calls machine_unplug_handler()
          machine_unplug_handler(dev) {
              /* eventually do unplug stuff */
              bus_unplug_handler(dev) -> calls unrealize(dev)
              /* we can do more unplug stuff but device already unrealized */
          }
      object_unparent(dev)
      
      In the long run, every unplug action should be factored out of the
      unrealize() function into the unplug handler (especially for PCI). Then
      we can get rid of the additonal unrealize() calls and object_unparent()
      will properly unrealize the device hierarchy after the device has been
      unplugged.
      
      hotplug_handler_unplug(dev) -> calls machine_unplug_handler()
          machine_unplug_handler(dev) {
              /* eventually do unplug stuff */
              bus_unplug_handler(dev) -> only unplugs, does not unrealize
              /* we can do more unplug stuff */
          }
      object_unparent(dev) -> will unrealize
      
      The original approach was suggested by Igor Mammedov for the PCI
      part, but I extended it to all hotplug handlers. I consider this one
      step into the right direction.
      
      To summarize:
      - object_unparent() on synchronous unplugs is done by common code
      -- "Caller of hotplug_handler_unplug"
      - object_unparent() on asynchronous unplugs ("unplug requests") has to
        be done manually
      -- "Caller of hotplug_handler_unplug"
      
      Reviewed-by: default avatarIgor Mammedov <imammedo@redhat.com>
      Acked-by: default avatarCornelia Huck <cohuck@redhat.com>
      Signed-off-by: default avatarDavid Hildenbrand <david@redhat.com>
      Message-Id: <20190228122849.4296-2-david@redhat.com>
      Reviewed-by: default avatarGreg Kurz <groug@kaod.org>
      Signed-off-by: default avatarEduardo Habkost <ehabkost@redhat.com>
      07578b0a
    • Tony Krowiak's avatar
      qdev/core: fix qbus_is_full() · 12b2e9f3
      Tony Krowiak authored
      
      The qbus_is_full(BusState *bus) function (qdev_monitor.c) compares the max_index
      value of the BusState structure with the max_dev value of the BusClass structure
      to determine whether the maximum number of children has been reached for the
      bus. The problem is, the max_index field of the BusState structure does not
      necessarily reflect the number of devices that have been plugged into
      the bus.
      
      Whenever a child device is plugged into the bus, the bus's max_index value is
      assigned to the child device and then incremented. If the child is subsequently
      unplugged, the value of the max_index does not change and no longer reflects the
      number of children.
      
      When the bus's max_index value reaches the maximum number of devices
      allowed for the bus (i.e., the max_dev field in the BusClass structure),
      attempts to plug another device will be rejected claiming that the bus is
      full -- even if the bus is actually empty.
      
      To resolve the problem, a new 'num_children' field is being added to the
      BusState structure to keep track of the number of children plugged into the
      bus. It will be incremented when a child is plugged, and decremented when a
      child is unplugged.
      
      Signed-off-by: default avatarTony Krowiak <akrowiak@linux.ibm.com>
      Reviewed-by: default avatarPierre <Morel&lt;pmorel@linux.ibm.com>
      Reviewed-by: default avatarHalil Pasic <pasic@linux.ibm.com>
      Message-Id: <1545062250-7573-1-git-send-email-akrowiak@linux.ibm.com>
      Reviewed-by: default avatarIgor Mammedov <imammedo@redhat.com>
      Signed-off-by: default avatarEduardo Habkost <ehabkost@redhat.com>
      12b2e9f3
  12. Nov 05, 2018
  13. Oct 05, 2018
  14. Mar 12, 2018
  15. Mar 06, 2018
  16. Mar 02, 2018
    • Markus Armbruster's avatar
      qapi: Empty out qapi-schema.json · 112ed241
      Markus Armbruster authored
      
      The previous commit improved compile time by including less of the
      generated QAPI headers.  This is impossible for stuff defined directly
      in qapi-schema.json, because that ends up in headers that that pull in
      everything.
      
      Move everything but include directives from qapi-schema.json to new
      sub-module qapi/misc.json, then include just the "misc" shard where
      possible.
      
      It's possible everywhere, except:
      
      * monitor.c needs qmp-command.h to get qmp_init_marshal()
      
      * monitor.c, ui/vnc.c and the generated qapi-event-FOO.c need
        qapi-event.h to get enum QAPIEvent
      
      Perhaps we'll get rid of those some other day.
      
      Adding a type to qapi/migration.json now recompiles some 120 instead
      of 2300 out of 5100 objects.
      
      Signed-off-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Message-Id: <20180211093607.27351-25-armbru@redhat.com>
      [eblake: rebase to master]
      Signed-off-by: default avatarEric Blake <eblake@redhat.com>
      112ed241
  17. Feb 09, 2018
  18. Jan 19, 2018
  19. Nov 05, 2017
  20. Jun 13, 2017
  21. May 17, 2017
    • Eduardo Habkost's avatar
      qdev: Replace cannot_instantiate_with_device_add_yet with !user_creatable · e90f2a8c
      Eduardo Habkost authored
      
      cannot_instantiate_with_device_add_yet was introduced by commit
      efec3dd6 to replace no_user. It was
      supposed to be a temporary measure.
      
      When it was introduced, we had 54
      cannot_instantiate_with_device_add_yet=true lines in the code.
      Today (3 years later) this number has not shrunk: we now have
      57 cannot_instantiate_with_device_add_yet=true lines. I think it
      is safe to say it is not a temporary measure, and we won't see
      the flag go away soon.
      
      Instead of a long field name that misleads people to believe it
      is temporary, replace it a shorter and less misleading field:
      user_creatable.
      
      Except for code comments, changes were generated using the
      following Coccinelle patch:
      
        @@
        expression DC;
        @@
        (
        -DC->cannot_instantiate_with_device_add_yet = false;
        +DC->user_creatable = true;
        |
        -DC->cannot_instantiate_with_device_add_yet = true;
        +DC->user_creatable = false;
        )
      
        @@
        typedef ObjectClass;
        expression dc;
        identifier class, data;
        @@
         static void device_class_init(ObjectClass *class, void *data)
         {
         ...
         dc->hotpluggable = true;
        +dc->user_creatable = true;
         ...
         }
      
        @@
        @@
         struct DeviceClass {
         ...
        -bool cannot_instantiate_with_device_add_yet;
        +bool user_creatable;
         ...
        }
      
        @@
        expression DC;
        @@
        (
        -!DC->cannot_instantiate_with_device_add_yet
        +DC->user_creatable
        |
        -DC->cannot_instantiate_with_device_add_yet
        +!DC->user_creatable
        )
      
      Cc: Alistair Francis <alistair.francis@xilinx.com>
      Cc: Laszlo Ersek <lersek@redhat.com>
      Cc: Marcel Apfelbaum <marcel@redhat.com>
      Cc: Markus Armbruster <armbru@redhat.com>
      Cc: Peter Maydell <peter.maydell@linaro.org>
      Cc: Thomas Huth <thuth@redhat.com>
      Acked-by: default avatarAlistair Francis <alistair.francis@xilinx.com>
      Reviewed-by: default avatarThomas Huth <thuth@redhat.com>
      Reviewed-by: default avatarMarcel Apfelbaum <marcel@redhat.com>
      Acked-by: default avatarMarcel Apfelbaum <marcel@redhat.com>
      Signed-off-by: default avatarEduardo Habkost <ehabkost@redhat.com>
      Message-Id: <20170503203604.31462-2-ehabkost@redhat.com>
      [ehabkost: kept "TODO remove once we're there" comment]
      Reviewed-by: default avatarMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: default avatarEduardo Habkost <ehabkost@redhat.com>
      e90f2a8c
  22. Apr 21, 2017
  23. Feb 28, 2017
  24. Jan 27, 2017
  25. Jan 24, 2017
  26. Nov 22, 2016
  27. Sep 23, 2016
  28. Mar 22, 2016
  29. Mar 16, 2016
Loading