From: Maximilian Luz <email@example.com>
To: "H. Peter Anvin" <firstname.lastname@example.org>,
Thomas Gleixner <email@example.com>,
Sachi King <firstname.lastname@example.org>, Ingo Molnar <email@example.com>,
Borislav Petkov <firstname.lastname@example.org>,
David Laight <David.Laight@aculab.com>
Cc: "email@example.com" <firstname.lastname@example.org>,
Subject: Re: [PATCH] x86/i8259: Work around buggy legacy PIC
Date: Sat, 15 May 2021 00:47:44 +0200 [thread overview]
Message-ID: <email@example.com> (raw)
On 5/14/21 7:35 PM, H. Peter Anvin wrote:
> On 5/14/21 10:32 AM, Thomas Gleixner wrote:
>> That's a valid assumption. As I said, we can make IOAPIC work even w/o
>> PIC. I'll have a look how much PIC assumptions are still around.
> As far as I read, the problem isn't actually the absence of a PIC (we definitely boot systems without PICs all the time now), but rather that the PIC is advertised in ACPI but is buggy or absent; a similar platform with different firmware doesn't have problem.
> If my understanding of the thread is correct, it's quirk fodder.
I believe the theory was that, while the PIC is advertised in ACPI, it
might be expected to not be used and only present for some legacy reason
(therefore untested and buggy). Which I believe led to the question
whether we shouldn't prefer IOAPIC on systems like that in general. So I
guess it comes down to how you define "systems like that". By Tomas'
comment, I guess it should be possible to implement this as "systems
that should prefer IOAPIC over legacy PIC" quirk.
I guess all modern machines should have an IOAPIC, so it might also be
preferable to expand that definition, maybe over time and with enough
If possible, I think that would be preferable to the "just retry until
it works" kind of workaround.
As Sachi mentioned in her reply:
> I'm not sure the i8259 is needed on the device, as the interrupts
> appear to function on the device if I bypass the nr_legacy_irqs() check
> while the legacy_pic is set to the null_legacy_pic.
> The null_legacy_pic however specifies having 0 irqs, and the io_apic
> does not allow us to set the pin attributes unless the pin we are
> attempting to set is less than nr_legacy_irqs.
> The IOAPIC seems to take responsibility for the 0-15 interrupts on this
> specific hardware, should we maybe be ignoring the i8259 and looking
> into allowing interrupts 0-15 to be setup even when the legacy_pic is
> not available?
Just my two cents, please keep in mind that I'm out of my depth here.
next prev parent reply other threads:[~2021-05-14 22:47 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-12 21:04 [PATCH] x86/i8259: Work around buggy legacy PIC Maximilian Luz
2021-05-13 8:10 ` David Laight
2021-05-13 10:11 ` Maximilian Luz
2021-05-13 10:36 ` David Laight
2021-05-14 13:01 ` Thomas Gleixner
2021-05-14 13:13 ` David Laight
2021-05-14 16:19 ` Ingo Molnar
2021-05-14 19:41 ` Sachi King
2021-05-14 10:51 ` David Laight
2021-05-14 11:58 ` Maximilian Luz
2021-05-14 17:32 ` Thomas Gleixner
2021-05-14 17:35 ` H. Peter Anvin
2021-05-14 22:47 ` Maximilian Luz [this message]
2021-05-17 18:40 ` Thomas Gleixner
2021-05-17 19:25 ` Maximilian Luz
2021-05-17 23:27 ` Thomas Gleixner
2021-05-18 8:28 ` Andy Shevchenko
2021-05-18 19:58 ` Sachi King
2021-05-18 15:45 ` Thomas Gleixner
2021-05-14 13:44 ` Thomas Gleixner
2021-05-14 16:12 ` David Laight
2021-05-14 17:28 ` H. Peter Anvin
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).