aboutsummaryrefslogtreecommitdiffstats
path: root/xen/drivers
Commit message (Collapse)AuthorAgeFilesLines
...
* pl011: Move registers' definition in a separate fileJulien Grall2013-08-051-47/+1
| | | | | Signed-off-by: Julien Grall <julien.grall@linaro.org> Reviewed-by: Tim Deegan <tim@xen.org>
* pl011: Use ioreadl/iowritelJulien Grall2013-08-051-38/+42
| | | | | Signed-off-by: Julien Grall <julien.grall@linaro.org> 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>
* extract register definitions from ns16550 into a separated headerChen Baozi2013-07-161-111/+44
| | | | | Signed-off-by: Chen Baozi <baozich@gmail.com> Acked-by: Keir Fraser <keir@xen.org>
* 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>
* use SMP barrier in common code dealing with shared memory protocolsIan Campbell2013-07-041-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Xen currently makes no strong distinction between the SMP barriers (smp_mb etc) and the regular barrier (mb etc). In Linux, where we inherited these names from having imported Linux code which uses them, the SMP barriers are intended to be sufficient for implementing shared-memory protocols between processors in an SMP system while the standard barriers are useful for MMIO etc. On x86 with the stronger ordering model there is not much practical difference here but ARM has weaker barriers available which are suitable for use as SMP barriers. Therefore ensure that common code uses the SMP barriers when that is all which is required. On both ARM and x86 both types of barrier are currently identical so there is no actual change. A future patch will change smp_mb to a weaker barrier on ARM. Signed-off-by: Ian Campbell <ian.campbell@citrix.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>
* cpufreq, xenpm: fix cpufreq and xenpm mismatchJacob Shin2013-07-021-1/+1
| | | | | | | | Currently cpufreq and xenpm are out of sync. Fix cpufreq reporting of if turbo mode is enabled or not. Fix xenpm to not decode for tristate, but a boolean. Signed-off-by: Jacob Shin <jacob.shin@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>
* drivers/exynos4210: Return -ENOMEM when ioremap has failedJulien Grall2013-05-231-0/+1
| | | | | Signed-off-by: Julien Grall <julien.grall@linaro.org> Acked-by: Ian Campbell <ian.campbell@citrix.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>
* xen/arm: Add Exynos 4210 UART supportAnthony PERARD2013-05-132-0/+366
| | | | | | Signed-off-by: Anthony PERARD <anthony.perard@citrix.com> Signed-off-by: Julien Grall <julien.grall@linaro.org> Acked-by: Ian Campbell <ian.campbell@citrix.com>
* xen/arm: Use device tree API in pl011 UART driverJulien Grall2013-05-131-16/+72
| | | | | | | | Allow UART driver to retrieve all its information in the device tree. It's possible to choose the pl011 driver via the Xen command line. Signed-off-by: Julien Grall <julien.grall@linaro.org> Acked-by: Ian Campbell <ian.campbell@citrix.com>
* xen/arm: Add generic UART to get the device in the device treeJulien Grall2013-05-133-0/+76
| | | | | | | | | | | | | This generic UART will find the right UART via xen command line with dtuart=myserial. "myserial" is the alias of the UART in the device tree. Xen will retrieve the information via the device tree and call the initialization function for this specific UART thanks to the device API. Signed-off-by: Julien Grall <julien.grall@linaro.org> Acked-by: Ian Campbell <ian.campbell@citrix.com> Acked-by: Keir Fraser <keir@xen.org>
* xen/arm: New callback in uart_driver to get device tree interrupt structureJulien Grall2013-05-131-0/+10
| | | | | | | | | | | The existing function serial_irq doesn't allow to retrieve if the interrupt is edge or level trigger. Use this function to routes IRQs for all serial ports which Xen is using to Xen. Signed-off-by: Julien Grall <julien.grall@linaro.org> Acked-by: Ian Campbell <ian.campbell@citrix.com>
* xen/arm: Introduce ioremap_attr, ioremap_cache, ioremap_nocache, ioremap_wcJulien Grall2013-05-131-1/+1
| | | | | | | | | | | | Map physical range in virtual memory with a specific mapping attribute. Also add new mapping attributes for ARM: PAGE_HYPERVISOR_NOCACHE and PAGE_HYPERVISOR_WC. This function replaces early_ioremap which is only able to deal with 2Mb aligned mapping. Therefore, vmap initialization has been moved earlier. Signed-off-by: Julien Grall <julien.grall@linaro.org> Acked-by: Ian Campbell <ian.campbell@citrix.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>
* ns16550: delay resume until dom0 ACPI has a chance to runBen Guthro2013-04-241-1/+54
| | | | | | | | | | | | | | | | | | | | | | Check for ioport access, before fully resuming operation, to avoid spinning in __ns16550_poll when reading the LSR register returns 0xFF on failing ioport access. On some systems (like Lenovo T410, and some HP machines of similar vintage) there is a SuperIO card that provides this legacy ioport on the LPC bus. In this case, we need to wait for dom0's ACPI processing to run the proper AML to re-initialize the chip, before we can use the card again. This may cause a small amount of garbage to be written to the serial log while we wait patiently for that AML to be executed. This implementation limits the number of retries, to avoid a situation where we keep trying over and over again, in the case of some other failure on the ioport. Signed-Off-By: Ben Guthro <benjamin.guthro@citrix.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>
* ACPI/APEI: revert "accept validly sized ERST on Intel systems only for now"Jan Beulich2013-03-281-13/+0
| | | | | | | | With the recent two fixes to ERST handling, this should no longer be necessary. Signed-off-by: Jan Beulich <jbeulich@suse.com> Tested-by: Andrew Cooper <andrew.cooper3@citrix.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>
* ACPI, APEI: Add apei_exec_run_optionalHuang Ying2013-03-222-4/+16
| | | | | | | | | | | | | | | | | | Some actions in APEI ERST and EINJ tables are optional, for example, ACPI_EINJ_BEGIN_OPERATION action is used to do some preparation for error injection, and firmware may choose to do nothing here. While some other actions are mandatory, for example, firmware must provide ACPI_EINJ_GET_ERROR_TYPE implementation. Original implementation treats all actions as optional (that is, can have no instructions), that may cause issue if firmware does not provide some mandatory actions. To fix this, this patch adds apei_exec_run_optional, which should be used for optional actions. The original apei_exec_run should be used for mandatory actions. Signed-off-by: Huang Ying <ying.huang@intel.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Tested-by: Andrew Cooper <andrew.cooper3@citrix.com>
* ACPI/APEI: Unlock apei_iomaps_lock on error pathAndrew Cooper2013-03-221-4/+2
| | | | | | | | | | | | | This causes deadlocks during early boot on hardware with broken/buggy APEI implementations, such as a Dell Poweredge 2950 with the latest currently available BIOS. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Don't use goto or another special error path, as handling the error case in normal flow is quite simple. Signed-off-by: Jan Beulich <jbeulich@suse.com>
* ACPI/ERST: Name table in otherwise opaque error messagesAndrew Cooper2013-03-201-2/+2
| | | | | | | | Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Fix spelling and lower severities. Signed-off-by: Jan Beulich <jbeulich@suse.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>
* ACPI: support v5 (reduced HW) sleep interfaceJan Beulich2013-02-221-0/+16
| | | | | | | | | | | | Note that this also fixes a broken input check in acpi_enter_sleep() (previously validating the sleep->pm1[ab]_cnt_val relationship based on acpi_sinfo.pm1b_cnt_val, which however gets set only subsequently). Also adjust a few minor issues with the pre-v5 handling in acpi_fadt_parse_sleep_info(). Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org>
* ACPICA: Update for larger ACPI 5 FADT sizeBob Moore2013-02-221-5/+6
| | | | | | | | | FADT is now larger than 256 bytes, so all FADT offsets must be changed from 8 bits to 16 bits. Signed-off-by: Bob Moore <robert.moore@intel.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org>
* ACPI 5.0: Implement hardware-reduced optionBob Moore2013-02-221-2/+20
| | | | | | | | | | | | | If HW-reduced flag is set in the FADT, do not attempt to access or initialize any ACPI hardware, including SCI and global lock. No FACS will be present. Signed-off-by: Bob Moore <robert.moore@intel.com> Also adjust acpi_fadt_parse_sleep_info(). Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org>
* ACPI 5.0: Basic support for FADT version 5Bob Moore2013-02-221-2/+3
| | | | | | Signed-off-by: Bob Moore <robert.moore@intel.com> 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-219-9/+9
| | | | | | | 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>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-09 21:24:48 +0000