aboutsummaryrefslogtreecommitdiffstats
path: root/xen/drivers/passthrough
Commit message (Collapse)AuthorAgeFilesLines
* VT-d: fix suspected data race condition in iommu_set_root_entry()Andrew Cooper2013-10-081-16/+3
| | | | | | | | | | | | | | | | | Coverity ID: 1054967 Coverity spotted that iommu->root_maddr was optionally allocated within the protection of the iommu->lock, but was referenced with the protection of the iommu->register_lock, and freed without any lock. Luckily, the code as-is is not vulnerable to the potential risks identified. However, the alloc_pgtable_maddr() is far more appropriately done in iommu_alloc(), removing a set of spinlock calls, and a possibility for the iommu setup to fail later than iommu_alloc() with an -ENOMEM. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Xiantao Zhang <xiantao.zhang@intel.com>
* x86/AMD-Vi: Fix IVRS HPET special->handle overrideSuravee Suthikulpanit2013-09-302-13/+27
| | | | | | | | | | | | | The current logic does not handle the case when HPET special->handle is invalid in IVRS. On such system, the following message is shown: (XEN) AMD-Vi: Failed to setup HPET MSI remapping: Wrong HPET This patch will allow the ivrs_hpet[<handle>]=<sbdf> to override the IVRS. Also, it removes struct hpet_sbdf.iommu since it is not used anywhere in the code. Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
* AMD IOMMU: fix Dom0 device setup failure for host bridgesSuravee Suthikulpanit2013-09-274-5/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The host bridge device (i.e. 0x18 for AMD) does not require IOMMU, and therefore is not included in the IVRS. The current logic tries to map all PCI devices to an IOMMU. In this case, "xl dmesg" shows the following message on AMD sytem. (XEN) setup 0000:00:18.0 for d0 failed (-19) (XEN) setup 0000:00:18.1 for d0 failed (-19) (XEN) setup 0000:00:18.2 for d0 failed (-19) (XEN) setup 0000:00:18.3 for d0 failed (-19) (XEN) setup 0000:00:18.4 for d0 failed (-19) (XEN) setup 0000:00:18.5 for d0 failed (-19) This patch adds a new device type (i.e. DEV_TYPE_PCI_HOST_BRIDGE) which corresponds to PCI class code 0x06 and sub-class 0x00. Then, it uses this new type to filter when trying to map device to IOMMU. Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Reported-by: Stefan Bader <stefan.bader@canonical.com> On VT-d refuse (un)mapping host bridges for other than the hardware domain. Coding style cleanup. Signed-off-by: Jan Beulich <jbeulich@suse.com> Tested-by: Stefan Bader <stefan.bader@canonical.com> Acked-by: Xiantao Zhang <xiantao.zhang@intel.com>
* passthrough/amd: Shuffle declaration.Tim Deegan2013-09-171-1/+1
| | | | | | | | | | | Coverity's parser chokes on seeing __section() before the type. Coverity CID 1087190 Signed-off-by: Tim Deegan <tim@xen.org> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Jan Beulich <jbeulich@suse.com> Acked-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
* passthrough/amd: Missing 'break'Tim Deegan2013-09-171-0/+1
| | | | | | | | Coverity CID 1055502 Signed-off-by: Tim Deegan <tim@xen.org> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
* passthrough/amd: Drop unnecessary lock lookup.Tim Deegan2013-09-171-1/+0
| | | | | | | | | | | | The lock's not used for anything, and AFAICT no locking is needed since the IVRS tables are static after boot. Coverity CID 1087199 Signed-off-by: Tim Deegan <tim@xen.org> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
* AMD-Vi: also match IVRS overrides on device IDJan Beulich2013-09-161-0/+18
| | | | | Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
* AMD-Vi: Fix IVRS HPET special->handle overrideSuravee Suthikulpanit2013-09-161-0/+1
| | | | Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
* AMD IOMMU: allow command line overrides for broken IVRS tablesJan Beulich2013-08-291-18/+70
| | | | | | | | | | | | | | With there being so many systems with broken ACPI tables, and with it generally being known what's wrong with those tables, give people a handle to overcome the resulting disabling of their IOMMUs. Inspired by Linux side patches providing similar functionality. Suggested-by: Sander Eikelenboom <linux@eikelenboom.it> Signed-off-by: Jan Beulich <jbeulich@suse.com> Tested-By: Sander Eikelenboom <linux@eikelenboom.it> Acked-by: Keir Fraser <keir@xen.org> Acked-by: Suravee Suthikulpanit <suravee.suthikulapanit@amd.com>
* AMD IOMMU: add missing checksJan Beulich2013-08-291-3/+11
| | | | | | | | | | | For one we shouldn't accept IVHD tables specifying IO-APIC IDs beyond the limit we support (MAX_IO_APICS, currently 128). And then we shouldn't memset() a pointer allocation of which failed. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Suravee Suthikulpanit <suravee.suthikulapanit@amd.com>
* PCI: centralize parsing of device coordinates in command line optionsJan Beulich2013-08-281-15/+6
| | | | | | | | | With yet another case to come in a subsequent patch, it seems time to do this in a single place rather than hand crafting it in various scattered around locations. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org>
* AMD IOMMU: also allocate IRTEs for HPET MSIJan Beulich2013-08-281-5/+22
| | | | | | | | | | | | | | Omitting this was a blatant oversight of mine in commit 2ca9fbd7 ("AMD IOMMU: allocate IRTE entries instead of using a static mapping"). This also changes a bogus inequality check into a sensible one, even though it is already known that this will make HPET MSI unusable on certain systems (having respective broken firmware). This, however, seems better than failing on systems with consistent ACPI tables. Reported-by: Sander Eikelenboom <linux@eikelenboom.it> Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
* PCI: break MSI-X data out of struct pci_dev_infoJan Beulich2013-08-231-1/+16
| | | | | | | | | | | Considering that a significant share of PCI devices out there (not the least the myriad of CPU-exposed ones) don't support MSI-X at all, and that the amount of data is well beyond a handful of bytes, break this out of the common structure, at once allowing the actual data to be tracked to become architecture specific. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org>
* VT-d: warn about Compatibility Format Interrupts being enabled by firmwareJan Beulich2013-08-211-6/+10
| | | | | | | | | ... as being insecure. Also drop the second (redundant) read DMAR_GSTS_REG from enable_intremap(). Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by Xiantao Zhang <xiantao.zhang@intel.com>
* VT-d: protect against bogus information coming from BIOSJan Beulich2013-08-142-0/+6
| | | | | | | | | | | | | Add checks similar to those done by Linux: The DRHD address must not be all zeros or all ones (Linux only checks for zero), and capabilities as well as extended capabilities must not be all ones. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Ben Guthro <benjamin.guthro@citrix.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Tested-by: Ben Guthro <benjamin.guthro@citrix.com> Acked by: Yang Zhang <yang.z.zhang@intel.com> Acked-by: Xiantao Zhang <xiantao.zhang@intel.com>
* cleanup unused request{_dt,}_irq() parameterAndrew Cooper2013-08-082-2/+2
| | | | | | | | | The irqflags parameter appears to be an unused vestigial parameter right from the integration of the IOMMU code in 2007. The parameter is 0 at all callsites and never used. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
* VT-d: enable for multi-vector MSIJan Beulich2013-07-181-29/+35
| | | | | | | | | The main change being to make alloc_remap_entry() capable of allocating a block of entries. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Xiantao Zhang <xiantao.zhang@intel.com>
* AMD IOMMU: Add debug-key for dumping IRTEsSuravee Suthikulpanit2013-07-161-0/+61
| | | | | | Support debug-key "V" to allow IOMMU IRTE dumping. Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
* AMD IOMMU: enable for multi-vector MSIJan Beulich2013-07-161-12/+51
| | | | | | | | The main change being to make alloc_intremap_entry() capable of allocating a block of entries. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
* AMD IOMMU: untie remap and vector mapsJan Beulich2013-07-161-44/+0
| | | | | | | | | | With the specific IRTEs used for an interrupt no longer depending on the vector, there's no need to tie the remap sharing model to the vector sharing one. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: George Dunlap <george.dunlap@eu.citrix.com> Acked-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
* AMD IOMMU: allocate IRTE entries instead of using a static mappingJan Beulich2013-07-163-80/+183
| | | | | | | | | | | For multi-vector MSI, where we surely don't want to allocate contiguous vectors and be able to set affinities of the individual vectors separately, we need to drop the use of the tuple of vector and delivery mode to determine the IRTE to use, and instead allocate IRTEs (which imo should have been done from the beginning). Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
* AMD IOMMU: use ioremap()Jan Beulich2013-07-151-12/+3
| | | | | | | | | | There's no point in using the fixmap here, and it gets map_iommu_mmio_region() in line with unmap_iommu_mmio_region(), which was already using iounmap() (thus crashing if actually used). Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org> Acked-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
* VT-d: use ioremap()Jan Beulich2013-07-153-11/+4
| | | | | | | | | There's no point in using the fixmap here, and it gets iommu_alloc() in line with iommu_free(), which was already using iounmap() (thus crashing if actually used). Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org>
* iommu/amd: Workaround for erratum 787Suravee Suthikulpanit2013-07-021-0/+16
| | | | | | | | | | | | | | | | | | | | | The IOMMU interrupt handling in bottom half must clear the PPR log interrupt and event log interrupt bits to re-enable the interrupt. This is done by writing 1 to the memory mapped register to clear the bit. Due to hardware bug, if the driver tries to clear this bit while the IOMMU hardware also setting this bit, the conflict will result with the bit being set. If the interrupt handling code does not make sure to clear this bit, subsequent changes in the event/PPR logs will no longer generating interrupts, and would result if buffer overflow. After clearing the bits, the driver must read back the register to verify. Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Adjust to apply on top of heavily modified patch 1. Adjust flow to get away with a single readl() in each instance of the status register checks. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Tim Deegan <tim@xen.org> Acked-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
* iommu/amd: Fix logic for clearing the IOMMU interrupt bitsSuravee Suthikulpanit2013-07-023-40/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The IOMMU interrupt bits in the IOMMU status registers are "read-only, and write-1-to-clear (RW1C). Therefore, the existing logic which reads the register, set the bit, and then writing back the values could accidentally clear certain bits if it has been set. The correct logic would just be writing only the value which only set the interrupt bits, and leave the rest to zeros. This patch also, clean up #define masks as Jan has suggested. Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> With iommu_interrupt_handler() properly having got switched its readl() from status to control register, the subsequent writel() needed to be switched too (and the RW1C comment there was bogus). Some of the cleanup went too far - undone. Further, with iommu_interrupt_handler() now actually disabling the interrupt sources, they also need to get re-enabled by the tasklet once it finished processing the respective log. This also implies re-running the tasklet so that log entries added between reading the log and re- enabling the interrupt will get handled in a timely manner. Finally, guest write emulation to the status register needs to be done with the RW1C (and RO for all other bits) semantics in mind too. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Tim Deegan <tim@xen.org> Acked-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
* AMD/intremap: Prevent use of per-device vector maps until irq logic is fixedAndrew Cooper2013-06-271-2/+17
| | | | | | | | | | | | | | | | | | | | | XSA-36 changed the default vector map mode from global to per-device. This is because a global vector map does not prevent one PCI device from impersonating another and launching a DoS on the system. However, the per-device vector map logic is broken for devices with multiple MSI-X vectors, which can either result in a failed ASSERT() or misprogramming of a guests interrupt remapping tables. The core problem is not trivial to fix. In an effort to get AMD systems back to a non-regressed state, introduce a new type of vector map called per-device-global. This uses per-device vector maps in the IOMMU, but uses a single used_vector map for the core IRQ logic. This patch is intended to be removed as soon as the per-device logic is fixed correctly. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
* AMD IOMMU: make interrupt work againJan Beulich2013-06-171-7/+6
| | | | | | | | | | | | | | | | | | | | Commit 899110e3 ("AMD IOMMU: include IOMMU interrupt information in 'M' debug key output") made the AMD IOMMU MSI setup code use more of the generic MSI setup code (as other than for VT-d this is an ordinary MSI- capable PCI device), but failed to notice that till now interrupt setup there _required_ the subsequent affinity setup to be done, as that was the only point where the MSI message would get written. The generic MSI affinity setting routine, however, does only an incremental change, i.e. relies on this setup to have been done before. In order to not make the code even more clumsy, introduce a new low level helper routine __setup_msi_irq(), thus eliminating the need for the AMD IOMMU code to directly fiddle with the IRQ descriptor. Reported-by: Suravee Suthikulanit <suravee.suthikulpanit@amd.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Tested-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Acked-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
* AMD/IOMMU: revert "SR56x0 Erratum 64 - Reset all head & tail pointers"Jan Beulich2013-06-051-19/+6
| | | | | | | | | | The code this patch added is redundant with already present code in set_iommu_{command_buffer,{event,ppr}_log}_control(). Just switch those ones from using writel() to writeq() for consistency. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
* AMD/iommu: SR56x0 Erratum 64 - Reset all head & tail pointersAndrew Cooper2013-05-221-0/+13
| | | | | | | | | | | | | | | | Reference at time of patch: http://support.amd.com/us/ChipsetMotherboard_TechDocs/46303.pdf Erratum 64 states that the head and tail pointers for the Command buffer and Event log are only reset on a cold boot, not a warm boot. While the erratum is limited to systems using SR56xx chipsets (such as Family 10h CPUs), resetting the pointers is a sensible action in all cases, including the PPR log for consistency. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Keir Fraser <keir@xen.org> Acked-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
* AMD IOMMU: fill msi_desc fields required by commit fe017c59Jan Beulich2013-05-071-3/+10
| | | | | | | | | Since the AMD IOMMU code relies on the x86 generic MSI code, it also needs to be updated to match "x86/MSI: cleanup to prepare for multi- vector MSI". Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Suravee Suthikulanit <suravee.suthikulpanit@amd.com>
* VT-d: don't permit SVT_NO_VERIFY entries for known device typesJan Beulich2013-05-021-5/+9
| | | | | | | | | | | Only in cases where we don't know what to do we should leave the IRTE blank (suppressing all validation), but we should always log a warning in those cases (as being insecure). This is CVE-2013-1952 / XSA-49. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: "Zhang, Xiantao" <xiantao.zhang@intel.com>
* x86: allow Dom0 read-only access to IO-APICsJan Beulich2013-05-022-4/+0
| | | | | | | | | | | | | | | | | There are BIOSes that want to map the IO-APIC MMIO region from some ACPI method(s), and there is at least one BIOS flavor that wants to use this mapping to clear an RTE's mask bit. While we can't allow the latter, we can permit reads and simply drop write attempts, leveraging the already existing infrastructure introduced for dealing with AMD IOMMUs' representation as PCI devices. This fixes an interrupt setup problem on a system where _CRS evaluation involved the above described BIOS/ACPI behavior, and is expected to also deal with a boot time crash of pv-ops Linux upon encountering the same kind of system. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org>
* VTD: Remove the check for reserved device scope typeYang Zhang2013-04-161-2/+8
| | | | | | | | | | | | | | Though we only have four valid types now, the new type may be added in future. It's better to remove the check and only deal with the type that we can recognize. Signed-off-by: Yang Zhang <yang.z.zhang@Intel.com> Signed-off-by: Xiantao Zhang <xiantao.zhang@Intel.com> Acked-by: Keir Fraser <keir@xen.org> Add log message for this case. Signed-off-by: Jan Beulich <jbeulich@suse.com>
* iommu/crash: Interrupt remapping is also disabled on crashAndrew Cooper2013-04-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | This fixes a regression side-effect caused by: IOMMU: properly check whether interrupt remapping is enabled git: fae0372140befb88d890a30704a8ec058c902af8 hg: 26742:e1ec14bad0cb On the crash path in nmi_shootdown_cpus(), we shut down the IOMMU, then disable the IOAPIC. On systems which support interrupt remapping, the variable iommu_intremap remains set, meaning that disable_IO_APIC() issues interrupt remapping invalidate requests. IOAPIC interrupt remapping used to be conditional on iommu_enabled, but is now conditional on iommu_intremap, following the above changeset. This behaviour can be fixed by also indicating that interrupt remapping is not enabled after shutting down the IOMMU. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
* IOMMU: allow MSI message to IRTE propagation to failJan Beulich2013-04-154-18/+33
| | | | | | | | | | | | With the need to allocate multiple contiguous IRTEs for multi-vector MSI, the chance of failure here increases. While on the AMD side there's no allocation of IRTEs at present at all (and hence no way for this allocation to fail, which is going to change with a later patch in this series), VT-d already ignores an eventual error here, which this patch fixes. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: "Zhang, Xiantao" <xiantao.zhang@intel.com>
* x86: reserve pages when SandyBridge integrated graphicsXudong Hao2013-03-261-1/+1
| | | | | | | | | | | | | | | | SNB graphics devices have a bug that prevent them from accessing certain memory ranges, namely anything below 1M and in the pages listed in the table. Xen does not initialize below 1MB to heap, i.e. below 1MB pages don't be allocated, so it's unnecessary to reserve memory below the 1 MB mark that has not already been reserved. So reserve those pages listed in the table at xen boot if set detect a SNB gfx device on the CPU to avoid GPU hangs. Signed-off-by: Xudong Hao <xudong.hao@intel.com> Acked-by: Keir Fraser <keir@xen.org>
* AMD IOMMU: allow disabling only interrupt remapping when certain IVRS ↵Jan Beulich2013-03-252-3/+6
| | | | | | | | | | | | | | | | | | | consistency checks fail After some more thought on the XSA-36 and specifically the comments we got regarding disabling the IOMMU in this situation altogether making things worse instead of better, I came to the conclusion that we can actually restrict the action in affected cases to just disabling interrupt remapping. That doesn't make the situation worse than prior to the XSA-36 fixes (where interrupt remapping didn't really protect domains from one another), but allows at least DMA isolation to still be utilized. To do so, disabling of interrupt remapping must be explicitly requested on the command line - respective checks will then be skipped. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Suravee Suthikulanit <suravee.suthikulpanit@amd.com>
* VT-d: deal with 5500/5520/X58 errataMalcolm Crossley2013-03-252-0/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | http://www.intel.com/content/www/us/en/chipsets/5520-and-5500-chipset-ioh-specification-update.html Stepping B-3 has two errata (#47 and #53) related to Interrupt remapping, to which the workaround is for the BIOS to completely disable interrupt remapping. These errata are fixed in stepping C-2. Unfortunately this chipset stepping is very common and many BIOSes are not disabling interrupt remapping on this stepping . We can detect this in Xen and prevent Xen from using the problematic interrupt remapping feature. The Intel 5500/5520/X58 chipset does not support VT-d Extended Interrupt Mode(EIM). This means the iommu_supports_eim() check always fails and so x2apic mode cannot be enabled in Xen before this quirk disables the interrupt remapping feature. Signed-off-by: Malcolm Crossley <malcolm.crossley@citrix.com> Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Gate the function call to check the quirk on interrupt remapping being requested to get enabled, and upon failure disable the IOMMU to be in line with what the changes for XSA-36 (plus follow-ups) did. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: "Zhang, Xiantao" <xiantao.zhang@intel.com>
* IOMMU: properly check whether interrupt remapping is enabledJan Beulich2013-03-253-30/+13
| | | | | | | | | | | | | | | | ... rather than the IOMMU as a whole. That in turn required to make sure iommu_intremap gets properly cleared when the respective initialization fails (or isn't being done at all). Along with making sure interrupt remapping doesn't get inconsistently enabled on some IOMMUs and not on others in the VT-d code, this in turn allowed quite a bit of cleanup on the VT-d side (if desired, that cleanup could of course be broken out into a separate patch). Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: "Zhang, Xiantao" <xiantao.zhang@intel.com>
* VT-d: Enumerate IOMMUs when listing capabilitiesAndrew Cooper2013-03-201-1/+2
| | | | | | This saves N identical console log lines on a multi-iommu server. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
* AMD/IOMMU: Process softirqs while building dom0 iommu mappingsAndrew Cooper2013-03-201-0/+3
| | | | | | | | | | | | | | | | Recent changes which have made their way into xen-4.2 stable have pushed the runtime of construct_dom0() over 5 seconds, which has caused regressions in XenServer testing because of our 5 second watchdog. The root cause is that amd_iommu_dom0_init() does not process softirqs and in particular the nmi_timer which causes the watchdog to decide that no useful progress is being made. This patch adds periodic calls to process_pending_softirqs() at the same interval as the Intel variant of this function. The server which was failing with the watchdog test now boots reliably with a timeout of 1 second. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
* IOMMU, AMD Family15h Model10-1Fh erratum 746 WorkaroundSuravee Suthikulpanit2013-02-261-0/+38
| | | | | | | | | | | | | | | The IOMMU may stop processing page translations due to a perceived lack of credits for writing upstream peripheral page service request (PPR) or event logs. If the L2B miscellaneous clock gating feature is enabled the IOMMU does not properly register credits after the log request has completed, leading to a potential system hang. BIOSes are supposed to disable L2B micellaneous clock gating by setting L2_L2B_CK_GATE_CONTROL[CKGateL2BMiscDisable](D0F2xF4_x90[2]) = 1b. This patch corrects that for those which do not enable this workaround. Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com> Signed-off-by: Jan Beulich <jbeulich@suse.com>
* AMD IOMMU: cover all functions of a device even if ACPI only tells us of func 0Jan Beulich2013-02-263-13/+48
| | | | | | | | | | | | | | This ought to work as all functions of a device have the same place in the bus topology, i.e. use the same IOMMU. Also fix the type of ivrs_bdf_entries (when it's 'unsigned short' and the last device found on a segment is ff:1f.x, it would otherwise end up being zero). And drop the bogus 'last_bdf' static variable, which conflicted anyway with various functions' parameters. Signed-off-by: Jan Beulich <jbeulich@suse.com>
* honor ACPI v4 FADT flagsJan Beulich2013-02-222-0/+9
| | | | | | | | | | | | | | - force use of physical APIC mode if indicated so (as we don't support xAPIC cluster mode, the respective flag is taken to force physical mode too) - don't use MSI if indicated so (implies no IOMMU) Both can be overridden on the command line, for the MSI case this at once adds a new command line option allowing to turn off PCI MSI (IOMMU and HPET are unaffected by this). Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org>
* Fix emacs local variable block to use correct C style variable.David Vrabel2013-02-214-4/+4
| | | | | | | The emacs variable to set the C style from a local variable block is c-file-style, not c-set-style. Signed-off-by: David Vrabel <david.vrabel@citrix.com
* AMD IOMMU: use __ioapic_read_entry() instead of open coding itJan Beulich2013-02-181-4/+2
| | | | | Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
* AMD IOMMU: don't BUG() when we don't have toJan Beulich2013-02-181-2/+2
| | | | | | | find_iommu_for_device() can easily return NULL instead, as all of its callers are prepared for that. Signed-off-by: Jan Beulich <jbeulich@suse.com>
* AMD IOMMU: handle MSI for phantom functionsJan Beulich2013-02-141-6/+27
| | | | | | | | | | | | | | With ordinary requests allowed to come from phantom functions, the remapping tables ought to be set up to also allow for MSI triggers to come from other than the "real" device too. It is not clear to me whether the alias-ID handling also needs adjustment for this to work properly, or whether firmware can be expected to properly express this through a device alias range descriptor (or multiple device alias ones). Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Ian Campbell <ian.campbell@citrix.com>
* AMD IOMMU: also spot missing IO-APIC entries in IVRS tableJan Beulich2013-02-141-14/+37
| | | | | | | | | | | | | | | | | | Apart from dealing duplicate conflicting entries, we also have to handle firmware omitting IO-APIC entries in IVRS altogether. Not doing so has resulted in c/s 26517:601139e2b0db to crash such systems during boot (whereas with the change here the IOMMU gets disabled just as is being done in the other cases, i.e. unless global tables are being used). Debugging this issue has also pointed out that the debug log output is pretty ugly to look at - consolidate the output, and add one extra item for the IVHD special entries, so that future issues are easier to analyze. Signed-off-by: Jan Beulich <jbeulich@suse.com> Tested-by: Sander Eikelenboom <linux@eikelenboom.it> Acked-by: Ian Campbell <ian.campbell@citrix.com>
* AMD,IOMMU: Make per-device interrupt remapping table defaultBoris Ostrovsky2013-02-052-1/+3
| | | | | | | | | | | | | | Using global interrupt remapping table may be insecure, as described by XSA-36. This patch makes per-device mode default. This is XSA-36 / CVE-2013-0153. Signed-off-by: Boris Ostrovsky <boris.ostrovsky@amd.com> Moved warning in amd_iov_detect() to location covering all cases. Signed-off-by: Jan Beulich <jbeulich@suse.com> Committed-by: Jan Beulich <jbeulich@suse.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-09 08:20:44 +0000