Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Sender: Ingo Molnar <mingo.kernel.org@gmail.com>
Date:   Fri, 14 May 2021 18:19:41 +0200
From:   Ingo Molnar <mingo@kernel.org>
To:     David Laight <David.Laight@aculab.com>
Cc:     'Thomas Gleixner' <tglx@linutronix.de>,
        'Maximilian Luz' <luzmaximilian@gmail.com>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        "H. Peter Anvin" <hpa@zytor.com>, Sachi King <nakato@nakato.io>,
        "x86@kernel.org" <x86@kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "stable@vger.kernel.org" <stable@vger.kernel.org>
Subject: Re: [PATCH] x86/i8259: Work around buggy legacy PIC
Message-ID: <YJ6jHYM5oXyYHIX9@gmail.com>
References: <20210512210459.1983026-1-luzmaximilian@gmail.com>
 <9b70d8113c084848b8d9293c4428d71b@AcuMS.aculab.com>
 <e7dbd4d1-f23f-42f0-e912-032ba32f9ec8@gmail.com>
 <e43d9a823c9e44bab0cdbf32a000c373@AcuMS.aculab.com>
 <87tun54gg3.ffs@nanos.tec.linutronix.de>
 <bbf5d417ee0d4edbbed31f19ef40fad0@AcuMS.aculab.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <bbf5d417ee0d4edbbed31f19ef40fad0@AcuMS.aculab.com>
Precedence: bulk


* David Laight <David.Laight@ACULAB.COM> wrote:

> > > It is also worth noting that the probe code is spectacularly crap.
> > > It writes 0xff and then checks that 0xff is read back.
> > > Almost anything (including a failed PCIe read to the ISA bridge)
> > > will return 0xff and make the test pass.
> > 
> >         unsigned char probe_val = ~(1 << PIC_CASCADE_IR);
> > 
> > 	outb(probe_val, PIC_MASTER_IMR);
> > 	new_val = inb(PIC_MASTER_IMR);
> > 
> > How is that writing 0xFF?
> 
> Sorry I misread the code and diagnostic output.
> 
> In any case writing a value and expecting the same value back
> isn't exactly a high-quality probe.

It's not, and it's not intended to be: 0x21 is a well-known port nobody was 
crazy enough to override yet, so that probe basically filters out the 
"there is nothing at that port, at all" case, which would normally return 
0xff, or in a few weird cases 0x00 perhaps.

Writing something inbetween those values and getting the same value back 
tells us that something functional occupies that well-known IO-port, 
pretending to be a i8259 PIC.

Which is what we wanted to know, given the context.

Thanks,

	Ingo