On 29.01.2025 12:53, Marek Marczykowski-Górecki wrote: > On Wed, Jan 29, 2025 at 10:17:20AM +0100, Jan Beulich wrote: >> On 29.01.2025 04:22, Marek Marczykowski-Górecki wrote: >>> On Tue, Jan 28, 2025 at 09:03:15PM -0600, Bjorn Helgaas wrote: >>>> The report claims the problem only happens with Xen. I'm not a Xen >>>> person, and I don't know how to find the relevant config accessors. >>>> The snippets of kernel messages I see at [1] all mention pciback, so >>>> that's my only clue of where to look. Bottom line, I have no idea >>>> what the config accessor path is, and maybe we could learn something >>>> by looking at whatever it is. >>> >>> AFAIK there are no separate config accessors under Xen dom0, the default >>> ones are used. xen-pcifront takes over PCI config space access (and few >>> more) only in a domU (and only for PV), when PCI passthrough is used. >>> Here, it didn't went that far... >>> >>> But then, Xen may intercept such access [2]. If I read it right, it >>> should allow all access (is_hardware_domain(dom0)==true, and also the >>> device is not on ro_map - otherwise reset wouldn't work at all). >> >> The other day you mentioned (on Matrix I think) that you observe mmcfg >> not being used on that system. Am I misremembering? (Since the capability >> where the control bit lives is an extended one, that capability would >> neither be read nor modified when mmcfg is unavailable.) > > Yes, but later (once dom0 starts) it switched back to mmcfg. Now I see > this: > (XEN) PCI: MCFG configuration 0: base e0000000 segment 0000 buses 00 - ff > (XEN) PCI: Using MCFG for segment 0000 bus 00-ff > > Another thing I noticed in the bug report - the reporter says warm > reboot from 6.11 (where it works) to 6.12 avoids the issue (not sure > about further reboots). Cold boot directly to 6.12 results in this buggy > behavior. Makes things yet more odd, imo. Jan
