Displaying 6 results from an estimated 6 matches for "ioapic_level_typ".
Did you mean:
ioapic_level_type
2007 May 31
4
[RFC][PATCH 4/6] HVM PCI Passthrough (non-IOMMU)
...ne is
asserted
(then, polarity change is done) and another interrupt when the
_external_
line is deassered (as a result from the polarity change), this
continues
repeatedly.
- It is implemented by introducing a new hw_interrupt_type, which is
exactly
the same as the ioapic_level_type hw_interrupt_type with its end()
callback replaced (see io_apic.c for more details).
- State machine:
Whenever an interrupt occur (both for an assertion or
deassertion):
1. Ack & Mask the interrupt
2. Assert/Deassert virtual line of NativeDom (Interrupt
act...
2007 Apr 18
2
refactoring io_apic.c
...ontinue;
- irq = pin_2_irq(irq_entry, ioapic, pin);
- set_ioapic_affinity_irq(irq, TARGET_CPUS);
- }
-
- }
-}
-
-/*
* EISA Edge/Level control register, ELCR
*/
static int EISA_ELCR(unsigned int irq)
@@ -1153,32 +951,6 @@ next:
return current_vector;
}
-static struct hw_interrupt_type ioapic_level_type;
-static struct hw_interrupt_type ioapic_edge_type;
-
-#define IOAPIC_AUTO -1
-#define IOAPIC_EDGE 0
-#define IOAPIC_LEVEL 1
-
-static inline void ioapic_register_intr(int irq, int vector, unsigned long trigger)
-{
- if (use_pci_vector() && !platform_legacy_irq(irq)) {
- if ((trigger == I...
2007 Apr 18
2
refactoring io_apic.c
...ontinue;
- irq = pin_2_irq(irq_entry, ioapic, pin);
- set_ioapic_affinity_irq(irq, TARGET_CPUS);
- }
-
- }
-}
-
-/*
* EISA Edge/Level control register, ELCR
*/
static int EISA_ELCR(unsigned int irq)
@@ -1153,32 +951,6 @@ next:
return current_vector;
}
-static struct hw_interrupt_type ioapic_level_type;
-static struct hw_interrupt_type ioapic_edge_type;
-
-#define IOAPIC_AUTO -1
-#define IOAPIC_EDGE 0
-#define IOAPIC_LEVEL 1
-
-static inline void ioapic_register_intr(int irq, int vector, unsigned long trigger)
-{
- if (use_pci_vector() && !platform_legacy_irq(irq)) {
- if ((trigger == I...
2008 Sep 26
2
RE: [Xen-changelog] [xen-unstable] x86: Properly synchronise updates to pirq-to-vector mapping.
...-
-int domain_vector_to_irq(struct domain *d, int vector)
-{
- return d->arch.vector_pirq[vector];
-}
-
/* Where if anywhere is the i8259 connect in external int mode */
static struct { int pin, apic; } ioapic_i8259 = { -1, -1 };
@@ -721,7 +711,6 @@ next:
static struct hw_interrupt_type ioapic_level_type;
static struct hw_interrupt_type ioapic_edge_type;
-struct hw_interrupt_type pci_msi_type;
#define IOAPIC_AUTO -1
#define IOAPIC_EDGE 0
diff -r 7750906b06b3 -r 31f09a5e24cf xen/arch/x86/irq.c
--- a/xen/arch/x86/irq.c Wed Sep 24 10:23:51 2008 +0100
+++ b/xen/arch/x86/irq.c W...
2008 Sep 23
9
Xen crash on dom0 shutdown
There is a BUG_ON() at xen/arch/x86/physdev.c:169 which appears to
be dependent upon guest behavior (should close event channel before
un-mapping pirq), rather than on internal hypervisor state. In 2.6.18,
this likely goes unnoticed because pci_device_shutdown() only calls all
the driver shutdown routines. In newer kernels, however, it also calls
pci_msi_shutdown() and pci_msix_shutdown(), which
2013 May 31
62
cpuidle and un-eoid interrupts at the local apic
Recently our automated testing system has caught a curious assertion
while testing Xen 4.1.5 on a HaswellDT system.
(XEN) Assertion ''(sp == 0) || (peoi[sp-1].vector < vector)'' failed at irq.c:1030
(XEN) ----[ Xen-4.1.5 x86_64 debug=n Not tainted ]----
(XEN) CPU: 0
(XEN) RIP: e008:[<ffff82c48016b2b4>] do_IRQ+0x514/0x750
(XEN) RFLAGS: 0000000000010093 CONTEXT: