aboutsummaryrefslogtreecommitdiffstats
path: root/xen/arch/x86/i8259.c
Commit message (Collapse)AuthorAgeFilesLines
* xen: move for_each_set_bit to xen/bitops.hStefano Stabellini2013-05-081-1/+1
| | | | | | | | Move for_each_set_bit from asm-x86/bitops.h to xen/bitops.h. Replace #include <asm/bitops.h> with #include <xen/bitops.h> everywhere. Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> Acked-by: Keir Fraser <keir@xen.org>
* x86: irq_move_cleanup_interrupt() must ignore legacy vectorsJan Beulich2013-04-021-0/+2
| | | | | | | | | | | | | | | | | | | | | Since the main loop in the function includes legacy vectors, and since vector_irq[] gets set up for legacy vectors regardless of whether those get handled through the IO-APIC, it must not do anything on this vector range. In fact, we should never get past the move_cleanup_count check for IRQs not handled through the IO-APIC. Adding a respective assertion woulkd make those iterations more expensive (due to the lock acquire). For such an assertion to not have false positives we however ought to suppress setting up IRQ2 as an 8259A interrupt (which wasn't correct anyway), which is being done here despite the assertion not actually getting added. Furthermore, there's no point iterating over the vectors past LAST_HIPRIORITY_VECTOR, so terminate the loop accordingly. Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Keir Fraser <keir@xen.org>
* x86: extend diagnostics for "No irq handler for vector" messagesJan Beulich2013-03-141-1/+1
| | | | | | | | | By storing the inverted IRQ number in vector_irq[], we may be able to spot which IRQ a vector was used for most recently, thus hopefully permitting to understand why these messages trigger on certain systems. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org>
* x86: clean up interrupt stub generationJan Beulich2012-09-261-18/+28
| | | | | | | | | | | | Apart from moving some code that is only used here from the header file to the actual source one, this also - moves interrupt[] into .init.data, - prevents generating (unused) stubs for vectors below FIRST_DYNAMIC_VECTOR, and - shortens and sanitizes the names of the stubs. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org>
* x86/i8259: Clean up _mask_and_ack_8259A_irq().Keir Fraser2012-08-301-39/+24
| | | | Signed-off-by: Keir Fraser <keir@xen.org>
* x86/i8259: Handle bogus spurious interrupts more quietlyAndrew Cooper2012-08-301-15/+19
| | | | | | | | | | | | | | | | | | | | | | c/s 25336:edd7c7ad1ad2 introduced the concept of a bogus vector, for in irqs delivered through the i8259 PIC after IO-APICs had been set up. However, if supurious PIC vectors are received, many "No irq handler for vector" log messages can be seen on the console. This patch adds to the bogus vector logic to detect spurious PIC vectors and simply ignore them. _mask_and_ack_8259A_irq() has been modified to return a boolean indicating whether the irq is real or not, and in the case of a spurious vector, the error in do_IRQ() is not printed. One complication is that now, _mask_and_ack_8259A_irq() can get called whatever the ack mode is, so has been altered to work out whether it should EOI the irq or not. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Committed-by: Keir Fraser <keir@xen.org>
* x86: adjust handling of interrupts coming in via legacy vectorsJan Beulich2012-05-151-11/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The debugging code added in c/s 24707:96987c324a4f was hit a (small) number of times (one report being http://lists.xen.org/archives/html/xen-devel/2012-05/msg00332.html), apparently always with a vector within the legacy range. Obviously, besides legacy vectors not normally expected to be in use on systems with IO-APIC(s), they should never make it to the IRQ migration logic. This wasn't being prevented so far: Since we don't have a one-to-one mapping between vectors and IRQs - legacy IRQs may have two vectors associated with them (one used in either 8259A, the other used in one of the IO-APICs) -, vector-to-IRQ translations for legacy vectors (as used in do_IRQ()) would yield a valid IRQ number despite the IRQ really being handled via an IO-APIC. This gets changed here - disable_8259A_irq() zaps the legacy vector-to- IRQ mapping, and enable_8259A_irq(), should it ever be called for a particular interrupts, restores it. The spurious interrupt logic in do_IRQ() gets adjusted too: Interrupts coming in via legacy vectors presumably didn't get reported through the IO-APIC/LAPIC pair (as we never program these vectors into any RTE or LVT). Call ack_APIC_irq() only when the LAPIC's ISR bit says an interrupt is pending at the given vector. Plus, a new function (pointer) bogus_8259A_irq() gets used to have the 8259A driver take care of the bogus interrupt (as outside of automatic EOI mode it may need an EOI to be issued for it to prevent other interrupts legitimately going through the 8259As from getting masked out). Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
* x86: fix i8259A_resume()Jan Beulich2012-05-151-1/+1
| | | | | | | | On systems that have an IO-APIC, we generally run the PIC in AEOI mode, yet i8259A_resume() so far failed to put it back into that mode. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org>
* x86: Unify direct-apic and hiprio irq vector allocations.Keir Fraser2012-03-301-1/+1
| | | | Signed-off-by: Keir Fraser <keir@xen.org>
* IRQ: allocate CPU masks dynamicallyJan Beulich2011-11-031-1/+1
| | | | | | | | | | This includes delaying the initialization of dynamically created IRQs until their actual first use and some further elimination of uses of struct irq_cfg. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
* fold struct irq_cfg into struct irq_descJan Beulich2011-10-191-3/+2
| | | | | | | | | | | | | struct irq_cfg really has become an architecture extension to struct irq_desc, and hence it should be treated as such (rather than as IRQ chip specific data, which it was meant to be originally). For a first step, only convert a subset of the uses; subsequent patches (partly to be sent later) will aim at fully eliminating the use of the old structure type. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
* pass struct irq_desc * to all other IRQ accessorsJan Beulich2011-09-181-19/+19
| | | | | | | | | | | | | This is again because the descriptor is generally more useful (with the IRQ number being accessible in it if necessary) and going forward will hopefully allow to remove all direct accesses to the IRQ descriptor array, in turn making it possible to make this some other, more efficient data structure. This additionally makes the .end() accessor optional, noting that in a number of cases the functions were empty. Signed-off-by: Jan Beulich <jbeulich@suse.com>
* IRQ: manually EOI migrating line interruptsAndrew Cooper2011-08-311-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When migrating IO-APIC line level interrupts between PCPUs, the migration code rewrites the IO-APIC entry to point to the new CPU/Vector before EOI'ing it. The EOI process says that EOI'ing the Local APIC will cause a broadcast with the vector number, which the IO-APIC must listen to to clear the IRR and Status bits. In the case of migrating, the IO-APIC has already been reprogrammed so the EOI broadcast with the old vector fails to match the new vector, leaving the IO-APIC with an outstanding vector, preventing any more use of that line interrupt. This causes a lockup especially when your root device is using PCI INTA (megaraid_sas driver *ehem*) However, the problem is mostly hidden because send_cleanup_vector() causes a cleanup of all moving vectors on the current PCPU in such a way which does not cause the problem, and if the problem has occured, the writes it makes to the IO-APIC clears the IRR and Status bits which unlocks the problem. This fix is distinctly a temporary hack, waiting on a cleanup of the irq code. It checks for the edge case where we have moved the irq, and manually EOI's the old vector with the IO-APIC which correctly clears the IRR and Status bits. Also, it protects the code which updates irq_cfg by disabling interrupts. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
* xen/x86: explicitly mark start-of-file asm()s as .textTim Deegan2011-04-071-0/+2
| | | | | | | | LLVM and gold between them get confused when asm align commands are emitted before a section marker. Signed-off-by: Tim Deegan <Tim.Deegan@citrix.com> Acked-by: Keir Fraser <keir@xen.org>
* x86: IO-APIC cleanupJan Beulich2011-03-091-1/+1
| | | | | | | | Remove unused and pointless bits from IO-APIC handling code. Move whatever possible into .init.*, and some data items into .data.read_mostly. Adjust some types. Signed-off-by: Jan Beulich <jbeulich@novell.com>
* x86: adjust other interrupt related section placementKeir Fraser2010-12-151-1/+0
| | | | | | | ... and remove some variables the value of which is never used altogether. Signed-off-by: Jan Beulich <jbeulich@novell.com>
* x86: fix boot failure (regression from pre-4.0 IRQ handling changes)Keir Fraser2010-10-021-0/+6
| | | | | | | | | | | | | | | | | | | With the change to index irq_desc[] by IRQ rather than by vector, the prior implicit change of the used flow handler when altering the IRQ routing path to go through the 8259A didn't work anymore, and hence on boards needing the ExtINT delivery workaround failed to boot. Make make_8259A_irq() a real function again, thus allowing the flow handler to be changed there. Also eliminate the generally superfluous and (at least theoretically) dangerous hard coded setting of the flow handler for IRQ0: Earlier code should have set this already based on information coming from ACPI/MPS, and non-standard systems may e.g. have this IRQ level triggered. Signed-off-by: Jan Beulich <jbeulich@novell.com> Tested-by: Markus Schuster <ml@markus.schuster.name>
* Rename irq_cfg->domain to irq_cfg->cpu_maskKeir Fraser2010-08-301-1/+1
| | | | | From: Sheng Yang <sheng.yang@intel.com> Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
* x2APIC: improve enabling logicKeir Fraser2010-07-051-0/+20
| | | | | | | | | | | | | | This patch masks PIC and IOAPIC RTE's before x2APIC enabling, unmask and restore them after x2APIC enabling. It also really enables interrupt remapping before x2APIC enabling instead of just checking interrupt remapping setting. This patch also handles all x2APIC configuration including BIOS settings and command line settings. Especially, it handles that BIOS hands over in x2APIC mode (when there is apic id > 255). It checks if x2APIC is already enabled by BIOS. If already enabled, it will disable interrupt remapping and queued invalidation first, then enable them again. Signed-off-by: Weidong Han <weidong.han@intel.com>
* irq cleanupKeir Fraser2009-10-281-3/+3
| | | | | | | | Make IRQ related data const or __read_mostly where possible/reasonable, use platform_legacy_irq() where feasible, and remove the now unused definition of vector_to_irq(). Signed-off-by: Jan Beulich <jbeulich@novell.com>
* Scattered code arrangement cleanups.Keir Fraser2009-10-071-24/+0
| | | | | | | | - remove redundant declarations - add/move prototypes to headers - move things where they belong to Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
* x86: Implement per-cpu vector for xen hypervisorKeir Fraser2009-08-191-9/+12
| | | | | | | | | | | | | | | Since Xen and Linux has big differece in code base, it is very hard to port Linux's patch and apply it to Xen directly, so this patch only adopts core logic of Linux, and make it work for Xen. Key changes: 1. vector allocation algorithm 2. all IRQ chips' set_affinity logic 3. IRQ migration when cpu hot remove. 4. Break assumptions which depend on global vector policy. Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
* x86: Change Xen hypervisor's interrupt infrastructureKeir Fraser2009-08-191-41/+24
| | | | | | | | | | | | | | from vector-based to IRQ-based. In per-cpu vector environment, vector space changes to multi-demension resource, so vector number is not appropriate to index irq_desc which stands for unique interrupt source. As Linux does, irq number is chosen to index irq_desc. This patch changes vector-based interrupt infrastructure to irq-based one. Mostly, it follows upstream linux's changes, and some parts are adapted for Xen. Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
* x86: Change nr_irqs to nr_irqs_gsi.Keir Fraser2009-08-191-2/+2
| | | | | | | | | Currently, nr_irqs is only used for GSI irqs, change the name to make its meaning more precise. And, also this is the initial step to support irq allocation for MSI interrupt source. Signed-off-by: Xiantao Zhang <xiantao.zhang@intel.com>
* x86: eliminate hard-coded NR_IRQSKeir Fraser2009-05-271-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... splitting it into global nr_irqs (determined at boot time) and per- domain nr_pirqs (derived from nr_irqs and a possibly command line specified value, which probably should later become a per-domain config setting). This has the (desirable imo) side effect of reducing the size of struct hvm_irq_dpci from requiring an order-3 page to order-2 (on x86-64), which nevertheless still is too large. However, there is now a variable size bit array on the stack in pt_irq_time_out() - while for the moment this probably is okay, it certainly doesn't look nice. However, replacing this with a static (pre-)allocation also seems less than ideal, because that would require at least min(d->nr_pirqs, NR_VECTORS) bit arrays of d->nr_pirqs bits, since this bit array is used outside of the serialized code region in that function, and keeping the domain's event lock acquired across pirq_guest_eoi() doesn't look like a good idea either. The IRQ- and vector-indexed arrays hanging off struct hvm_irq_dpci could in fact be changed further to dynamically use the smaller of the two ranges for indexing, since there are other assumptions about a one-to-one relationship between IRQs and vectors here and elsewhere. Additionally, it seems to me that struct hvm_mirq_dpci_mapping's digl_list and gmsi fields could really be overlayed, which would yield significant savings since this structure gets always instanciated in form of d->nr_pirqs (as per the above could also be the smaller of this and NR_VECTORS) dimensioned arrays. Signed-off-by: Jan Beulich <jbeulich@novell.com>
* Cleanup naming for ia64 and x86 interrupt handling functionsKeir Fraser2009-02-121-2/+2
| | | | | | | | | | | | | - Append '_IRQ' to AUTO_ASSIGN, NEVER_ASSIGN, and FREE_TO_ASSIGN - Rename {request,setup}_irq to {request,setup}_irq_vector - Rename free_irq to release_irq_vector - Add {request,setup,release}_irq wrappers for their {request,setup,release}_irq_vector counterparts - Added generic irq_to_vector inline for ia64 - Changed ia64 to use the new naming scheme Signed-off-by: Espen Skoglund <espen.skoglund@netronome.com> Signed-off-by: Isaku Yamahata <yamahata@valinux.co.jp>
* Enable CMCI for Intel CPUsKeir Fraser2008-12-221-0/+1
| | | | | Signed-off-by Yunhong Jiang <yunhong.jiang@intel.com> Signed-off-by Liping Ke <liping.ke@intel.com>
* Properly distinguish irq and vector spacesKeir Fraser2008-11-201-1/+1
| | | | | | | | | | | | This makes sure that there are no assumptions about NR_IRQS==NR_VECTORS anymore, and it also renames various variables to properly reflect what they represent. While coded correctly, I wonder whether dump_irqs() shouldn't iterate over the vector space rather than the irq space, so that MSI entries are also processed. Signed-off-by: Jan Beulich <jbeulich@novell.com>
* x86: Free MSI vector when a pirq is unmapped.Keir Fraser2008-10-081-0/+4
| | | | | Signed-off-by: Yunhong Jiang <yunhong.jiang@intel.com> Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
* x86: More accurate PIT frequency estimation (1193182Hz)Keir Fraser2008-07-211-1/+1
| | | | | | | | | In practice this has no impact since variance between crystals will be substantially greater than 1-2ppm. But we may as well be as accurate as possible. From: Dan Magenheimer <dan.magenheimer@oracle.com> Signed-off-by: Keir Fraser <keir.fraser@citrix.com>
* Add management and locking of PCI device structuresKeir Fraser2008-07-041-3/+0
| | | | | | | | | Add functions for managing pci_dev structures. Create a list containing all current pci_devs. Remove msi_pdev_list. Create a read-write lock protecting all pci_dev lists. Add spinlocks for pci_dev access. Do necessary modifications to MSI code. Signed-off-by: Espen Skoglund <espen.skoglund@netronome.com>
* MSI 3/6: add msi support to xenKeir Fraser2008-05-011-0/+3
| | | | | Signed-off-by: Jiang Yunhong <yunhong.jiang@intel.com> Signed-off-by: Shan Haitao <haitao.shan@intel.com>
* vmx: Enable Core 2 Duo Performance Counters in HVM guestKeir Fraser2008-01-301-0/+1
| | | | Signed-off-by: Haitao Shan <haitao.shan@intel.com>
* x86: Various cleanups around CR4 handling, cpu_possible_map, and VMX ↵kfraser@localhost.localdomain2007-07-121-1/+2
| | | | | | initialisation. Signed-off-by: Keir Fraser <keir@xensource.com>
* Convert __init into __devinit in wakeup path.kfraser@localhost.localdomain2007-07-111-1/+1
| | | | | | | | | | | | | Need to ensure all the code slice in the wakeup path still existing. For this purpose, we have to use __devinit instead of __init, since the former is null for CONFIG_HOTPLUG while the latter always causes related code to be free-ed after first boot. Later when adding __init to some function, be sure to consider wakeup case and cpu hotplug! Signed-off-by <Kevin.Tian@intel.com>
* Provide cpu hotplug support to Xen. Note this hotplugkfraser@localhost.localdomain2007-07-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | support is specific to PM, instead of for a run-time single CPU hotplug which can be a separate task. See embedded comment: /* * XXX: One important thing missed here is to migrate vcpus * from dead cpu to other online ones and then put whole * system into a stop state. It assures a safe environment * for a cpu hotplug/remove at normal running state. * * However for xen PM case, at this point: * -> All other domains should be notified with PM event, * and then in following states: * * Suspend state, or * * Paused state, which is a force step to all * domains if they do nothing to suspend * -> All vcpus of dom0 (except vcpu0) have already beem * hot removed * with the net effect that all other cpus only have idle vcpu * running. In this special case, we can avoid vcpu migration * then and system can be considered in a stop state. * * So current cpu hotplug is a special version for PM specific * usage, and need more effort later for full cpu hotplug. * (ktian1) */ Signed-off-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Keir Fraser <keir@xensource.com>
* Add suspend/resume to devices owned by Xen.kfraser@localhost.localdomain2007-06-111-0/+30
| | | | | | Signed-off-by: Ke Yu <ke.yu@intel.com> Signed-off-by: Kevin Tian <kevin.tian@intel.com> Signed-off-by: Keir Fraser <keir@xensource.com>
* Use DEFINE_SPINLOCK consistently throughout Xen.kaf24@firebug.cl.cam.ac.uk2006-06-011-1/+1
| | | | | Signed-off-by: Keir Fraser <keir@xensource.com>
* Remove definition of NR_PIRQS and replace all uses withkaf24@firebug.cl.cam.ac.uk2006-04-301-0/+1
| | | | | | | NR_IRQS. Allows removal of redundant check in pirq_guest_bind(). Signed-off-by: Keir Fraser <keir@xensource.com>
* Big fixes for the new IO-APIC acknowledging method. The problemskaf24@firebug.cl.cam.ac.uk2006-04-151-2/+2
| | | | | | | | | | | | | | | | | | | | were: 1. Some critical Xen interrupts could get blocked behind unacknowledged guest interrupts. This is avoided by making all Xen-bound interrrupts strictly higher priority. 2. Interrupts must not only be EOIed on the CPU that received them, but also in reverse order when interrupts are nested. A whole load of logic has been added to ensure this. There are two boot parameters relating to all this: 'ioapic_ack=old' -- use the old IO-APIC ACK method 'ioapic_ack=new' -- use the new IO-APIC ACK method (default) 'force_intack' -- periodically force acknowledgement of interrupts (default is no; useful for debugging) Signed-off-by: Keir Fraser <keir@xensource.com>
* More upgrades of Xen code to linux-2.6.16-rc2.kaf24@firebug.cl.cam.ac.uk2006-02-141-19/+1
| | | | | | Signed-off-by: Keir Fraser <keir@xensource.com>
* Upgrade arch/x86/cpu/* files to their equivalents inkaf24@firebug.cl.cam.ac.uk2006-02-141-1/+3
| | | | | | | | | | | linux-2.6.16-rc2/arch/i386/kernel/cpu/*. Also include kernel taint tracking and include that information, and Xen release info, in our crash dumps. Signed-off-by: Keir Fraser <keir@xensource.com>
* First cut of new time interfaces and synchronisation mechanisms.kaf24@firebug.cl.cam.ac.uk2005-07-181-4/+4
| | | | | | | | | | | | | | Based on an initial patch from Don Fry at IBM. Still TODO: 1. Testing 2. NTP synchronisation 3. Fix wallclock interface a bit 4. Support for platform timers other than PIT (e.g., HPET, IBM Cyclone) 5. Scale 64-bit TSC diffs instead of 32-bit, just for sanity 6. Error-correcting scale factor is still slightly wrong 6. More testing Signed-off-by: Keir Fraser <keir@xensource.com>
* bitkeeper revision 1.1702 (42a86f65gBB_DT3imKRA_tkGBTiKQA)kaf24@firebug.cl.cam.ac.uk2005-06-091-7/+0
| | | | | | Fix io_apic -> i8259 irq handling transition. Signed-off-by: Keir Fraser <keir@xensource.com>
* bitkeeper revision 1.1691.1.13 (42a767bfQ0_UVkV0FEMxkQeSluJPmA)kaf24@firebug.cl.cam.ac.uk2005-06-081-64/+69
| | | | | | | More irq changes: moving towards addressing irqs by vector rather than 'irq index'. Signed-off-by: Keir Fraser <keir@xensource.com>
* bitkeeper revision 1.1691.1.8 (42a6fb21d3oJwpLmOxa2jKHRJ-8fJg)kaf24@firebug.cl.cam.ac.uk2005-06-081-32/+15
| | | | | | | | | | First phase of removing IRQ numbers from Xen (transitioning to IRQ addressing by 'legacy ISA IRQ', 'interrupt vector', and 'I/O APIC address + pin' as appropriate). Overall plan is to move I/O APIC parsing and setup out of Xen (so we start DOM0 in virtual wire mode). Signed-off-by: Keir Fraser <keir@xensource.com>
* bitkeeper revision 1.1482 (428dbc17RT9NQ-_ttXtXBKQgwnM38g)kaf24@firebug.cl.cam.ac.uk2005-05-201-2/+2
| | | | | | | Ensure the static correspondence IRQ0<->FIRST_DEVICE_VECTOR is reflected in the vector_irq[] and irq_vector[] arrays. Signed-off-by: Keir Fraser <keir@xensource.com>
* bitkeeper revision 1.1389.10.1 (427fa2d3ZV92f_ErvLuIzWbV1f67QA)kaf24@firebug.cl.cam.ac.uk2005-05-091-5/+5
| | | | | | | Phase 1 of upgrading platform code to be derived from Linux 2.6.11 rather than 2.4.x. Signed-off-by: Keir Fraser <keir@xensource.com>
* bitkeeper revision 1.1159.187.5 (41a48ea4noDXAKVgDzH9BvR43D1OQg)cl349@arcadians.cl.cam.ac.uk2004-11-241-0/+1
| | | | | Simplify includes.
* bitkeeper revision 1.1159.146.1 (41865618vMDBaanL8_33U65ovb9fHw)ach61@labyrinth.cl.cam.ac.uk2004-11-011-1/+1
| | | | | rename pt_regs to xen_regs
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-13 08:24:13 +0000