1. 15 1月, 2019 1 次提交
  2. 21 12月, 2018 2 次提交
  3. 20 12月, 2018 1 次提交
    • A
      pci: Sync PCIe downstream port LNKSTA on read · 727b4866
      Alex Williamson 提交于
      The PCIe link speed and width between a downstream device and its
      upstream port is negotiated on real hardware and susceptible to
      dynamic changes due to signal issues and power management.  In the
      emulated device case there is no real hardware link, but we still
      might wish to have some consistency between endpoint and downstream
      port via a virtual negotiation.  There is of course a real link for
      assigned devices and this same virtual negotiation allows the
      downstream port to match the endpoint, synchronizing on every read
      to support underlying physical hardware dynamically adjusting the
      link.
      
      This negotiation is intentionally unidirectional for compatibility.
      If the endpoint exceeds the capabilities of the downstream port or
      there is no endpoint device, the downstream port reports negotiation
      to its maximum speed and width, matching the previous case where
      negotiation was absent.  De-tuning the endpoint to match a virtual
      link doesn't seem to benefit anyone and is a condition we've thus
      far reported without functional issues.
      
      Note that PCI_EXP_LNKSTA is already ignored for migration
      compatibility via pcie_cap_v1_fill().
      
      Cc: Marcel Apfelbaum <marcel.apfelbaum@gmail.com>
      Tested-by: NGeoffrey McRae <geoff@hostfission.com>
      Reviewed-by: NEric Auger <eric.auger@redhat.com>
      Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      727b4866
  4. 04 7月, 2017 1 次提交
  5. 16 3月, 2017 2 次提交
  6. 25 1月, 2017 1 次提交
    • D
      PCI/migration merge vmstate_pci_device and vmstate_pcie_device · 20daa90a
      Dr. David Alan Gilbert 提交于
      The vmstate_pci_device and vmstate_pcie_devices differ
      just in the size of one buffer; combine the two using a _TEST
      macro.
      
      I think this is safe as long as everywhere which currently
      uses either of these two uses the right type.
      
      One thing that concerns me is that some places use pci_device_load/save
      which does some irq mangling, but others just use the VMSTATE_PCI_DEVICE
      macro - how are they getting the same irq mangling?
      
      This passes a smoke test migrate of:
      ./x86_64-softmmu/qemu-system-x86_64 -M pc,accel=kvm -m 1024
      ./littlefed20.img -device e1000e -device virtio-net -device
      e1000 -device virtio-rng -device megasas -device megasas-gen2 -device
      ioh3420 -device nec-usb-xhci
      
      to an unmodified qemu.
      Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
      Message-Id: <20161214195829.18241-1-dgilbert@redhat.com>
      Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: NDr. David Alan Gilbert <dgilbert@redhat.com>
      20daa90a
  7. 10 1月, 2017 1 次提交
  8. 02 6月, 2016 2 次提交
  9. 15 10月, 2014 1 次提交
  10. 25 8月, 2014 1 次提交
  11. 23 6月, 2014 1 次提交
  12. 10 2月, 2014 1 次提交
  13. 14 10月, 2013 1 次提交
  14. 09 4月, 2013 1 次提交
    • P
      hw: move headers to include/ · 0d09e41a
      Paolo Bonzini 提交于
      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: NPaolo Bonzini <pbonzini@redhat.com>
      0d09e41a
  15. 27 3月, 2013 1 次提交
  16. 17 12月, 2012 2 次提交
  17. 07 9月, 2012 1 次提交
    • J
      pcie: drop version_id field for live migration · 1de53459
      Jason Baron 提交于
      While testing q35 live migration, I found that the migration would abort with
      the following error: "Unknown savevm section type 76".
      
      The error is due to this check failing in 'vmstate_load_state()':
      
          while(field->name) {
              if ((field->field_exists &&
                   field->field_exists(opaque, version_id)) ||
                  (!field->field_exists &&
                   field->version_id <= version_id)) {
      
      The VMSTATE_PCIE_DEVICE() currently has a 'version_id' set to 2. However,
      'version_id' in the above check is 1. And thus we fail to load the pcie device
      field. Further the code returns to 'qemu_loadvm_state()' which produces the
      error that I saw.
      
      I'm proposing to fix this by simply dropping the 'version_id' field from
      VMSTATE_PCIE_DEVICE(). VMSTATE_PCI_DEVICE() defines no such field and further
      the vmstate_pcie_device that VMSTATE_PCI_DEVICE() refers to is already
      versioned. Thus, any versioning issues could be detected at the vmsd level.
      
      Taking a step back, I think that the 'field->version_id' should be compared
      against a saved version number for the field not the 'version_id'. Futhermore,
      once vmstate_load_state() is called recursively on another vmsd, the check of:
      
          if (version_id > vmsd->version_id) {
              return -EINVAL;
          }
      
      Will never fail since version_id is always equal to vmsd->version_id. So I'm
      wondering why we aren't storing the vmsd version id of the source in the
      migration stream?
      
      This patch also renames the 'name' field of vmstate_pcie_device from:
      PCIDevice -> PCIEDevice to differentiate it from vmstate_pci_device.
      Signed-off-by: NJason Baron <jbaron@redhat.com>
      Signed-off-by: NMichael S. Tsirkin <mst@redhat.com>
      1de53459
  18. 14 1月, 2012 1 次提交
  19. 08 5月, 2011 1 次提交
  20. 22 12月, 2010 1 次提交
  21. 22 11月, 2010 1 次提交
  22. 28 10月, 2010 1 次提交
  23. 20 10月, 2010 1 次提交
  24. 19 10月, 2010 1 次提交