Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 07 7月, 2015 2 次提交
  3. 29 4月, 2015 3 次提交
    • A
      vfio-pci: Reset workaround for AMD Bonaire and Hawaii GPUs · 5655f931
      由 Alex Williamson 提交于 
      Somehow these GPUs manage not to respond to a PCI bus reset, removing
our primary mechanism for resetting graphics cards.  The result is
that these devices typically work well for a single VM boot.  If the
VM is rebooted or restarted, the guest driver is not able to init the
card from the dirty state, resulting in a blue screen for Windows
guests.

The workaround is to use a device specific reset.  This is not 100%
reliable though since it depends on the incoming state of the device,
but it substantially improves the usability of these devices in a VM.

Credit to Alex Deucher <alexander.deucher@amd.com> for his guidance.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      5655f931
    • A
      vfio-pci: Fix error path sign · c6d231e2
      由 Alex Williamson 提交于 
      This is an impossible error path due to the fact that we're reading a
kernel provided, rather than user provided link, which will certainly
always fit in PATH_MAX.  Currently it returns a fixed 26 char path
plus %d group number, which typically maxes out at double digits.
However, the caller of the initfn certainly expects a less-than zero
return value on error, not just a non-zero value.  Therefore we
should correct the sign here.
Reported-by: NLaszlo Ersek <lersek@redhat.com>
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      c6d231e2
    • A
      vfio-pci: Further fix BAR size overflow · 07ceaf98
      由 Alex Williamson 提交于 
      In an analysis by Laszlo, the resulting type of our calculation for
the end of the MSI-X table, and thus the start of memory after the
table, is uint32_t.  We're therefore not correctly preventing the
corner case overflow that we intended to fix here where a BAR >=4G
could place the MSI-X table to end exactly at the 4G boundary.  The
MSI-X table offset is defined by the hardware spec to 32bits, so we
simply use a cast rather than changing data structure types.  This
scenario is purely theoretically, typically the MSI-X table is located
at the front of the BAR.
Reported-by: NLaszlo Ersek <lersek@redhat.com>
Reviewed-by: NLaszlo Ersek <lersek@redhat.com>
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      07ceaf98
  5. 26 4月, 2015 1 次提交
  7. 03 3月, 2015 2 次提交
  9. 11 2月, 2015 4 次提交
    • A
      vfio: Fix debug message compile error · bc5baffa
      由 Alexey Kardashevskiy 提交于 
      This fixes a compiler error which occurs if DEBUG_VFIO is defined.
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      bc5baffa
    • P
      vfio: unmap and free BAR data in instance_finalize · ba5e6bfa
      由 Paolo Bonzini 提交于 
      In the case of VFIO, the unrealize callback is too early to munmap the
BARs.  The munmap must be delayed until memory accesses are complete.
To do this, split vfio_unmap_bars in two.  The removal step, now called
vfio_unregister_bars, remains in vfio_exitfn.  The reclamation step
is vfio_unmap_bars and is moved to the instance_finalize callback.

Similarly, quirk MemoryRegions have to be removed during
vfio_unregister_bars, but freeing the data structure must be delayed
to vfio_unmap_bars.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      ba5e6bfa
    • P
      vfio: free dynamically-allocated data in instance_finalize · 77a10d04
      由 Paolo Bonzini 提交于 
      In order to enable out-of-BQL address space lookup, destruction of
devices needs to be split in two phases.

Unrealize is the first phase; once it complete no new accesses will
be started, but there may still be pending memory accesses can still
be completed.

The second part is freeing the device, which only happens once all memory
accesses are complete.  At this point the reference count has dropped to
zero, an RCU grace period must have completed (because the RCU-protected
FlatViews hold a reference to the device via memory_region_ref).  This is
when instance_finalize is called.

Freeing data belongs in an instance_finalize callback, because the
dynamically allocated memory can still be used after unrealize by the
pending memory accesses.

