aboutsummaryrefslogtreecommitdiffstats
path: root/xen/arch/x86/irq.c
Commit message (Collapse)AuthorAgeFilesLines
* evtchn: refactor low-level event channel port opsDavid Vrabel2013-10-141-6/+5
| | | | | | | | | | | | | Use functions for the low-level event channel port operations (set/clear pending, unmask, is_pending and is_masked). Group these functions into a struct evtchn_port_op so they can be replaced by alternate implementations (for different ABIs) on a per-domain basis. Signed-off-by: David Vrabel <david.vrabel@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org>
* debug: remove some event channel info from the 'i' and 'q' debug keysDavid Vrabel2013-10-141-4/+1
| | | | | | | | | | | | | The 'i' key would always use VCPU0's selector word when printing the event channel state. Remove the incorrect output as a subsequent change will add the (correct) information to the 'e' key instead. When dumping domain information, printing the state of the VIRQ_DEBUG port is redundant -- this information is available via the 'e' key. Signed-off-by: David Vrabel <david.vrabel@citrix.com> Reviewed-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org>
* cleanup unused request{_dt,}_irq() parameterAndrew Cooper2013-08-081-1/+1
| | | | | | | | | 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>
* x86: enable multi-vector MSIJan Beulich2013-08-081-36/+170
| | | | | | | | | | | | | | | This implies - extending the public interface to have a way to request a block of MSIs - allocating a block of contiguous pIRQ-s for the target domain (but note that the Xen IRQs allocated have no need of being contiguous) - repeating certain operations for all involved IRQs - fixing multi_msi_enable() - adjusting the mask bit accesses for maskable MSIs Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Keir Fraser <keir@xen.org>
* Revert "irq: Add extra debugging to help track down why an assertion is failing"Jan Beulich2013-06-101-15/+1
| | | | | | | | | | | | | This reverts commits 2ae8b9173fb2388af6514c730d620ed5f450bc34 and 98e10364bde098e12104caa4f566b17d05f8b791. This was never reported to be hit, and we assume to have taken care of the problem by excluding legacy IRQs from the IRQ move cleanup logic. Suggested-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
* x86: fix ordering of operations in destroy_irq()Jan Beulich2013-05-311-23/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The fix for XSA-36, switching the default of vector map management to be per-device, exposed more readily a problem with the cleanup of these vector maps: dynamic_irq_cleanup() clearing desc->arch.used_vectors keeps the subsequently invoked clear_irq_vector() from clearing the bits for both the in-use and a possibly still outstanding old vector. Fix this by folding dynamic_irq_cleanup() into destroy_irq(), which was its only caller, deferring the clearing of the vector map pointer until after clear_irq_vector(). Once at it, also defer resetting of desc->handler until after the loop around smp_mb() checking for IRQ_INPROGRESS to be clear, fixing a (mostly theoretical) issue with the intercation with do_IRQ(): If we don't defer the pointer reset, do_IRQ() could, for non-guest IRQs, call ->ack() and ->end() with different ->handler pointers, potentially leading to an IRQ remaining un-acked. The issue is mostly theoretical because non-guest IRQs are subject to destroy_irq() only on (boot time) error paths. As to the changed locking: Invoking clear_irq_vector() with desc->lock held is okay because vector_lock already nests inside desc->lock (proven by set_desc_affinity(), which takes vector_lock and gets called from various desc->handler->ack implementations, getting invoked with desc->lock held). Reported-by: Andrew Cooper <andrew.cooper3@citrix.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org> Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: George Dunlap <george.dunlap@eu.citrix.com>
* x86: remove IS_PRIV access check bypassesDaniel De Graaf2013-04-181-2/+1
| | | | | | | | | | | Several domctl functions dealing with rangesets contain a short-circuit bypass if the domain is privileged. Since the construction of domain 0 permits access to all I/O ranges, the call to irq_access_permitted will normally return true even without the IS_PRIV check, and the presence of the IS_PRIV check prevents the creation of a privileged domain without access to specific devices or IO memory ranges. Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
* x86: fix various issues with handling guest IRQsJan Beulich2013-04-181-8/+42
| | | | | | | | | | | | | - properly revoke IRQ access in map_domain_pirq() error path - don't permit replacing an in use IRQ - don't accept inputs in the GSI range for MAP_PIRQ_TYPE_MSI - track IRQ access permission in host IRQ terms, not guest IRQ ones (and with that, also disallow Dom0 access to IRQ0) This is CVE-2013-1919 / XSA-46. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
* IOMMU: allow MSI message to IRTE propagation to failJan Beulich2013-04-151-2/+8
| | | | | | | | | | | | 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: show handler for Xen-internal interruptsJan Beulich2013-04-101-3/+6
| | | | | | | ... in 'i' debug key output. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org>
* x86: irq_move_cleanup_interrupt() must ignore legacy vectorsJan Beulich2013-04-021-1/+6
| | | | | | | | | | | | | | | | | | | | | 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/HPET: mask interrupt while changing affinityJan Beulich2013-03-181-1/+1
| | | | | | | | | | | | | | | While being unable to reproduce the "No irq handler for vector ..." messages observed on other systems, the change done by 5dc3fd2 ('x86: extend diagnostics for "No irq handler for vector" messages') appears to point at the lack of masking - at least I can't see what else might be wrong with the HPET MSI code that could trigger these warnings. While at it, also adjust the message printed by aforementioned commit to not pointlessly insert spaces - we don't need aligned tabular output here. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org>
* x86: extend diagnostics for "No irq handler for vector" messagesJan Beulich2013-03-141-8/+22
| | | | | | | | | 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: fix CMCI injectionJan Beulich2013-02-261-2/+2
| | | | | | | | | | | | | | | | This fixes the wrong use of literal vector 0xF7 with an "int" instruction (invalidated by 25113:14609be41f36) and the fact that doing the injection via a software interrupt was never valid anyway (because cmci_interrupt() acks the LAPIC, which does the wrong thing if the interrupt didn't get delivered though it). In order to do latter, the patch introduces send_IPI_self(), at once removing two opend coded uses of "genapic" in the IRQ handling code. Reported-by: Yongjie Ren <yongjie.ren@intel.com> Signed-off-by: Jan Beulich <jbeulich@suse.com> Tested-by: Yongjie Ren <yongjie.ren@intel.com> Acked-by: Keir Fraser <keir@xen.org>
* AMD,IOMMU: Make per-device interrupt remapping table defaultBoris Ostrovsky2013-02-051-3/+0
| | | | | | | | | | | | | | 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>
* xen/arch/x86: complete XSM hooks on irq/pirq mappingsDaniel De Graaf2013-01-231-4/+9
| | | | | | | | | | | | | | | | | Manipulation of a domain's pirq namespace was not fully protected by XSM hooks because the XSM hooks for IRQs needed a physical IRQ. Since this may not apply to HVM domains, a complete solution needs to split the XSM hook for this operation, using one hook for the PIRQ manipulation and one for controlling access to the hardware IRQ. This reworking has the advantage of providing the same MSI data to remove_irq that is provided to add_irq, allowing the PCI device to be determined in both functions. It also eliminates the last callers of rcu_lock_target_domain_by_id in x86 and common code in preparation for this function's removal. Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> Committed-by: Keir Fraser <keir@xen.org>
* xen/xsm: Add xsm_default parameter to XSM hooksDaniel De Graaf2013-01-111-1/+1
| | | | | | | | | | | | | | Include the default XSM hook action as the first argument of the hook to facilitate quick understanding of how the call site is expected to be used (dom0-only, arbitrary guest, or device model). This argument does not solely define how a given hook is interpreted, since any changes to the hook's default action need to be made identically to all callers of a hook (if there are multiple callers; most hooks only have one), and may also require changing the arguments of the hook. Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> Acked-by: Tim Deegan <tim@xen.org> Committed-by: Keir Fraser <keir@xen.org>
* xen: use XSM instead of IS_PRIV where duplicatedDaniel De Graaf2013-01-111-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Xen hypervisor has two basic access control function calls: IS_PRIV and the xsm_* functions. Most privileged operations currently require that both checks succeed, and many times the checks are at different locations in the code. This patch eliminates the explicit and implicit IS_PRIV checks that are duplicated in XSM hooks. When XSM_ENABLE is not defined or when the dummy XSM module is used, this patch should not change any functionality. Because the locations of privilege checks have sometimes moved below argument validation, error returns of some functions may change from EPERM to EINVAL or ESRCH if called with invalid arguments and from a domain without permission to perform the operation. Some checks are removed due to non-obvious duplicates in their callers: * acpi_enter_sleep is checked in XENPF_enter_acpi_sleep * map_domain_pirq has IS_PRIV_FOR checked in its callers: * physdev_map_pirq checks when acquiring the RCU lock * ioapic_guest_write is checked in PHYSDEVOP_apic_write * PHYSDEVOP_{manage_pci_add,manage_pci_add_ext,pci_device_add} are checked by xsm_resource_plug_pci in pci_add_device * PHYSDEVOP_manage_pci_remove is checked by xsm_resource_unplug_pci in pci_remove_device * PHYSDEVOP_{restore_msi,restore_msi_ext} are checked by xsm_resource_setup_pci in pci_restore_msi_state * do_console_io has changed to IS_PRIV from an explicit domid==0 Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> Acked-by: Jan Beulich <jbeulich@suse.com> Committed-by: Keir Fraser <keir@xen.org>
* x86: save/restore only partial register state where possibleJan Beulich2012-10-301-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | ... and make restore conditional not only upon having saved the state, but also upon whether saved state was actually modified (and register values are known to have been preserved). Note that RBP is unconditionally considered a volatile register (i.e. irrespective of CONFIG_FRAME_POINTER), since the RBP handling would become overly complicated due to the need to save/restore it on the compat mode hypercall path [6th argument]. Note further that for compat mode code paths, saving/restoring R8...R15 is entirely unnecessary - we don't allow those guests to enter 64-bit mode, and hence they have no way of seeing these registers' contents (and there consequently also is no information leak, except if the context saving domctl would be considered such). Finally, note that this may not properly deal with gdbstub's needs, yet (but if so, I can't really suggest adjustments, as I don't know that code). Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org>
* x86/IRQ: fix valid-old-vector checks in __assign_irq_vector()Jan Beulich2012-09-281-2/+1
| | | | | | | | | | | | | | | | | | There are two greater-than-zero checks for the old vector retrieved, which don't work when a negative value got stashed into the respective arch_irq_desc field. The effect of this was that for interrupts that are intended to get their affinity adjusted the first time before the first interrupt occurs, the affinity change would fail, because the original vector assignment would have caused the move_in_progress flag to get set (which causes subsequent re-assignments to fail until it gets cleared, which only happens from the ->ack() actor, i.e. when an interrupt actually occurred). This addresses a problem introduced in c/s 23816:7f357e1ef60a (by changing IRQ_VECTOR_UNASSIGNED from 0 to -1). Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org>
* x86/IO-APIC: streamline level ack/end handlingJan Beulich2012-09-201-1/+2
| | | | | | | | | | | | Rather than evaluating "ioapic_ack_new" on each invocation, and considering that the two methods really have almost no code in common, split the handlers. While at it, also move ioapic_ack_{new,forced} into .init.data (eliminating the single non-__init reference to the former). Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org>
* x86: drop "index" parameter from get_free_pirq()Jan Beulich2012-09-051-1/+1
| | | | | | | It's unused. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org>
* x86/i8259: Handle bogus spurious interrupts more quietlyAndrew Cooper2012-08-301-5/+5
| | | | | | | | | | | | | | | | | | | | | | 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: prevent call to xfree() in dump_irqs() while in an irq contextAndrew Cooper2012-05-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Because of c/s 24707:96987c324a4f, dump_irqs() can now be called in an irq context when a bug condition is encountered. If this is the case, ignore the call to xsm_show_irq_ssid() and the subsequent call to xfree(). This prevents an assertion failure in xfree(), and should allow all the debug information to be dumped, before failing with a BUG() because of the underlying race condition we are attempting to reproduce. Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Rather than using the non-obvious conditional around an xfree() that would be passed NULL only in the inverse case (which could easily get removed by a future change on the basis that calling xfree(NULL) is benign), switch the order of checks in xfree() itself and only suppress the call to XSM that could potentially call xmalloc(). Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org> Committed-by: Jan Beulich <jbeulich@suse.com>
* x86: adjust handling of interrupts coming in via legacy vectorsJan Beulich2012-05-151-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/irq: fix locking for c/s 24707:96987c324a4f debugging codeJan Beulich2012-05-141-0/+1
| | | | | | | | Without this, dump_irqs() may try to acquire the lock the caller is currently holding. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
* x86: Unify direct-apic and hiprio irq vector allocations.Keir Fraser2012-03-301-4/+10
| | | | Signed-off-by: Keir Fraser <keir@xen.org>
* x86: Allow direct vectored interrupts to be dynamically allocated.Keir Fraser2012-03-301-0/+15
| | | | | | Use this for Intel's CMCI and thermal interrupts. Signed-off-by: Keir Fraser <keir@xen.org>
* x86: All vectored interrupts go through do_IRQ().Keir Fraser2012-03-301-16/+20
| | | | Signed-off-by: Keir Fraser <keir@xen.org>
* replace bogus gdprintk() uses with {,d}printk()Jan Beulich2012-02-161-13/+13
| | | | | | | | | | | When the subject domain is not the current one (e.g. during domctl or HVM save/restore handling), use of gdprintk() is questionable at best, as it won't give the intended information on what domain is affected. Use plain printk() or dprintk() instead, but keep things (mostly) as guest messages by using XENLOG_G_*. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org>
* irq: Add extra debugging to help track down why an assertion is failingAndrew Cooper2012-02-071-1/+14
| | | | | | Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com> Acked-by: Keir Fraser <keir@xen.org> Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
* xsm: Add xsm_map_domain_pirq hookDaniel De Graaf2012-02-021-1/+1
| | | | | | | | | | When checking permissions in map_domain_pirq, the msi_desc field of the irq_desc is not yet populated with the PCI device being used. Pass in the msi_info structure which contains the intended PCI device whose label will be used in the security check. Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> Committed-by: Keir Fraser <keir@xen.org>
* xsm: Add security label to IRQ debug outputDaniel De Graaf2012-02-021-0/+8
| | | | | Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> Committed-by: Keir Fraser <keir@xen.org>
* x86: Make asmlinkage explicitly a no-op, and avoid usage in arch/x86Keir Fraser2012-01-151-1/+1
| | | | Signed-off-by: Keir Fraser <keir@xen.org>
* PCI: properly abstract out per-architecture extensions to struct pci_devJan Beulich2012-01-091-1/+1
| | | | | | | | | | | | | x86's used_vectors member was both misplaced (in struct pci_dev_info, which acts as a hypercall input data passing container only) and improperly abstracted (requiring a CONFIG_X86 conditional in a generic header). The adjustment requires hiding several more lines in IA64's pci.h, but as a benefit this allows removing one of the "null" headers. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org>
* VT-d: bind IRQs to CPUs local to the node the IOMMU is onJan Beulich2011-12-131-4/+14
| | | | | | | | | | | | | This extends create_irq() to take a node parameter, allowing the resulting IRQ to have its destination set to a CPU on that node right away, which is more natural than having to post-adjust this (and get e.g. a new IRQ vector assigned despite a fresh one was just obtained). All other callers of create_irq() pass NUMA_NO_NODE for the time being. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org>
* xsm: Expand I/O resource hooksDaniel De Graaf2011-12-021-0/+9
| | | | | | | | | | | | | | | | | | The XSM hooks inside rangeset are not useful in capturing the PIRQ mappings in HVM domains. They can also be called from softirq context where current->domain is invalid, causing spurious AVC denials from unrelated domains on such calls. Within FLASK code, the rangeset hooks were already divided between IRQs, I/O memory, and x86 IO ports; propagate this division back through the XSM hooks and call the XSM functions directly when needed. This removes XSM checks for the initial rangeset population for dom0 and the removal checks on domain destruction; denying either of these actions does not make sense. Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov> Committed-by: Keir Fraser <keir@xen.org>
* x86/IRQ: prevent vector sharing within IO-APICsJan Beulich2011-11-181-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | Following the prevention of vector sharing for MSIs, this change enforces the same within IO-APICs: Pin based interrupts use the IO-APIC as their identifying device under the AMD IOMMU (and just like for MSIs, only the identifying device is used to remap interrupts here, with no regard to an interrupt's destination). Additionally, LAPIC initiated EOIs (for level triggered interrupts) too use only the vector for identifying which interrupts to end. While this generally causes no significant problem (at worst an interrupt would be re-raised without a new interrupt event actually having occurred), it still seems better to avoid the situation. For this second aspect, a distinction is being made between the traditional and the directed-EOI cases: In the former, vectors should not be shared throughout all IO-APICs in the system, while in the latter case only individual IO-APICs need to be contrained (or, if the firmware indicates so, sub- groups of them having the same GSI appear at multiple pins). Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
* x86/IRQ: eliminate irq_vector[]Jan Beulich2011-11-111-11/+8
| | | | | | | | | | | | The vector is already being tracked in struct irq_desc's arch.vector member, so there's no real need for a second place where this to get stored. The only caveat is that legacy vectors (used for interrupts handled through the 8259) must be special cased to not prevent non- legacy vectors from being assigned. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
* x86/IRQ: create_irq() should call assign_irq_vector()Jan Beulich2011-11-081-7/+1
| | | | | | | | | | | ... rather than __assign_irq_vector(), to ensure desc->affinity gets initialized properly. This at once eliminates the need to forward-declare the latter function. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
* eliminate remaining uses of struct irq_cfgJan Beulich2011-11-081-5/+3
| | | | | | Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
* eliminate first_cpu() etcJan Beulich2011-11-081-6/+6
| | | | | | | | This includes the conversion from for_each_cpu_mask() to for_each-cpu(). Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
* eliminate cpus_xyz()Jan Beulich2011-11-081-1/+1
| | | | | | Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
* IRQ: move a few more bits into common codeJan Beulich2011-11-071-4/+0
| | | | | | | ... as they're not really arch-specific. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org>
* x86/IRQ: fix create_irq() after c/s 24068:6928172f7dedJan Beulich2011-11-041-17/+16
| | | | | | | | | | | | | | | | | | init_one_irq_desc() must be called with interrupts enabled (as it may call functions from the xmalloc() group). Rather than mis-using vector_lock to also protect the finding of an unused IRQ, make this lockless through using cmpxchg(), and obtain the lock only around the actual assignment of the vector. Also fold find_unassigned_irq() into its only caller. It is, btw, questionable whether create_irq() calling __assign_irq_vector() (rather than assign_irq_vector()) is actually correct - desc->affinity appears to not get initialized properly in this case. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org>
* x86/IRQ: consolidate IRQ disabling when acquiring vector lockJan Beulich2011-11-031-7/+2
| | | | | | | | | | __assign_irq_vector() doesn't need to disable interrupts (its callers are required to when acquiring the lock), and set_desc_affinity() can use the normal spin lock primitives. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
* IRQ: allocate CPU masks dynamicallyJan Beulich2011-11-031-92/+108
| | | | | | | | | | 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>
* allocate CPU sibling and core maps dynamicallyJan Beulich2011-10-211-1/+1
| | | | | | | | | | ... thus reducing the per-CPU data area size back to one page even when building for large NR_CPUS. At once eliminate the old __cpu{mask,list}_scnprintf() helpers. Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org>
* x86: allocate IRQ actions' cpu_eoi_map dynamicallyJan Beulich2011-10-211-12/+19
| | | | | Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org>
* eliminate direct assignments of CPU masksJan Beulich2011-10-211-7/+7
| | | | | | | | | | | | | | | | Use cpumask_copy() instead of direct variable assignments for copying CPU masks. While direct assignments are not a problem when both sides are variables actually defined as cpumask_t (except for possibly copying *much* more than would actually need to be copied), they must not happen when the original variable is of type cpumask_var_t (which may have lass space allocated to it than a full cpumask_t). Eliminate as many of such assignments as possible (in several cases it's even possible to collapse two operations [copy then clear one bit] into one [cpumask_andnot()]), and thus set the way for reducing the allocation size in alloc_cpumask_var(). Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Keir Fraser <keir@xen.org>
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-01 22:30:08 +0000