[kata-dev] Guest kernel and CONFIG_PCI_MMCONFIG
Christophe de Dinechin
cdupontd at redhat.com
Tue Jul 27 09:58:56 UTC 2021
> On 26 Jul 2021, at 11:44, David Gibson <kata-dev at gibson.dropbear.id.au> wrote:
>
> Hello all,
>
> I recently discovered that the kernel config generated by
> tools/packaging/kernel has CONFIG_PCI_MMCONFIG disabled.
I'm curious how much difference it makes in memory size (if at all).
I suspect things that were configured out were most likely selected to
reduce the kernel size more than for any other reason.
> That's probably not a good idea, since that's a very atypical config for
> modern systems, and for complicated reasons it completely stops SHPC
> hotplug from working.
That's weird. Shouldn't that be abstracted behind pci_read_config_byte() and
the like? Now you make me curious why this breaks SHPC hotplug. If
you have the time to explain ;-) Does this seem like a kernel bug or some
hardware / architectural limitation?
>
> So, I've filed
> https://github.com/kata-containers/kata-containers/pull/2311 to change
> it.
>
> But..
>
> I have reason to suspect that anyone using Kata's VFIO support is
> actually *relying* on this bogus guest behaviour to make things work.
> In all my experiements when I try to use VFIO devices with a more
> normal kernel, the device is detected in the guest after the agent's
> rescan and works, but only briefly. When the SHPC hotplug completes
> 5s later, this interferes somehow and puts the device in a badly
> broken state (config space accesses fail completely)[0].
>
> To make things harder, seeing how this affects the CI is also non-trivial:
> 1) Changing the config in the kata-containers repo will not (AFAICT)
> trigger a rebuild of the cached guest kernel in the CI, and so it
> will be tested effectively without the change.
> 2) The vfio CI testcase is pretty rudimentary. I think it's quite
> likely it could complete fast enough to succeed and shut down
> before the SHPC hotplug completes and breaks the device
>
> At this point I'm inclined to just push the change anyway and deal
> with the fallout as and when it occurs. But does any one have a
> better idea?
>
>
> [0] In fact, if disable_idle_d3=N for the vfio-pci module, it even
> puts the device into a broken state in the *host*, requiring a
> host reboot to restore.
>
> --
> David Gibson | I'll have my music baroque, and my code
> david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
> | _way_ _around_!
> http://www.ozlabs.org/~dgibson
> _______________________________________________
> kata-dev mailing list
> kata-dev at lists.katacontainers.io
> http://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev
More information about the kata-dev
mailing list