1. 31 7月, 2017 1 次提交
  2. 28 7月, 2017 1 次提交
  3. 18 7月, 2017 3 次提交
  4. 17 7月, 2017 1 次提交
    • P
      qdev: support properties which don't set a default value · 5cc56cc6
      Peter Maydell 提交于
      In some situations it's useful to have a qdev property which doesn't
      automatically set its default value when qdev_property_add_static is
      called (for instance when the default value is not constant).
      
      Support this by adding a flag to the Property struct indicating
      whether to set the default value.  This replaces the existing test
      for whether the PropertyInfo set_default_value function pointer is
      NULL, and we set the .set_default field to true for all those cases
      of struct Property which use a PropertyInfo with a non-NULL
      set_default_value, so behaviour remains the same as before.
      
      This gives us the semantics of:
       * if .set_default is true, then .info->set_default_value must
         be not NULL, and .defval is used as the the default value of
         the property
       * otherwise, the property system does not set any default, and
         the field will retain whatever initial value it was given by
         the device's .instance_init method
      
      We define two new macros DEFINE_PROP_SIGNED_NODEFAULT and
      DEFINE_PROP_UNSIGNED_NODEFAULT, to cover the most plausible use cases
      of wanting to set an integer property with no default value.
      Suggested-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NPeter Maydell <peter.maydell@linaro.org>
      Reviewed-by: NMarc-André Lureau <marcandre.lureau@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Message-id: 1499788408-10096-3-git-send-email-peter.maydell@linaro.org
      5cc56cc6
  5. 14 7月, 2017 4 次提交
  6. 13 7月, 2017 2 次提交
  7. 11 7月, 2017 2 次提交
  8. 28 6月, 2017 2 次提交
  9. 20 6月, 2017 3 次提交
  10. 19 6月, 2017 1 次提交
  11. 06 6月, 2017 2 次提交
    • I
      numa: make sure that all cpus have has_node_id set if numa is enabled · d41f3e75
      Igor Mammedov 提交于
      It fixes/add missing _PXM object for non mapped CPU (x86)
      and missing fdt node (virt-arm).
      
      It ensures that possible_cpus contains complete mapping if
      numa is enabled by the time machine_init() is executed.
      
      As result non completely mapped CPUs:
       1) appear in ACPI/fdt blobs
       2) QMP query-hotpluggable-cpus command shows bound nodes for such CPUs
       3) allows to drop checks for has_node_id in numa only code,
         reducing number of invariants incomplete mapping could produce
       4) moves fixup/implicit node init from runtime numa_cpu_pre_plug()
         (when CPU object is created) to machine_numa_finish_init() which
         helps to fix [1, 2] and make possible_cpus complete source
         of numa mapping available even before CPUs are created.
      Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
      Message-Id: <1496161442-96665-4-git-send-email-imammedo@redhat.com>
      Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      d41f3e75
    • I
      numa: move default mapping init to machine · 60bed6a3
      Igor Mammedov 提交于
      there is no need use cpu_index_to_instance_props() for setting
      default cpu -> node mapping. Generic machine code can do it
      without cpu_index by just enabling already preset defaults
      in possible_cpus.
      
      PS:
      as bonus it makes one less user of cpu_index_to_instance_props()
      Signed-off-by: NIgor Mammedov <imammedo@redhat.com>
      Message-Id: <1496161442-96665-3-git-send-email-imammedo@redhat.com>
      Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      60bed6a3
  12. 05 6月, 2017 1 次提交
  13. 04 6月, 2017 1 次提交
  14. 02 6月, 2017 5 次提交
  15. 23 5月, 2017 1 次提交
  16. 17 5月, 2017 3 次提交
    • E
      sysbus: Set user_creatable=false by default on TYPE_SYS_BUS_DEVICE · e4f4fb1e
      Eduardo Habkost 提交于
      commit 33cd52b5 unset
      cannot_instantiate_with_device_add_yet in TYPE_SYSBUS, making all
      sysbus devices appear on "-device help" and lack the "no-user"
      flag in "info qdm".
      
      To fix this, we can set user_creatable=false by default on
      TYPE_SYS_BUS_DEVICE, but this requires setting
      user_creatable=true explicitly on the sysbus devices that
      actually work with -device.
      
      Fortunately today we have just a few has_dynamic_sysbus=1
      machines: virt, pc-q35-*, ppce500, and spapr.
      
      virt, ppce500, and spapr have extra checks to ensure just a few
      device types can be instantiated:
      
      * virt supports only TYPE_VFIO_CALXEDA_XGMAC, TYPE_VFIO_AMD_XGBE.
      * ppce500 supports only TYPE_ETSEC_COMMON.
      * spapr supports only TYPE_SPAPR_PCI_HOST_BRIDGE.
      
      This patch sets user_creatable=true explicitly on those 4 device
      classes.
      
      Now, the more complex cases:
      
      pc-q35-*: q35 has no sysbus device whitelist yet (which is a
      separate bug). We are in the process of fixing it and building a
      sysbus whitelist on q35, but in the meantime we can fix the
      "-device help" and "info qdm" bugs mentioned above. Also, despite
      not being strictly necessary for fixing the q35 bug, reducing the
      list of user_creatable=true devices will help us be more
      confident when building the q35 whitelist.
      
      xen: We also have a hack at xen_set_dynamic_sysbus(), that sets
      has_dynamic_sysbus=true at runtime when using the Xen
      accelerator. This hack is only used to allow xen-backend devices
      to be dynamically plugged/unplugged.
      
      This means today we can use -device with the following 22 device
      types, that are the ones compiled into the qemu-system-x86_64 and
      qemu-system-i386 binaries:
      
      * allwinner-ahci
      * amd-iommu
      * cfi.pflash01
      * esp
      * fw_cfg_io
      * fw_cfg_mem
      * generic-sdhci
      * hpet
      * intel-iommu
      * ioapic
      * isabus-bridge
      * kvmclock
      * kvm-ioapic
      * kvmvapic
      * SUNW,fdtwo
      * sysbus-ahci
      * sysbus-fdc
      * sysbus-ohci
      * unimplemented-device
      * virtio-mmio
      * xen-backend
      * xen-sysdev
      
      This patch adds user_creatable=true explicitly to those devices,
      temporarily, just to keep 100% compatibility with existing
      behavior of q35. Subsequent patches will remove
      user_creatable=true from the devices that are really not meant to
      user-creatable on any machine, and remove the FIXME comment from
      the ones that are really supposed to be user-creatable. This is
      being done in separate patches because we still don't have an
      obvious list of devices that will be whitelisted by q35, and I
      would like to get each device reviewed individually.
      
      Cc: Alexander Graf <agraf@suse.de>
      Cc: Alex Williamson <alex.williamson@redhat.com>
      Cc: Alistair Francis <alistair.francis@xilinx.com>
      Cc: Beniamino Galvani <b.galvani@gmail.com>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
      Cc: David Gibson <david@gibson.dropbear.id.au>
      Cc: "Edgar E. Iglesias" <edgar.iglesias@gmail.com>
      Cc: Eduardo Habkost <ehabkost@redhat.com>
      Cc: Frank Blaschka <frank.blaschka@de.ibm.com>
      Cc: Gabriel L. Somlo <somlo@cmu.edu>
      Cc: Gerd Hoffmann <kraxel@redhat.com>
      Cc: Igor Mammedov <imammedo@redhat.com>
      Cc: Jason Wang <jasowang@redhat.com>
      Cc: John Snow <jsnow@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Kevin Wolf <kwolf@redhat.com>
      Cc: Laszlo Ersek <lersek@redhat.com>
      Cc: Marcel Apfelbaum <marcel@redhat.com>
      Cc: Markus Armbruster <armbru@redhat.com>
      Cc: Max Reitz <mreitz@redhat.com>
      Cc: "Michael S. Tsirkin" <mst@redhat.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Peter Maydell <peter.maydell@linaro.org>
      Cc: Pierre Morel <pmorel@linux.vnet.ibm.com>
      Cc: Prasad J Pandit <pjp@fedoraproject.org>
      Cc: qemu-arm@nongnu.org
      Cc: qemu-block@nongnu.org
      Cc: qemu-ppc@nongnu.org
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Rob Herring <robh@kernel.org>
      Cc: Shannon Zhao <zhaoshenglong@huawei.com>
      Cc: sstabellini@kernel.org
      Cc: Thomas Huth <thuth@redhat.com>
      Cc: Yi Min Zhao <zyimin@linux.vnet.ibm.com>
      Acked-by: NJohn Snow <jsnow@redhat.com>
      Acked-by: NJuergen Gross <jgross@suse.com>
      Acked-by: NMarcel Apfelbaum <marcel@redhat.com>
      Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      Message-Id: <20170503203604.31462-3-ehabkost@redhat.com>
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      [ehabkost: Small changes at sysbus_device_class_init() comments]
      Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      e4f4fb1e
    • E
      qdev: Replace cannot_instantiate_with_device_add_yet with !user_creatable · e90f2a8c
      Eduardo Habkost 提交于
      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: NAlistair Francis <alistair.francis@xilinx.com>
      Reviewed-by: NThomas Huth <thuth@redhat.com>
      Reviewed-by: NMarcel Apfelbaum <marcel@redhat.com>
      Acked-by: NMarcel Apfelbaum <marcel@redhat.com>
      Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      Message-Id: <20170503203604.31462-2-ehabkost@redhat.com>
      [ehabkost: kept "TODO remove once we're there" comment]
      Reviewed-by: NMarkus Armbruster <armbru@redhat.com>
      Signed-off-by: NEduardo Habkost <ehabkost@redhat.com>
      e90f2a8c
    • J
      migration: Move check_migratable() into qdev.c · 1bfe5f05
      Juan Quintela 提交于
      The function is only used once, and nothing else in migration knows
      about objects.  Create the function vmstate_device_is_migratable() in
      savem.c that really do the bit that is related with migration.
      Signed-off-by: NJuan Quintela <quintela@redhat.com>
      Reviewed-by: NPeter Xu <peterx@redhat.com>
      1bfe5f05
  17. 12 5月, 2017 4 次提交
  18. 10 5月, 2017 1 次提交
  19. 21 4月, 2017 2 次提交