linux-kernel - Re: platform/x86: p2sb: Allow p2sb_bar() calls during PCI device probe

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZzsRb4yXszugcLf8@smile.fi.intel.com>
Date: Mon, 18 Nov 2024 12:05:35 +0200
From: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To: Hans de Goede <hdegoede@...hat.com>
Cc: "Daniel Walker (danielwa)" <danielwa@...co.com>,
	Shin'ichiro Kawasaki <shinichiro.kawasaki@....com>,
	Ilpo J�rvinen <ilpo.jarvinen@...ux.intel.com>,
	Klara Modin <klarasmodin@...il.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Danil Rybakov <danilrybakov249@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"xe-linux-external(mailer list)" <xe-linux-external@...co.com>
Subject: Re: platform/x86: p2sb: Allow p2sb_bar() calls during PCI device
 probe

On Sat, Nov 16, 2024 at 12:34:54PM +0100, Hans de Goede wrote:
> On 13-Nov-24 8:17 PM, Andy Shevchenko wrote:
> > On Wed, Nov 13, 2024 at 05:33:41PM +0100, Hans de Goede wrote:

...

> > That said, messing up with that address is most likely a problematic there.
> 
> The relocation also happens in the provided working dmesg. I agree that
> the relocation is weird, but that does not appear to be the issue.

Hmm... I'm then wondering why we can't just unhide the device once at the early
boot (via [x86 specific] PCI quirk) and live with that... My most worries were
about relocation, but currently reading the documentations I see that this
shouldn't be a problem as the lowest 3 bytes define the target address on the
backbone anyway. I.o.w. it shouldn't matter what is written in the bits 63..24.

And FTR, I haven't found any specifics for Denverton, it's just an early
generation of P2SB RTL, but documentation says it should work as the others
on a basic levels (like what we expect from it in the Linux kernel).

> At least it was not an issue before we switched to caching the bar
> returned by p2sb_bar() early on so that p2sb_bar() does not need
> to take looks.

Anyway, it's easy to check just by caching the initial value of 0xfd000000
and see if it helps.

Another point here is the power management. Is there any PM handling during
the resource (re-)assignment? It might put the whole piece to D3hot and make
it not working. But I'm purely speculating here...

-- 
With Best Regards,
Andy Shevchenko