aboutsummaryrefslogtreecommitdiff
path: root/hw/vfio
AgeCommit message (Collapse)AuthorFilesLines
2017-07-14memory/iommu: QOM'fy IOMMU MemoryRegionAlexey Kardashevskiy2-6/+9
This defines new QOM object - IOMMUMemoryRegion - with MemoryRegion as a parent. This moves IOMMU-related fields from MR to IOMMU MR. However to avoid dymanic QOM casting in fast path (address_space_translate, etc), this adds an @is_iommu boolean flag to MR and provides new helper to do simple cast to IOMMU MR - memory_region_get_iommu. The flag is set in the instance init callback. This defines memory_region_is_iommu as memory_region_get_iommu()!=NULL. This switches MemoryRegion to IOMMUMemoryRegion in most places except the ones where MemoryRegion may be an alias. Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Message-Id: <20170711035620.4232-2-aik@ozlabs.ru> Acked-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-07-10vfio/pci: Fixup v0 PCIe capabilitiesAlex Williamson1-0/+12
Intel 82599 VFs report a PCIe capability version of 0, which is invalid. The earliest version of the PCIe spec used version 1. This causes Windows to fail startup on the device and it will be disabled with error code 10. Our choices are either to drop the PCIe cap on such devices, which has the side effect of likely preventing the guest from discovering any extended capabilities, or performing a fixup to update the capability to the earliest valid version. This implements the latter. Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2017-07-10vfio: Test realized when using VFIOGroup.device_list iteratorAlex Williamson3-4/+10
VFIOGroup.device_list is effectively our reference tracking mechanism such that we can teardown a group when all of the device references are removed. However, we also use this list from our machine reset handler for processing resets that affect multiple devices. Generally device removals are fully processed (exitfn + finalize) when this reset handler is invoked, however if the removal is triggered via another reset handler (piix4_reset->acpi_pcihp_reset) then the device exitfn may run, but not finalize. In this case we hit asserts when we start trying to access PCI helpers since much of the PCI state of the device is released. To resolve this, add a pointer to the Object DeviceState in our common base-device and skip non-realized devices as we iterate. Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2017-07-03pci: Replace pci_add_capability2() with pci_add_capability()Mao Zhongyi1-3/+3
After the patch 'Make errp the last parameter of pci_add_capability()', pci_add_capability() and pci_add_capability2() now do exactly the same. So drop the wrapper pci_add_capability() of pci_add_capability2(), then replace the pci_add_capability2() with pci_add_capability() everywhere. Cc: pbonzini@redhat.com Cc: rth@twiddle.net Cc: ehabkost@redhat.com Cc: mst@redhat.com Cc: dmitry@daynix.com Cc: jasowang@redhat.com Cc: marcel@redhat.com Cc: alex.williamson@redhat.com Cc: armbru@redhat.com Suggested-by: Eduardo Habkost <ehabkost@redhat.com> Signed-off-by: Mao Zhongyi <maozy.fnst@cn.fujitsu.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-07-03pci: Make errp the last parameter of pci_add_capability()Mao Zhongyi1-3/+6
Add Error argument for pci_add_capability() to leverage the errp to pass info on errors. This way is helpful for its callers to make a better error handling when moving to 'realize'. Cc: pbonzini@redhat.com Cc: rth@twiddle.net Cc: ehabkost@redhat.com Cc: mst@redhat.com Cc: jasowang@redhat.com Cc: marcel@redhat.com Cc: alex.williamson@redhat.com Cc: armbru@redhat.com Signed-off-by: Mao Zhongyi <maozy.fnst@cn.fujitsu.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-07-03pci: Fix the wrong assertion.Mao Zhongyi1-1/+1
pci_add_capability returns a strictly positive value on success, correct asserts. Cc: dmitry@daynix.com Cc: jasowang@redhat.com Cc: kraxel@redhat.com Cc: alex.williamson@redhat.com Cc: armbru@redhat.com Cc: marcel@redhat.com Signed-off-by: Mao Zhongyi <maozy.fnst@cn.fujitsu.com> Reviewed-by: Marcel Apfelbaum <marcel@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-05-30Merge remote-tracking branch 'mst/tags/for_upstream' into stagingStefan Hajnoczi1-1/+1
pci, virtio, vhost: fixes A bunch of fixes all over the place. Most notably this fixes the new MTU feature when using vhost. Signed-off-by: Michael S. Tsirkin <mst@redhat.com> # gpg: Signature made Mon 29 May 2017 01:10:24 AM BST # gpg: using RSA key 0x281F0DB8D28D5469 # gpg: Good signature from "Michael S. Tsirkin <mst@kernel.org>" # gpg: aka "Michael S. Tsirkin <mst@redhat.com>" # Primary key fingerprint: 0270 606B 6F3C DF3D 0B17 0970 C350 3912 AFBE 8E67 # Subkey fingerprint: 5D09 FD08 71C8 F85B 94CA 8A0D 281F 0DB8 D28D 5469 * mst/tags/for_upstream: acpi-test: update expected files pc: ACPI BIOS: use highest NUMA node for hotplug mem hole SRAT entry vhost-user: pass message as a pointer to process_message_reply() virtio_net: Bypass backends for MTU feature negotiation intel_iommu: turn off pt before 2.9 intel_iommu: support passthrough (PT) intel_iommu: allow dev-iotlb context entry conditionally intel_iommu: use IOMMU_ACCESS_FLAG() intel_iommu: provide vtd_ce_get_type() intel_iommu: renaming context entry helpers x86-iommu: use DeviceClass properties memory: remove the last param in memory_region_iommu_replay() memory: tune last param of iommu_ops.translate() Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-05-25memory: remove the last param in memory_region_iommu_replay()Peter Xu1-1/+1
We were always passing in that one as "false" to assume that's an read operation, and we also assume that IOMMU translation would always have that read permission. A better permission would be IOMMU_NONE since the replay is after all not a real read operation, but just a page table rebuilding process. CC: David Gibson <david@gibson.dropbear.id.au> CC: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Reviewed-by: Jason Wang <jasowang@redhat.com>
2017-05-19vfio/ccw: update sense data if a unit check is pendingDong Jia Shi1-0/+7
Concurrent-sense data is currently not delivered. This patch stores the concurrent-sense data to the subchannel if a unit check is pending and the concurrent-sense bit is enabled. Then a TSCH can retreive the right IRB data back to the guest. Acked-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Message-Id: <20170517004813.58227-13-bjsdjshi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2017-05-19s390x/css: introduce and realize ccw-request callbackXiao Feng Ren1-0/+85
Introduce a new callback on subchannel to handle ccw-request. Realize the callback in vfio-ccw device. Besides, resort to the event notifier handler to handling the ccw-request results. 1. Pread the I/O results via MMIO region. 2. Update the scsw info to guest. 3. Inject an I/O interrupt to notify guest the I/O result. Acked-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Xiao Feng Ren <renxiaof@linux.vnet.ibm.com> Signed-off-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Message-Id: <20170517004813.58227-11-bjsdjshi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2017-05-19vfio/ccw: get irqs info and set the eventfd fdDong Jia Shi1-0/+101
vfio-ccw resorts to the eventfd mechanism to communicate with userspace. We fetch the irqs info via the ioctl VFIO_DEVICE_GET_IRQ_INFO, register a event notifier to get the eventfd fd which is sent to kernel via the ioctl VFIO_DEVICE_SET_IRQS, then we can implement read operation once kernel sends the signal. Reviewed-by: Eric Auger <eric.auger@redhat.com> Acked-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Message-Id: <20170517004813.58227-10-bjsdjshi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2017-05-19vfio/ccw: get io region infoDong Jia Shi1-0/+54
vfio-ccw provides an MMIO region for I/O operations. We fetch its information via ioctls here, then we can use it performing I/O instructions and retrieving I/O results later on. Reviewed-by: Eric Auger <eric.auger@redhat.com> Acked-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Message-Id: <20170517004813.58227-9-bjsdjshi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2017-05-19vfio/ccw: vfio based subchannel passthrough driverXiao Feng Ren2-0/+188
We use the IOMMU_TYPE1 of VFIO to realize the subchannels passthrough, implement a vfio based subchannels passthrough driver called "vfio-ccw". Support qemu parameters in the style of: "-device vfio-ccw,sysfsdev=$mdev_file_path,devno=xx.x.xxxx' Reviewed-by: Eric Auger <eric.auger@redhat.com> Acked-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Xiao Feng Ren <renxiaof@linux.vnet.ibm.com> Signed-off-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Message-Id: <20170517004813.58227-8-bjsdjshi@linux.vnet.ibm.com> Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com>
2017-05-17sysbus: Set user_creatable=false by default on TYPE_SYS_BUS_DEVICEEduardo Habkost2-0/+4
commit 33cd52b5d7b9adfd009e95f07e6c64dd88ae2a31 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: John Snow <jsnow@redhat.com> Acked-by: Juergen Gross <jgross@suse.com> Acked-by: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Message-Id: <20170503203604.31462-3-ehabkost@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> [ehabkost: Small changes at sysbus_device_class_init() comments] Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-05-03vfio/pci: Fix incorrect error messageDong Jia Shi1-2/+2
When the "No host device provided" error occurs, the hint message that starts with "Use -vfio-pci," makes no sense, since "-vfio-pci" is not a valid command line parameter. Correct this by replacing "-vfio-pci" with "-device vfio-pci". Signed-off-by: Dong Jia Shi <bjsdjshi@linux.vnet.ibm.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2017-05-03vfio: enable 8-byte reads/writes to vfioJose Ricardo Ziviani1-0/+10
This patch enables 8-byte writes and reads to VFIO. Such implemention is already done but it's missing the 'case' to handle such accesses in both vfio_region_write and vfio_region_read and the MemoryRegionOps: impl.max_access_size and impl.min_access_size. After this patch, 8-byte writes such as: qemu_mutex_lock locked mutex 0x10905ad8 vfio_region_write (0001:03:00.0:region1+0xc0, 0x4140c, 4) vfio_region_write (0001:03:00.0:region1+0xc4, 0xa0000, 4) qemu_mutex_unlock unlocked mutex 0x10905ad8 goes like this: qemu_mutex_lock locked mutex 0x10905ad8 vfio_region_write (0001:03:00.0:region1+0xc0, 0xbfd0008, 8) qemu_mutex_unlock unlocked mutex 0x10905ad8 Signed-off-by: Jose Ricardo Ziviani <joserz@linux.vnet.ibm.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2017-05-03vfio: Set MemoryRegionOps:max_access_size and min_access_sizeJose Ricardo Ziviani1-0/+4
Sets valid.max_access_size and valid.min_access_size to ensure safe 8-byte accesses to vfio. Today, 8-byte accesses are broken into pairs of 4-byte calls that goes unprotected: qemu_mutex_lock locked mutex 0x10905ad8 vfio_region_write (0001:03:00.0:region1+0xc0, 0x2020c, 4) qemu_mutex_unlock unlocked mutex 0x10905ad8 qemu_mutex_lock locked mutex 0x10905ad8 vfio_region_write (0001:03:00.0:region1+0xc4, 0xa0000, 4) qemu_mutex_unlock unlocked mutex 0x10905ad8 which occasionally leads to: qemu_mutex_lock locked mutex 0x10905ad8 vfio_region_write (0001:03:00.0:region1+0xc0, 0x2030c, 4) qemu_mutex_unlock unlocked mutex 0x10905ad8 qemu_mutex_lock locked mutex 0x10905ad8 vfio_region_write (0001:03:00.0:region1+0xc0, 0x1000c, 4) qemu_mutex_unlock unlocked mutex 0x10905ad8 qemu_mutex_lock locked mutex 0x10905ad8 vfio_region_write (0001:03:00.0:region1+0xc4, 0xb0000, 4) qemu_mutex_unlock unlocked mutex 0x10905ad8 qemu_mutex_lock locked mutex 0x10905ad8 vfio_region_write (0001:03:00.0:region1+0xc4, 0xa0000, 4) qemu_mutex_unlock unlocked mutex 0x10905ad8 causing strange errors in guest OS. With this patch, such accesses are protected by the same lock guard: qemu_mutex_lock locked mutex 0x10905ad8 vfio_region_write (0001:03:00.0:region1+0xc0, 0x2000c, 4) vfio_region_write (0001:03:00.0:region1+0xc4, 0xb0000, 4) qemu_mutex_unlock unlocked mutex 0x10905ad8 This happens because the 8-byte write should be broken into 4-byte writes by memory.c:access_with_adjusted_size() in order to be under the same lock. Today, it's done in exec.c:address_space_write_continue() which was able to handle only 4 bytes due to a zero'ed valid.max_access_size (see exec.c:memory_access_size()). Signed-off-by: Jose Ricardo Ziviani <joserz@linux.vnet.ibm.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2017-04-20memory: add section range info for IOMMU notifierPeter Xu1-3/+9
In this patch, IOMMUNotifier.{start|end} are introduced to store section information for a specific notifier. When notification occurs, we not only check the notification type (MAP|UNMAP), but also check whether the notified iova range overlaps with the range of specific IOMMU notifier, and skip those notifiers if not in the listened range. When removing an region, we need to make sure we removed the correct VFIOGuestIOMMU by checking the IOMMUNotifier.start address as well. This patch is solving the problem that vfio-pci devices receive duplicated UNMAP notification on x86 platform when vIOMMU is there. The issue is that x86 IOMMU has a (0, 2^64-1) IOMMU region, which is splitted by the (0xfee00000, 0xfeefffff) IRQ region. AFAIK this (splitted IOMMU region) is only happening on x86. This patch also helps vhost to leverage the new interface as well, so that vhost won't get duplicated cache flushes. In that sense, it's an slight performance improvement. Suggested-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Message-Id: <1491562755-23867-2-git-send-email-peterx@redhat.com> [ehabkost: included extra vhost_iommu_region_del() change from Peter Xu] Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2017-04-06vfio/pci-quirks: Exclude non-ioport BAR from NVIDIA quirkAlex Williamson1-1/+1
The NVIDIA BAR5 quirk is targeting an ioport BAR. Some older devices have a BAR5 which is not ioport and can induce a segfault here. Test the BAR type to skip these devices. Link: https://bugs.launchpad.net/qemu/+bug/1678466 Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2017-03-31Revert "vfio/pci-quirks.c: Disable stolen memory for igd VFIO"Xiong Zhang1-38/+27
This reverts commit c2b2e158cc7b1cb431bd6039824ec13c3184a775. The original patch intend to prevent linux i915 driver from using stolen meory. But this patch breaks windows IGD driver loading on Gen9+, as IGD HW will use stolen memory on Gen9+, once windows IGD driver see zero size stolen memory, it will unload. Meanwhile stolen memory will be disabled in 915 when i915 run as a guest. Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com> [aw: Gen9+ is SkyLake and newer] Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2017-02-22vfio/pci-quirks.c: Disable stolen memory for igd VFIOXiongZhang1-27/+38
Regardless of running in UPT or legacy mode, the guest igd drivers may attempt to use stolen memory, however only legacy mode has BIOS support for reserving stolen memmory in the guest VM. We zero out the stolen memory size in all cases, then guest igd driver won't use stolen memory. In legacy mode, user could use x-igd-gms option to specify the amount of stolen memory which will be pre-allocated and reserved by bios for igd use. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99028 https://bugs.freedesktop.org/show_bug.cgi?id=99025 Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com> Tested-by: Terrence Xu <terrence.xu@intel.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2017-02-22vfio/pci: Improve extended capability comments, skip masked capsAlex Williamson1-10/+21
Since commit 4bb571d857d9 ("pci/pcie: don't assume cap id 0 is reserved") removes the internal use of extended capability ID 0, the comment here becomes invalid. However, peeling back the onion, the code is still correct and we still can't seed the capability chain with ID 0, unless we want to muck with using the version number to force the header to be non-zero, which is much uglier to deal with. The comment also now covers some of the subtleties of using cap ID 0, such as transparently indicating absence of capabilities if none are added. This doesn't detract from the correctness of the referenced commit as vfio in the kernel also uses capability ID zero to mask capabilties. In fact, we should skip zero capabilities precisely because the kernel might also expose such a capability at the head position and re-introduce the problem. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Peter Xu <peterx@redhat.com> Tested-by: Peter Xu <peterx@redhat.com> Reported-by: Jintack Lim <jintack@cs.columbia.edu> Tested-by: Jintack Lim <jintack@cs.columbia.edu>
2017-02-22vfio/pci: Report errors from qdev_unplug() via device requestAlex Williamson1-1/+5
Currently we ignore this error, report it with error_reportf_err() Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2017-02-17vfio: allow to notify unmap for very large regionPeter Xu1-4/+3
Linux vfio driver supports to do VFIO_IOMMU_UNMAP_DMA for a very big region. This can be leveraged by QEMU IOMMU implementation to cleanup existing page mappings for an entire iova address space (by notifying with an IOTLB with extremely huge addr_mask). However current vfio_iommu_map_notify() does not allow that. It make sure that all the translated address in IOTLB is falling into RAM range. The check makes sense, but it should only be a sensible checker for mapping operations, and mean little for unmap operations. This patch moves this check into map logic only, so that we'll get faster unmap handling (no need to translate again), and also we can then better support unmapping a very big region when it covers non-ram ranges or even not-existing ranges. Acked-by: Alex Williamson <alex.williamson@redhat.com> Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-02-17vfio: introduce vfio_get_vaddr()Peter Xu1-20/+45
A cleanup for vfio_iommu_map_notify(). Now we will fetch vaddr even if the operation is unmap, but it won't hurt much. One thing to mention is that we need the RCU read lock to protect the whole translation and map/unmap procedure. Acked-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-02-17vfio: trace map/unmap for notify as wellPeter Xu2-2/+3
We traces its range, but we don't know whether it's a MAP/UNMAP. Let's dump it as well. Acked-by: Alex Williamson <alex.williamson@redhat.com> Reviewed-by: David Gibson <david@gibson.dropbear.id.au> Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-02-10hw/vfio: Add CONFIG switches for calxeda-xgmac and amd-xgbeThomas Huth1-2/+2
Both devices seem to be specific to the ARM platform. It's confusing for the users if they show up on other target architectures, too (e.g. when the user runs QEMU with "-device ?" to get a list of supported devices). Thus let's introduce proper configuration switches so that the devices are only compiled and included when they are really required. Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2017-02-10hw/vfio/pci-quirks: Set category of the "vfio-pci-igd-lpc-bridge" deviceThomas Huth1-0/+1
The device has "bridge" in its name, so it should obviously be in the category DEVICE_CATEGORY_BRIDGE. Signed-off-by: Thomas Huth <thuth@redhat.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2017-02-10vfio-pci: Fix GTT wrap-around for Skylake+ IGDAlex Williamson1-1/+4
Previous IGD, up through Broadwell, only seem to write GTT values into the first 1MB of space allocated for the BDSM, but clearly the GTT can be multiple MB in size. Our test in vfio_igd_quirk_data_write() correctly filters out indexes beyond 1MB, but given the 1MB mask we're using, we re-apply writes only to the first 1MB of the guest allocated BDSM. We can't assume either the host or guest BDSM is naturally aligned, so we can't simply apply a different mask. Instead, save the host BDSM and do the arithmetic to subtract the host value to get the BDSM offset and add it to the guest allocated BDSM. Reported-by: Alexander Indenbaum <alexander.indenbaum@gmail.com> Tested-by: Alexander Indenbaum <alexander.indenbaum@gmail.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2017-02-02Merge remote-tracking branch 'remotes/stefanha/tags/tracing-pull-request' ↵Peter Maydell1-1/+1
into staging # gpg: Signature made Wed 01 Feb 2017 13:44:32 GMT # gpg: using RSA key 0x9CA4ABB381AB73C8 # gpg: Good signature from "Stefan Hajnoczi <stefanha@redhat.com>" # gpg: aka "Stefan Hajnoczi <stefanha@gmail.com>" # Primary key fingerprint: 8695 A8BF D3F9 7CDA AC35 775A 9CA4 ABB3 81AB 73C8 * remotes/stefanha/tags/tracing-pull-request: trace: clean up trace-events files qapi: add missing trace_visit_type_enum() call trace: improve error reporting when parsing simpletrace header trace: update docs to reflect new code generation approach trace: switch to modular code generation for sub-directories trace: move setting of group name into Makefiles trace: move hw/i386/xen events to correct subdir trace: move hw/xen events to correct subdir trace: move hw/block/dataplane events to correct subdir make: move top level dir to end of include search path # Conflicts: # Makefile Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2017-02-01pci: Convert msix_init() to Error and fix callersCao jin1-2/+6
msix_init() reports errors with error_report(), which is wrong when it's used in realize(). The same issue was fixed for msi_init() in commit 1108b2f. In order to make the API change as small as possible, leave the return value check to later patch. For some devices(like e1000e, vmxnet3, nvme) who won't fail because of msix_init's failure, suppress the error report by passing NULL error object. Bonus: add comment for msix_init. CC: Jiri Pirko <jiri@resnulli.us> CC: Gerd Hoffmann <kraxel@redhat.com> CC: Dmitry Fleytman <dmitry@daynix.com> CC: Jason Wang <jasowang@redhat.com> CC: Michael S. Tsirkin <mst@redhat.com> CC: Hannes Reinecke <hare@suse.de> CC: Paolo Bonzini <pbonzini@redhat.com> CC: Alex Williamson <alex.williamson@redhat.com> CC: Markus Armbruster <armbru@redhat.com> CC: Marcel Apfelbaum <marcel@redhat.com> Signed-off-by: Cao jin <caoj.fnst@cn.fujitsu.com> Reviewed-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2017-01-31trace: clean up trace-events filesStefan Hajnoczi1-1/+1
There are a number of unused trace events that scripts/cleanup-trace-events.pl finds. The "hw/vfio/pci-quirks.c" filename was typoed and "qapi/qapi-visit-core.c" was missing the qapi/ directory prefix. Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Message-id: 20170126171613.1399-3-stefanha@redhat.com Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2017-01-24vfio: remove a duplicated word in commentsCao jin1-2/+2
Signed-off-by: Cao jin <caoj.fnst@cn.fujitsu.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2017-01-24hw: Fix typos found by codespellStefan Weil1-1/+1
Signed-off-by: Stefan Weil <sw@weilnetz.de> Acked-by: Alistair Francis <alistair.francis@xilinx.com> Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
2016-10-31vfio: Add support for mmapping sub-page MMIO BARsYongji Xie2-2/+68
Now the kernel commit 05f0c03fbac1 ("vfio-pci: Allow to mmap sub-page MMIO BARs if the mmio page is exclusive") allows VFIO to mmap sub-page BARs. This is the corresponding QEMU patch. With those patches applied, we could passthrough sub-page BARs to guest, which can help to improve IO performance for some devices. In this patch, we expand MemoryRegions of these sub-page MMIO BARs to PAGE_SIZE in vfio_pci_write_config(), so that the BARs could be passed to KVM ioctl KVM_SET_USER_MEMORY_REGION with a valid size. The expanding size will be recovered when the base address of sub-page BAR is changed and not page aligned any more in guest. And we also set the priority of these BARs' memory regions to zero in case of overlap with BARs which share the same page with sub-page BARs in guest. Signed-off-by: Yongji Xie <xyjxie@linux.vnet.ibm.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2016-10-31vfio/pci: fix out-of-sync BAR information on resetIdo Yariv1-0/+12
When a PCI device is reset, pci_do_device_reset resets all BAR addresses in the relevant PCIDevice's config buffer. The VFIO configuration space stays untouched, so the guest OS may choose to skip restoring the BAR addresses as they would seem intact. The PCI device may be left non-operational. One example of such a scenario is when the guest exits S3. Fix this by resetting the BAR addresses in the VFIO configuration space as well. Signed-off-by: Ido Yariv <ido@wizery.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2016-10-31vfio: Handle zero-length sparse mmap rangesAlex Williamson1-14/+22
As reported in the link below, user has a PCI device with a 4KB BAR which contains the MSI-X table. This seems to hit a corner case in the kernel where the region reports being mmap capable, but the sparse mmap information reports a zero sized range. It's not entirely clear that the kernel is incorrect in doing this, but regardless, we need to handle it. To do this, fill our mmap array only with non-zero sized sparse mmap entries and add an error return from the function so we can tell the difference between nr_mmaps being zero based on sparse mmap info vs lack of sparse mmap info. NB, this doesn't actually change the behavior of the device, it only removes the scary "Failed to mmap ... Performance may be slow" error message. We cannot currently create an mmap over the MSI-X table. Link: http://lists.nongnu.org/archive/html/qemu-discuss/2016-10/msg00009.html Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2016-10-31memory: Replace skip_dump flag with "ram_device"Alex Williamson2-6/+5
Setting skip_dump on a MemoryRegion allows us to modify one specific code path, but the restriction we're trying to address encompasses more than that. If we have a RAM MemoryRegion backed by a physical device, it not only restricts our ability to dump that region, but also affects how we should manipulate it. Here we recognize that MemoryRegions do not change to sometimes allow dumps and other times not, so we replace setting the skip_dump flag with a new initializer so that we know exactly the type of region to which we're applying this behavior. Signed-off-by: Alex Williamson <alex.williamson@redhat.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com>
2016-10-17vfio: fix duplicate function callCao jin1-2/+6
When vfio device is reset(encounter FLR, or bus reset), if need to do bus reset(vfio_pci_hot_reset_one is called), vfio_pci_pre_reset & vfio_pci_post_reset will be called twice. Signed-off-by: Cao jin <caoj.fnst@cn.fujitsu.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2016-10-17vfio/pci: Fix vfio_rtl8168_quirk_data_read address offsetThorsten Kohfeldt1-1/+1
Introductory comment for rtl8168 VFIO MSI-X quirk states: At BAR2 offset 0x70 there is a dword data register, offset 0x74 is a dword address register. vfio: vfio_bar_read(0000:05:00.0:BAR2+0x70, 4) = 0xfee00398 // read data Thus, correct offset for data read is 0x70, but function vfio_rtl8168_quirk_data_read() wrongfully uses offset 0x74. Signed-off-by: Thorsten Kohfeldt <thorsten.kohfeldt@gmx.de> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2016-10-17vfio/pci: Handle host oversightEric Auger1-0/+11
In case the end-user calls qemu with -vfio-pci option without passing either sysfsdev or host property value, the device is interpreted as 0000:00:00.0. Let's create a specific error message to guide the end-user. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2016-10-17vfio/pci: Remove vfio_populate_device returned valueEric Auger1-13/+10
The returned value (either -errno or -1) is not used anymore by the caller, vfio_realize, since the error now is stored in the error object. So let's remove it. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2016-10-17vfio/pci: Remove vfio_msix_early_setup returned valueEric Auger1-10/+10
The returned value is not used anymore by the caller, vfio_realize, since the error now is stored in the error object. So let's remove it. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2016-10-17vfio/pci: Conversion to realizeEric Auger2-39/+27
This patch converts VFIO PCI to realize function. Also original initfn errors now are propagated using QEMU error objects. All errors are formatted with the same pattern: "vfio: %s: the error description" Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2016-10-17vfio/platform: Pass an error object to vfio_base_device_initEric Auger1-23/+27
This patch propagates errors encountered during vfio_base_device_init up to the realize function. In case the host value is not set or badly formed we now report an error. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2016-10-17vfio/platform: fix a wrong returned value in vfio_populate_deviceEric Auger1-0/+1
In case the vfio_init_intp fails we currently do not return an error value. This patch fixes the bug. The returned value is not explicit but in practice the error object is the one used to report the error to the end-user and the actual returned error value is not used. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2016-10-17vfio/platform: Pass an error object to vfio_populate_deviceEric Auger1-12/+13
Propagate the vfio_populate_device errors up to vfio_base_device_init. The error object also is passed to vfio_init_intp. At the moment we only report the error. Subsequent patches will propagate the error up to the realize function. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2016-10-17vfio: Pass an error object to vfio_get_deviceEric Auger3-11/+10
Pass an error object to prepare for migration to VFIO-PCI realize. In vfio platform vfio_base_device_init we currently just report the error. Subsequent patches will propagate the error up to the realize function. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2016-10-17vfio: Pass an error object to vfio_get_groupEric Auger3-17/+21
Pass an error object to prepare for migration to VFIO-PCI realize. For the time being let's just simply report the error in vfio platform's vfio_base_device_init(). A subsequent patch will duly propagate the error up to vfio_platform_realize. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
2016-10-17vfio: Pass an Error object to vfio_connect_containerEric Auger1-15/+25
The error is currently simply reported in vfio_get_group. Don't bother too much with the prefix which will be handled at upper level, later on. Also return an error value in case container->error is not 0 and the container is teared down. On vfio_spapr_remove_window failure, we also report an error whereas it was silent before. Signed-off-by: Eric Auger <eric.auger@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
generated by cgit v1.1 at 2024-11-02 23:08:13 +0000