| Message ID | 5CA35DE90200007800223E5A@prv1-mh.provo.novell.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | x86/IO-APIC: dump full destination ID in x2APIC mode | expand |
On Tue, Apr 02, 2019 at 07:04:41AM -0600, Jan Beulich wrote: > In x2APIC mode it is 32 bits wide. > > In __print_IO_APIC() drop logging of both physical and logical IDs: > The latter covers a superset of the bits of the former in the RTE, and > we write full 8-bit values anyway even in physical mode for all ordinary > interrupts, regardless of INT_DEST_MODE (see the users of SET_DEST()). > > Adjust other column arrangement (and heading) a little as well. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> Reviewed-by: Wei Liu <wei.liu2@citrix.com>
>>> On 02.04.19 at 15:04, wrote: > In x2APIC mode it is 32 bits wide. > > In __print_IO_APIC() drop logging of both physical and logical IDs: > The latter covers a superset of the bits of the former in the RTE, and > we write full 8-bit values anyway even in physical mode for all ordinary > interrupts, regardless of INT_DEST_MODE (see the users of SET_DEST()). > > Adjust other column arrangement (and heading) a little as well. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> > --- > I'm sure I had found some place where the wider destination ID is > documented for physical mode, but I wasn't able to find it again when I > searched now. All Intel chipset docs I've looked at claim it's only 4 > bits that are used / supposed to be stored. > > --- a/xen/arch/x86/io_apic.c > +++ b/xen/arch/x86/io_apic.c > @@ -1191,21 +1191,21 @@ static void /*__init*/ __print_IO_APIC(b > > printk(KERN_DEBUG ".... IRQ redirection table:\n"); > > - printk(KERN_DEBUG " NR Log Phy Mask Trig IRR Pol" > - " Stat Dest Deli Vect: \n"); > + printk(KERN_DEBUG " NR %s Msk Trg IRR Pol Stat DstM DelM Vec\n", > + x2apic_enabled ? " DestID" : "Dst"); > > for (i = 0; i <= reg_01.bits.entries; i++) { > struct IO_APIC_route_entry entry; > > entry = ioapic_read_entry(apic, i, 0); > > - printk(KERN_DEBUG " %02x %03X %02X ", > - i, > - entry.dest.logical.logical_dest, > - entry.dest.physical.physical_dest > - ); > + if ( x2apic_enabled ) > + printk(KERN_DEBUG " %02x %08x", i, entry.dest.dest32); > + else > + printk(KERN_DEBUG " %02x %02x ", i, > + entry.dest.logical.logical_dest); > > - printk("%1d %1d %1d %1d %1d %1d %1d %02X\n", > + printk(" %d %d %d %d %d %d %d %02X\n", > entry.mask, > entry.trigger, > entry.irr, > @@ -2481,12 +2481,14 @@ void dump_ioapic_irq_info(void) > rte = ioapic_read_entry(entry->apic, pin, 0); > > printk("vec=%02x delivery=%-5s dest=%c status=%d " > - "polarity=%d irr=%d trig=%c mask=%d dest_id:%d\n", > + "polarity=%d irr=%d trig=%c mask=%d dest_id:%0*x\n", > rte.vector, delivery_mode_2_str(rte.delivery_mode), > rte.dest_mode ? 'L' : 'P', > rte.delivery_status, rte.polarity, rte.irr, > rte.trigger ? 'L' : 'E', rte.mask, > - rte.dest.logical.logical_dest); > + x2apic_enabled ? 8 : 2, > + x2apic_enabled ? rte.dest.dest32 > + : rte.dest.logical.logical_dest); > > if ( entry->next == 0 ) > break; > > > >
>>> On 27.05.19 at 11:28, wrote: >>>> On 02.04.19 at 15:04, wrote: > > In x2APIC mode it is 32 bits wide. > > > > In __print_IO_APIC() drop logging of both physical and logical IDs: > > The latter covers a superset of the bits of the former in the RTE, and > > we write full 8-bit values anyway even in physical mode for all ordinary > > interrupts, regardless of INT_DEST_MODE (see the users of SET_DEST()). > > > > Adjust other column arrangement (and heading) a little as well. > > > > Signed-off-by: Jan Beulich <jbeulich@suse.com> > > --- > > I'm sure I had found some place where the wider destination ID is > > documented for physical mode, but I wasn't able to find it again when I > > searched now. All Intel chipset docs I've looked at claim it's only 4 > > bits that are used / supposed to be stored. > > > > --- a/xen/arch/x86/io_apic.c > > +++ b/xen/arch/x86/io_apic.c > > @@ -1191,21 +1191,21 @@ static void /*__init*/ __print_IO_APIC(b > > > > printk(KERN_DEBUG ".... IRQ redirection table:\n"); > > > > - printk(KERN_DEBUG " NR Log Phy Mask Trig IRR Pol" > > - " Stat Dest Deli Vect: \n"); > > + printk(KERN_DEBUG " NR %s Msk Trg IRR Pol Stat DstM DelM Vec\n", > > + x2apic_enabled ? " DestID" : "Dst"); > > > > for (i = 0; i <= reg_01.bits.entries; i++) { > > struct IO_APIC_route_entry entry; > > > > entry = ioapic_read_entry(apic, i, 0); > > > > - printk(KERN_DEBUG " %02x %03X %02X ", > > - i, > > - entry.dest.logical.logical_dest, > > - entry.dest.physical.physical_dest > > - ); > > + if ( x2apic_enabled ) > > + printk(KERN_DEBUG " %02x %08x", i, entry.dest.dest32); > > + else > > + printk(KERN_DEBUG " %02x %02x ", i, > > + entry.dest.logical.logical_dest); > > > > - printk("%1d %1d %1d %1d %1d %1d %1d %02X\n", > > + printk(" %d %d %d %d %d %d %d %02X\n", > > entry.mask, > > entry.trigger, > > entry.irr, > > @@ -2481,12 +2481,14 @@ void dump_ioapic_irq_info(void) > > rte = ioapic_read_entry(entry->apic, pin, 0); > > > > printk("vec=%02x delivery=%-5s dest=%c status=%d " > > - "polarity=%d irr=%d trig=%c mask=%d dest_id:%d\n", > > + "polarity=%d irr=%d trig=%c mask=%d dest_id:%0*x\n", > > rte.vector, delivery_mode_2_str(rte.delivery_mode), > > rte.dest_mode ? 'L' : 'P', > > rte.delivery_status, rte.polarity, rte.irr, > > rte.trigger ? 'L' : 'E', rte.mask, > > - rte.dest.logical.logical_dest); > > + x2apic_enabled ? 8 : 2, > > + x2apic_enabled ? rte.dest.dest32 > > + : rte.dest.logical.logical_dest); > > > > if ( entry->next == 0 ) > > break; > > > > > > > > > > > >
On 02/04/2019 14:04, Jan Beulich wrote: > In x2APIC mode it is 32 bits wide. > > In __print_IO_APIC() drop logging of both physical and logical IDs: > The latter covers a superset of the bits of the former in the RTE, and > we write full 8-bit values anyway even in physical mode for all ordinary > interrupts, regardless of INT_DEST_MODE (see the users of SET_DEST()). > > Adjust other column arrangement (and heading) a little as well. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
--- a/xen/arch/x86/io_apic.c +++ b/xen/arch/x86/io_apic.c @@ -1191,21 +1191,21 @@ static void /*__init*/ __print_IO_APIC(b printk(KERN_DEBUG ".... IRQ redirection table:\n"); - printk(KERN_DEBUG " NR Log Phy Mask Trig IRR Pol" - " Stat Dest Deli Vect: \n"); + printk(KERN_DEBUG " NR %s Msk Trg IRR Pol Stat DstM DelM Vec\n", + x2apic_enabled ? " DestID" : "Dst"); for (i = 0; i <= reg_01.bits.entries; i++) { struct IO_APIC_route_entry entry; entry = ioapic_read_entry(apic, i, 0); - printk(KERN_DEBUG " %02x %03X %02X ", - i, - entry.dest.logical.logical_dest, - entry.dest.physical.physical_dest - ); + if ( x2apic_enabled ) + printk(KERN_DEBUG " %02x %08x", i, entry.dest.dest32); + else + printk(KERN_DEBUG " %02x %02x ", i, + entry.dest.logical.logical_dest); - printk("%1d %1d %1d %1d %1d %1d %1d %02X\n", + printk(" %d %d %d %d %d %d %d %02X\n", entry.mask, entry.trigger, entry.irr, @@ -2481,12 +2481,14 @@ void dump_ioapic_irq_info(void) rte = ioapic_read_entry(entry->apic, pin, 0); printk("vec=%02x delivery=%-5s dest=%c status=%d " - "polarity=%d irr=%d trig=%c mask=%d dest_id:%d\n", + "polarity=%d irr=%d trig=%c mask=%d dest_id:%0*x\n", rte.vector, delivery_mode_2_str(rte.delivery_mode), rte.dest_mode ? 'L' : 'P', rte.delivery_status, rte.polarity, rte.irr, rte.trigger ? 'L' : 'E', rte.mask, - rte.dest.logical.logical_dest); + x2apic_enabled ? 8 : 2, + x2apic_enabled ? rte.dest.dest32 + : rte.dest.logical.logical_dest); if ( entry->next == 0 ) break;
In x2APIC mode it is 32 bits wide. In __print_IO_APIC() drop logging of both physical and logical IDs: The latter covers a superset of the bits of the former in the RTE, and we write full 8-bit values anyway even in physical mode for all ordinary interrupts, regardless of INT_DEST_MODE (see the users of SET_DEST()). Adjust other column arrangement (and heading) a little as well. Signed-off-by: Jan Beulich <jbeulich@suse.com> --- I'm sure I had found some place where the wider destination ID is documented for physical mode, but I wasn't able to find it again when I searched now. All Intel chipset docs I've looked at claim it's only 4 bits that are used / supposed to be stored.