On Mon, Oct 26, 2020 at 6:21 PM Thomas Gleixner <tglx@xxxxxxxxxxxxx> wrote: > [...] > > So, I don't want to hijack Liu's thread, but do you think it makes > > sense to have my approach as a (debug) parameter to prevent such a > > degenerate case? > > At least it makes sense to some extent even if it's incomplete. What > bothers me is that it'd be x86 specific while the issue is pretty much > architecture independent. I don't think that the APIC is special in that > regard. Rogue MSIs should be able to bring down pretty much all > architectures. > Thanks Thomas! I partially agree with you, I can speak only for x86 and powerpc. In x86 we know that happens, OK. But in powerpc, we had a special PCI reset, we called it IIRC "fundamental"/PHB reset - that procedure would put the PCI devices in good shape, it was something that the kernel could request from FW - see [0] for an example. It was present in all incarnations of powerpc (bare-metal, powerVM/PHyp - a virtual thing) except maybe in qemu (although it'd be possible to do that, since the PCI devices are attached on host and passthrough'ed via vfio). Anyway, in powerpc the PCI devices are really reset across "soft-reboots" be it kexec or what was called a fast reboot (that skipped some FW initializations), effectively disabling MSIs - x86 has no such default/vendor-agnostic reset infrastructure, BIOSes usually do some kind of PCI reset but with no interface for the kernel to request that in kexec, for example. That said, the option was to use the arch code to early-clear the MSI state in all devices, that being a kind of reset. And it's "supported" by the spec, that claims MSIs should be clear before devices' initialization =) Anyway, I'm glad to discuss more, and I'm even more glad that you consider the approach useful. We could revive that if Bjorn agrees, I could respin an updated version. ARM64/RISC-V or whatever other architectures I can't say about, but I think if they have early-PCI handlers (and !FW reset, like powerpc) it would be possible to implement that in a more complete way. > > Or could we have something in core IRQ code to prevent irq flooding in > > such scenarios, something "stronger" than disabling MSIs (APIC-level, > > likely)? > > For your case? No. The APIC cannot be protected against rogue MSIs. The > only cure is to disable interrupts or disable MSIs on all PCI[E] devices > early on. Disabling interrupts is not so much of an option obviously :) Great to know that, we imagined if it would be possible to have a more "soft" option, but it seems clearing MSIs is the way to go. Cheers, Guilherme [0] kernel portion: git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/platforms/powernv/pci-ioda.c#n3161 FW portion: github.com/open-power/skiboot/blob/master/core/pci-opal.c#L545 _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
