Skip to content

Q
qemu

openeuler / qemu

通知 10
Star 0
Fork 0
Q
qemu

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

切换分支/标签
  1. 31 10月, 2014 1 次提交
  3. 15 10月, 2014 2 次提交
  5. 23 9月, 2014 2 次提交
  7. 26 8月, 2014 1 次提交
  9. 18 8月, 2014 2 次提交
  11. 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
  13. 15 7月, 2014 1 次提交
  15. 30 6月, 2014 4 次提交
    • P
      vfio: use correct runstate · ba29776f
      由 Paolo Bonzini 提交于 
      io-error is for block device errors; it should always be preceded
by a BLOCK_IO_ERROR event.  I think vfio wants to use
RUN_STATE_INTERNAL_ERROR instead.
Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com>
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      ba29776f
    • A
      vfio: Make BARs native endian · c4070817
      由 Alexey Kardashevskiy 提交于 
      Slow BAR access path is used when VFIO fails to mmap() BAR.
Since this is just a transport between the guest and a device, there is
no need to do endianness swapping.

This changes BARs to use native endianness. Since non-ROM BARs were
doing byte swapping, we need to remove it so does the patch.
As the result, this eliminates cancelling byte swaps and there is
no change in behavior for non-ROM BARs.

ROM BARs were declared little endian too but byte swapping was not
implemented for them so they never actually worked on big endian systems
as there was no cancelling byte swap. This fixes endiannes for ROM BARs
by declaring them native endian and only fixing access sizes as it is
done for non-ROM BARs.
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      c4070817
    • A
      vfio-pci: Fix MSI-X masking performance · f4d45d47
      由 Alex Williamson 提交于 
      There are still old guests out there that over-exercise MSI-X masking.
The current code completely sets-up and tears-down an MSI-X vector on
the "use" and "release" callbacks.  While this is functional, it can
slow an old guest to a crawl.  We can easily skip the KVM parts of
this so that we keep the MSI route and irqfd setup.  We do however
need to switch VFIO to trigger a different eventfd while masked.
Actually, we have the option of continuing to use -1 to disable the
trigger, but by using another EventNotifier we can allow the MSI-X
core to emulate pending bits and re-fire the vector once unmasked.
MSI code gets updated as well to use the same setup and teardown
structures and functions.

Prior to this change, an igbvf assigned to a RHEL5 guest gets about
20Mbps and 50 transactions/s with netperf (remote or VF->PF).  With
this change, we get line rate and 3k transactions/s remote or 2Gbps
and 6k+ transactions/s to the PF.  No significant change is expected
for newer guests with more well behaved MSI-X support.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      f4d45d47
    • A
      vfio-pci: Fix MSI/X debug code · 9035f8c0
      由 Alex Williamson 提交于 
      Use the correct MSI message function for debug info.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      9035f8c0
  17. 27 6月, 2014 2 次提交
    • A
      vfio: Enable for SPAPR · 59181263
      由 Alexey Kardashevskiy 提交于 
      This turns the sPAPR support on and enables VFIO container use
in the kernel.

This extends vfio_connect_container to support VFIO_SPAPR_TCE_IOMMU type
in the host kernel.

This registers a memory listener which sPAPR IOMMU will notify when
executing H_PUT_TCE/etc DMA calls. The listener then will notify the host
kernel about DMA map/unmap operation via VFIO_IOMMU_MAP_DMA/
VFIO_IOMMU_UNMAP_DMA ioctls.

This executes VFIO_IOMMU_ENABLE ioctl to make sure that the IOMMU is free
of mappings and can be exclusively given to the user. At the moment SPAPR
is the only platform requiring this call to be implemented.

Note that the host kernel function implementing VFIO_IOMMU_DISABLE
is called automatically when container's fd is closed so there is
no need to call it explicitly from QEMU. We may need to call
VFIO_IOMMU_DISABLE explicitly in the future for some sort of dynamic
reconfiguration (PCI hotplug or dynamic IOMMU group management).
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Acked-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      59181263
    • A
      vfio: Add vfio_container_ioctl() · 6d8be4c3
      由 Alexey Kardashevskiy 提交于 
      While most operations with VFIO IOMMU driver are generic and used inside
vfio.c, there are still some operations which only specific VFIO IOMMU
drivers implement. The first example of it will be reading a DMA window
start from the host.

This adds a helper which passes an ioctl request to the container's fd.

The helper will check if @req is known. For this, stub is added. This return
-1 on any requests for now.
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Acked-by: NAlex Williamson <alex.williamson@redhat.com>
Acked-by: NAlex Williamson <alex.williamson@redhat.com>
Signed-off-by: NAlexander Graf <agraf@suse.de>
      6d8be4c3
  19. 31 5月, 2014 6 次提交
  21. 26 3月, 2014 1 次提交
  23. 25 3月, 2014 1 次提交
  25. 27 2月, 2014 2 次提交
  27. 28 1月, 2014 1 次提交
  29. 18 1月, 2014 1 次提交
    • A
      vfio: fix mapping of MSIX bar · 8d7b5a1d
      由 Alexey Kardashevskiy 提交于 
      VFIO virtualizes MSIX table for the guest but not mapping the part of
a BAR which contains an MSIX table. Since vfio_mmap_bar() mmaps chunks
before and after the MSIX table, they have to be aligned to the host
page size which may be TARGET_PAGE_MASK (4K) or 64K in case of PPC64.

This fixes boundaries calculations to use the real host page size.

Without the patch, the chunk before MSIX table may overlap with the MSIX
table and mmap will fail in the host kernel. The result will be serious
slowdown as the whole BAR will be emulated by QEMU.
Signed-off-by: NAlexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      8d7b5a1d
  31. 17 1月, 2014 2 次提交
    • A
      vfio-pci: Fail initfn on DMA mapping errors · 87ca1f77
      由 Alex Williamson 提交于 
      The vfio-pci initfn will currently succeed even if DMA mappings fail.
A typical reason for failure is if the user does not have sufficient
privilege to lock all the memory for the guest.  In this case, the
device gets attached, but can only access a portion of guest memory
and is extremely unlikely to work.

DMA mappings are done via a MemoryListener, which provides no direct
error return path.  We therefore stuff the errno into our container
structure and check for error after registration completes.  We can
also test for mapping errors during runtime, but our only option for
resolution at that point is to kill the guest with a hw_error.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
      87ca1f77
    • A
      vfio: Filter out bogus mappings · d3a2fd9b
      由 Alex Williamson 提交于 
      Since 57271d63 we now see spurious mappings with the upper bits set
if 64bit PCI BARs are sized while enabled.  The guest writes a mask
of 0xffffffff to the lower BAR to size it, then restores it, then
writes the same mask to the upper BAR resulting in a spurious BAR
mapping into the last 4G of the 64bit address space.  Most
architectures do not support or make use of the full 64bits address
space for PCI BARs, so we filter out mappings with the high bit set.
Long term, we probably need to think about vfio telling us the
address width limitations of the IOMMU.
Signed-off-by: NAlex Williamson <alex.williamson@redhat.com>
Reviewed-by: NMichael S. Tsirkin <mst@redhat.com>
      d3a2fd9b
  33. 16 1月, 2014 3 次提交
  35. 07 12月, 2013 4 次提交
  37. 22 11月, 2013 2 次提交