This starts the process by creating an instance_finalize callback and
freeing most of the dynamically-allocated data in instance_finalize.
Because instance_finalize is also called on error paths or also when
the device is actually not realized, the common code needs some changes
to be ready for this.  The error path in vfio_initfn can be simplified too.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      77a10d04
    • P
      vfio: cleanup vfio_get_device error path, remove vfio_populate_device callback · 217e9fdc
      由 Paolo Bonzini 提交于 
      Now that vfio_put_base_device is called unconditionally at instance_finalize
time, it can be called twice if vfio_populate_device fails.  This works
but it is slightly harder to follow.

Change vfio_get_device to not touch the vbasedev struct until it will
definitely succeed, moving the vfio_populate_device call back to vfio-pci.
This way, vfio_put_base_device will only be called once.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      217e9fdc
  11. 05 2月, 2015 1 次提交
  13. 09 1月, 2015 2 次提交
    • A
      vfio-pci: Fix interrupt disabling · b3e27c3a
      由 Alex Williamson 提交于 
      When disabling MSI/X interrupts the disable functions will leave the
device in INTx mode (when available).  This matches how hardware
operates, INTx is enabled unless MSI/X is enabled (DisINTx is handled
separately).  Therefore when we really want to disable all interrupts,
such as when removing the device, and we start with the device in
MSI/X mode, we need to pass through INTx on our way to being
completely quiesced.

In well behaved situations, the guest driver will have shutdown the
device and it will start vfio_exitfn() in INTx mode, producing the
desired result.  If hot-unplug causes the guest to crash, we may get
the device in MSI/X state, which will leave QEMU with a bogus handler
installed.

Fix this by re-ordering our disable routine so that it should always
finish in VFIO_INT_NONE state, which is what all callers expect.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      b3e27c3a
    • A
      vfio-pci: Fix BAR size overflow · 29c6e6df
      由 Alex Williamson 提交于 
      We use an unsigned int when working with the PCI BAR size, which can
obviously overflow if the BAR is 4GB or larger.  This needs to change
to a fixed length uint64_t.  A similar issue is possible, though even
more unlikely, when mapping the region above an MSI-X table.  The
start of the MSI-X vector table must be below 4GB, but the end, and
therefore the start of the next mapping region, could still land at
4GB.
Suggested-by: NNishank Trivedi <nishank.trivedi@netapp.com>
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Reviewed-by: NDon Slutz <dslutz@verizon.com>
Tested-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
      29c6e6df
  15. 23 12月, 2014 8 次提交
  17. 20 12月, 2014 6 次提交
  19. 15 12月, 2014 1 次提交
  21. 31 10月, 2014 1 次提交
  23. 15 10月, 2014 2 次提交
  25. 23 9月, 2014 2 次提交
  27. 26 8月, 2014 1 次提交
  29. 18 8月, 2014 2 次提交
  31. 06 8月, 2014 2 次提交
    • A
      vfio: Don't cache MSIMessage · 9b3af4c0
      由 Alex Williamson 提交于 
      Commit 40509f7f added a test to avoid updating KVM MSI routes when the
MSIMessage is unchanged and f4d45d47 switched to relying on this
rather than doing our own comparison.  Our cached msg is effectively
unused now.  Remove it.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      9b3af4c0
    • A
      vfio: Fix MSI-X vector expansion · c048be5c
      由 Alex Williamson 提交于 
      When new MSI-X vectors are enabled we need to disable MSI-X and
re-enable it with the correct number of vectors.  That means we need
to reprogram the eventfd triggers for each vector.  Prior to f4d45d47
vector->use tracked whether a vector was masked or unmasked and we
could always pick the KVM path when available for unmasked vectors.
Now vfio doesn't track mask state itself and vector->use and virq
remains configured even for masked vectors.  Therefore we need to ask
the MSI-X code whether a vector is masked in order to select the
correct signaling path.  As noted in the comment, MSI relies on
hardware to handle masking.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Cc: qemu-stable@nongnu.org # QEMU 2.1
      c048be5c