Message-ID: <d1cc0bee-2a98-0c2e-8796-6fb7fae6b803@broadcom.com>
Date:   Thu, 19 May 2022 12:20:54 -0700
From:   Scott Branden <scott.branden@...adcom.com>
To:     "Guilherme G. Piccoli" <gpiccoli@...lia.com>,
        Petr Mladek <pmladek@...e.com>,
        Sebastian Reichel <sre@...nel.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        Desmond yan <desmond.yan@...adcom.com>
Cc:     David Gow <davidgow@...gle.com>, Evan Green <evgreen@...omium.org>,
        Julius Werner <jwerner@...omium.org>,
        bcm-kernel-feedback-list@...adcom.com, linux-pm@...r.kernel.org,
        akpm@...ux-foundation.org, bhe@...hat.com,
        kexec@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linuxppc-dev@...ts.ozlabs.org, linux-alpha@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-edac@...r.kernel.org,
        linux-hyperv@...r.kernel.org, linux-leds@...r.kernel.org,
        linux-mips@...r.kernel.org, linux-parisc@...r.kernel.org,
        linux-remoteproc@...r.kernel.org, linux-s390@...r.kernel.org,
        linux-tegra@...r.kernel.org, linux-um@...ts.infradead.org,
        linux-xtensa@...ux-xtensa.org, netdev@...r.kernel.org,
        openipmi-developer@...ts.sourceforge.net, rcu@...r.kernel.org,
        sparclinux@...r.kernel.org, xen-devel@...ts.xenproject.org,
        x86@...nel.org, kernel-dev@...lia.com, kernel@...ccoli.net,
        halves@...onical.com, fabiomirmar@...il.com,
        alejandro.j.jimenez@...cle.com, andriy.shevchenko@...ux.intel.com,
        arnd@...db.de, bp@...en8.de, corbet@....net,
        d.hatayama@...fujitsu.com, dave.hansen@...ux.intel.com,
        dyoung@...hat.com, feng.tang@...el.com, gregkh@...uxfoundation.org,
        mikelley@...rosoft.com, hidehiro.kawai.ez@...achi.com,
        jgross@...e.com, john.ogness@...utronix.de, keescook@...omium.org,
        luto@...nel.org, mhiramat@...nel.org, mingo@...hat.com,
        paulmck@...nel.org, peterz@...radead.org, rostedt@...dmis.org,
        senozhatsky@...omium.org, stern@...land.harvard.edu,
        tglx@...utronix.de, vgoyal@...hat.com, vkuznets@...hat.com,
        will@...nel.org, Alexander Gordeev <agordeev@...ux.ibm.com>,
        Andrea Parri <parri.andrea@...il.com>,
        Ard Biesheuvel <ardb@...nel.org>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Brian Norris <computersforpeace@...il.com>,
        Christian Borntraeger <borntraeger@...ux.ibm.com>,
        Christophe JAILLET <christophe.jaillet@...adoo.fr>,
        "David S. Miller" <davem@...emloft.net>,
        Dexuan Cui <decui@...rosoft.com>,
        Doug Berger <opendmb@...il.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        Hari Bathini <hbathini@...ux.ibm.com>,
        Heiko Carstens <hca@...ux.ibm.com>,
        Justin Chen <justinpopo6@...il.com>,
        "K. Y. Srinivasan" <kys@...rosoft.com>,
        Lee Jones <lee.jones@...aro.org>,
        Markus Mayer <mmayer@...adcom.com>,
        Michael Ellerman <mpe@...erman.id.au>,
        Mihai Carabas <mihai.carabas@...cle.com>,
        Nicholas Piggin <npiggin@...il.com>,
        Paul Mackerras <paulus@...ba.org>, Pavel Machek <pavel@....cz>,
        Shile Zhang <shile.zhang@...ux.alibaba.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        Sven Schnelle <svens@...ux.ibm.com>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Tianyu Lan <Tianyu.Lan@...rosoft.com>,
        Vasily Gorbik <gor@...ux.ibm.com>,
        Wang ShaoBo <bobo.shaobowang@...wei.com>,
        Wei Liu <wei.liu@...nel.org>,
        zhenwei pi <pizhenwei@...edance.com>
Subject: Re: [PATCH 19/30] panic: Add the panic hypervisor notifier list



On 2022-05-19 05:19, Guilherme G. Piccoli wrote:
> On 18/05/2022 19:17, Scott Branden wrote:
>> Hi Guilherme,
>>
>> +Desmond
>> [...]
>>>>> I'm afraid it breaks kdump if this device is not reset beforehand - it's
>>>>> a doorbell write, so not high risk I think...
>>>>>
>>>>> But in case the not-reset device can be probed normally in kdump kernel,
>>>>> then I'm fine in moving this to the reboot list! I don't have the HW to
>>>>> test myself.
>>>>
>>>> Good question. Well, it if has to be called before kdump then
>>>> even "hypervisor" list is a wrong place because is not always
>>>> called before kdump.
>>> [...]
>> We register to the panic notifier so that we can kill the VK card ASAP
>> to stop DMAing things over to the host side.  If it is not notified then
>> memory may not be frozen when kdump is occurring.
>> Notifying the card on panic is also needed to allow for any type of
>> reset to occur.
>>
>> So, the only thing preventing moving the notifier later is the chance
>> that memory is modified while kdump is occurring.  Or, if DMA is
>> disabled before kdump already then this wouldn't be an issue and the
>> notification to the card (to allow for clean resets) can be done later.
> 
> Hi Scott / Desmond, thanks for the detailed answer! Is this adapter
> designed to run in x86 only or you have other architectures' use cases?
The adapter may be used in any PCIe design that supports DMA.
So it may be possible to run in arm64 servers.
> 
> I'm not expert on that, but I guess whether DMA is "kept" or not depends
> a bit if IOMMU is used. IIRC, there was a copy of the DMAR table in
> kdump (at least for Intel IOMMU). Also, devices are not properly
> quiesced on kdump IIUC, we don't call shutdown/reset handlers, they're
> skip due to the crash nature - so there is a risk of devices doing bad
> things in the new kernel.
> 
> With that said, and given this is a lightweight notifier that ideally
> should run ASAP, I'd keep this one in the hypervisor list. We can
> "adjust" the semantic of this list to include lightweight notifiers that
> reset adapters.
Sounds the best to keep system operating as tested today.
> 
> With that said, Petr has a point - not always such list is going to be
> called before kdump. So, that makes me think in another idea: what if we
> have another list, but not on panic path, but instead in the custom
> crash_shutdown()? Drivers could add callbacks there that must execute
> before kexec/kdump, no matter what.
It may be beneficial for some other drivers but for our use we would 
then need to register for the panic path and the crash_shutdown path. 
We notify the VK card for 2 purposes: one to stop DMA so memory stop 
changing during a kdump.  And also to get the card into a good state so 
resets happen cleanly.
> 
> Let me know your thoughts Scott / Desmond / Petr and all interested parties.
> Cheers,
> 
> 
> Guilherme

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4212 bytes)

Powered by blists - more mailing lists