[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] HPET interrupt remapping during boot


  • To: Jan Beulich <jbeulich@xxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Wed, 9 Oct 2019 13:29:27 +0200
  • Authentication-results: esa3.hc3370-68.iphmx.com; dkim=none (message not signed) header.i=none; spf=None smtp.pra=roger.pau@xxxxxxxxxx; spf=Pass smtp.mailfrom=roger.pau@xxxxxxxxxx; spf=None smtp.helo=postmaster@xxxxxxxxxxxxxxx
  • Cc: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Wed, 09 Oct 2019 11:29:42 +0000
  • Ironport-sdr: 5xGCWlJUj6WqS+lKPWzBM3YX3xseJlk7Hup0x6n96XEJseCCVYya2aTB5lBreBgnDYkpDP3ST0 oi9HrNZq9SNjZZvQNl8SG0YugDz+qM87ku09lYw5w0S8TJivSbkGTvSm2crqsBgWNXH6Kot6Da VpaW6DMFfQGF5FKo2zsQNKQK7ydbeqRE6bYQBdwAxrN3EiW5kT5jyjvTsMNiLk+kx5wqDy1+XI UXVfIrOmXO+3/XI96UcaKGEpDpSFK6z5SjOuD45iB6dn/BId4/TMAlLUMoVt/dFpUVxt/UplkY P+k=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Wed, Oct 09, 2019 at 12:41:05PM +0200, Jan Beulich wrote:
> On 09.10.2019 12:11, Roger Pau Monné  wrote:
> > And it does print the following when setting up the iommu:
> > 
> > (XEN) ioapic 0 pin 0 not masked
> > (XEN) vec=00 delivery=ExINT dest=P status=0 polarity=0 irr=0 trig=E mask=0 
> > dest_id:00010000
> > 
> > I wonder, shouldn't all pins of all the io-apics be masked at boot?
> 
> I think you might get different answers here depending on whether
> you ask firmware or OS people. In fact there are cases where the
> IO-APIC needs to be left in this state, I think, but such would
> likely need properly reflecting in ACPI tables (albeit I don't
> know/recall how this would be done; looking at the code ). This goes back to 
> times
> when IO-APICs were new and OSes would not even know about them,
> yet they wouldn't get any interrupts to work if fiddling with
> only the PIC (sitting behind IO-APIC pin 0).
> 
> See enable_IO_APIC(), where we actually use this property to
> determine the pin behind which the 8259 sits.
> 
> I've seen quite many systems where in the BIOS setup you have an
> option to select whether you have an "ACPI OS" (wording of course
> varies). I've never checked whether this may e.g. reflect itself
> in the handover state of the GSI 0 RTE.
> 
> In your testing patch, could you also log the PIC mask bytes?
> There ought to be at least one unmasked; or wait - there actually
> is a spurious interrupt there (right before IOMMU initialization):
> 
> (XEN) spurious 8259A interrupt: IRQ7.

So I've added a log of the PIC masks just before checking the ioapic
masks:

(XEN) 8259A-1 mask: fe 8259A-2 mask: ff

AFAICT IRQ7 seems to be unmasked? Sorry my knowledge of PICs is quite
limited since I've never had to deal with them.

The line I've added is:

printk("8259A-1 mask: %x 8259A-2 mask: %x\n", inb(0x21), inb(0xA1));

I wonder why does Xen even has any code to deal with the PICs,
shouldn't we rely on io-apics only for legacy delivery?

> Hence I wonder if there's not possibly a 2nd one once the IOMMU
> has been set up.

Right, then I guess we either mask all the io-apic pins or we setup
proper remapping entries for non-masked pins? (in order to avoid iommu
faults)

Thanks, Roger.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.