search for: info_for_irq

...tchn = evtchn, - .cpu = 0, .u.pirq = { .gsi = gsi, .vector = vector } }; -} - /* * Accessors for packed IRQ information. */ @@ -177,26 +170,6 @@ static unsigned virq_from_irq(unsigned irq) return info->u.virq; } -static unsigned gsi_from_irq(unsigned irq) -{ - struct irq_info *info = info_for_irq(irq); - - BUG_ON(info == NULL); - BUG_ON(info->type != IRQT_PIRQ); - - return info->u.pirq.gsi; -} - -static unsigned vector_from_irq(unsigned irq) -{ - struct irq_info *info = info_for_irq(irq); - - BUG_ON(info == NULL); - BUG_ON(info->type != IRQT_PIRQ); - - return info->u.pirq.vector...

...tchn = evtchn, - .cpu = 0, .u.pirq = { .gsi = gsi, .vector = vector } }; -} - /* * Accessors for packed IRQ information. */ @@ -177,26 +170,6 @@ static unsigned virq_from_irq(unsigned irq) return info->u.virq; } -static unsigned gsi_from_irq(unsigned irq) -{ - struct irq_info *info = info_for_irq(irq); - - BUG_ON(info == NULL); - BUG_ON(info->type != IRQT_PIRQ); - - return info->u.pirq.gsi; -} - -static unsigned vector_from_irq(unsigned irq) -{ - struct irq_info *info = info_for_irq(irq); - - BUG_ON(info == NULL); - BUG_ON(info->type != IRQT_PIRQ); - - return info->u.pirq.vector...

...tchn = evtchn, - .cpu = 0, .u.pirq = { .gsi = gsi, .vector = vector } }; -} - /* * Accessors for packed IRQ information. */ @@ -177,26 +170,6 @@ static unsigned virq_from_irq(unsigned irq) return info->u.virq; } -static unsigned gsi_from_irq(unsigned irq) -{ - struct irq_info *info = info_for_irq(irq); - - BUG_ON(info == NULL); - BUG_ON(info->type != IRQT_PIRQ); - - return info->u.pirq.gsi; -} - -static unsigned vector_from_irq(unsigned irq) -{ - struct irq_info *info = info_for_irq(irq); - - BUG_ON(info == NULL); - BUG_ON(info->type != IRQT_PIRQ); - - return info->u.pirq.vector...

Three of the patches could be squashed in one, but it makes more sense to review them as three. These patches fix the case of an PVHVM guest not being able to resume propely b/c of hitting: 142 BUG_ON(info->type != IRQT_UNBOUND && info->type != type); (in events.c) and also adds a WARN to catch situations like these. The reason for this is that the Xen python toolstack

...| __xen_evtchn_do_upcall() { 1) 0.119 us | irq_to_desc(); 1) | handle_edge_irq() { 1) 0.107 us | _raw_spin_lock(); 1) | ack_dynirq() { 1) | evtchn_from_irq() { 1) | info_for_irq() { 1) | irq_get_irq_data() { 1) 0.052 us | irq_to_desc(); 1) 0.418 us | } 1) 0.782 us | } 1) 1.135 us | } 1) 0.049 us | irq_move_irq(); 1) 1.800 us | } 1)...

...? get_cycles+0x5/0x8 [354047.224054] [<ffffffff8124561e>] ? add_interrupt_randomness+0x38/0x155 [354047.224054] [<ffffffff8109124d>] ? handle_irq_event_percpu+0x50/0x17d [354047.224054] [<ffffffff8121ca3a>] ? disable_pirq+0x2/0x2 [354047.224054] [<ffffffff8121c624>] ? info_for_irq+0x7/0x17 [354047.224054] [<ffffffff81093847>] ? handle_percpu_irq+0x3a/0x4f [354047.224054] [<ffffffff8121c866>] ? __xen_evtchn_do_upcall+0xd3/0x287 [354047.224054] [<ffffffff8104b780>] ? __local_bh_enable+0x40/0x77 [354047.224054] [<ffffffff813576ac>] ? call_softirq+0x...

Hi Ingo, Here''s the chunk of patches to add Xen Dom0 support (it''s probably worth creating a new xen/dom0 topic branch for it). A dom0 Xen domain is basically the same as a normal domU domain, but it has extra privileges to directly access hardware. There are two issues to deal with: - translating to and from the domain''s pseudo-physical addresses and real machine

...4047.224054] [<ffffffff8124561e>] ? > add_interrupt_randomness+0x38/0x155 > [354047.224054] [<ffffffff8109124d>] ? > handle_irq_event_percpu+0x50/0x17d > [354047.224054] [<ffffffff8121ca3a>] ? disable_pirq+0x2/0x2 > [354047.224054] [<ffffffff8121c624>] ? info_for_irq+0x7/0x17 > [354047.224054] [<ffffffff81093847>] ? handle_percpu_irq+0x3a/0x4f > [354047.224054] [<ffffffff8121c866>] ? > __xen_evtchn_do_upcall+0xd3/0x287 > [354047.224054] [<ffffffff8104b780>] ? __local_bh_enable+0x40/0x77 > [354047.224054] [<ffffffff813576...

...98] [<c1077a77>] ? pvclock_clocksource_read+0xd7/0x170 [ 43.193098] [<c1039d75>] ? xen_clocksource_read+0x25/0x40 [ 43.193098] [<c1103dd4>] handle_irq_event_percpu+0x54/0x200 [ 43.193098] [<c1106438>] ? irq_get_irq_data+0x8/0x10 [ 43.193098] [<c134b188>] ? info_for_irq+0x8/0x20 [ 43.193098] [<c1106724>] handle_percpu_irq+0x34/0x50 [ 43.193098] [<c134ba0d>] __xen_evtchn_do_upcall+0x2cd/0x2e0 [ 43.193098] [<c10d7f54>] ? tick_check_idle+0xb4/0xc0 [ 43.193098] [<c134ba4b>] xen_evtchn_do_upcall+0x1b/0x30 [ 43.193098] [<c15c303...

We''ve been hitting the following issue on a variety of hosts and recent Xen/dom0 version combinations. Here''s an excerpt from our latest: Xen: 4.1.4 (xenbits @ 23432) Dom0: 3.7.1-x86_64 BUG: unable to handle kernel NULL pointer dereference at 000000000000001c IP: [<ffffffff8141a301>] evtchn_from_irq+0x11/0x40 PGD 0 Oops: 0000 [#1] SMP Modules linked in: ebt_comment