linux-kernel - Re: [PATCH v2] PCI/MSI: Don't touch MSI bits when the PCI device is disconnected

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]

Date:   Wed, 14 Nov 2018 19:41:12 +0000
From:   "Derrick, Jonathan" <jonathan.derrick@...el.com>
To:     "Alex_Gagniuc@...lteam.com" <Alex_Gagniuc@...lteam.com>,
        "helgaas@...nel.org" <helgaas@...nel.org>
CC:     "Austin.Bolen@...l.com" <Austin.Bolen@...l.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "Shyam.Iyer@...l.com" <Shyam.Iyer@...l.com>,
        "sbobroff@...ux.ibm.com" <sbobroff@...ux.ibm.com>,
        "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
        "ruscur@...sell.cc" <ruscur@...sell.cc>,
        "oohall@...il.com" <oohall@...il.com>,
        "mr.nuke.me@...il.com" <mr.nuke.me@...il.com>,
        "lukas@...ner.de" <lukas@...ner.de>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        "Busch, Keith" <keith.busch@...el.com>
Subject: Re: [PATCH v2] PCI/MSI: Don't touch MSI bits when the PCI device is
 disconnected

On Wed, 2018-11-14 at 19:22 +0000, Alex_Gagniuc@...lteam.com wrote:
[snip]
> The whole issue of firmware-first, the mechanism by which
> > > > firmware
> > > > gets control, the System Error enables in Root Port Root
> > > > Control
> > > > registers, etc., is very murky to me.  Jon has a sort of
> > > > similar issue
> > > > with VMD where he needs to leave System Errors enabled instead
> > > > of
> > > > disabling them as we currently do.
> > > 
> > > Well, OS gets control via _OSC method, and based on that it
> > > should
> > > touch/not touch the AER bits.
> > 
> > I agree so far.
> > 
> > > The bits that get set/cleared come from _HPX method,
> > 
> > _HPX tells us about some AER registers, Device Control, Link
> > Control,
> > and some bridge registers.  It doesn't say anything about the Root
> > Control register that Jon is concerned with.
> 
> _HPX type 3 (yay!!!) got approved recently, and that will have more 
> fine-grained control. It will be able to handle root control reg.
> 
> > For firmware-first to work, firmware has to get control.  How does
> > it
> > get control?  How does OSPM know to either set up that mechanism or
> > keep its mitts off something firmware set up before handoff?
> 
> My understanding is that, if FW keeps control of AER in _OSC, then
> it 
> will have set things up to get notified instead of the OS. OSPM not 
> touching AER bits is to make sure it doesn't mess up FW's setup. I
> think 
> there are some proprietary bits in the root port to route interrupts
> to 
> SMIs instead of the AER vectors.
> 
> > In Jon's
> > VMD case, I think firmware-first relies on the System Error
> > controlled
> > by the Root Control register.  Linux thinks it owns that, and I
> > don't
> > know how to learn otherwise.
> 
> Didn't Keith say the root port is not visible to the OS?
> 
> Alex

That's correct. OS visibility wrt ACPI is limited to the VMD
endpoint/host bridge device which exposes the root ports. The root
ports aren't described by ACPI. VMD is the unusual case.

In VMD case, we might or might not need to pass back control to AER for
further error handling post FFS. I can see that's normally done by GHES
but will probably need some shimming to support the VMD case. I can't
rely on AER, because if any other devices use APEI, then the AER module
won't be initialized (aer_service_init::aer_acpi_firmware_first)
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (3278 bytes)