[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8acfd9b2-caae-4fe7-8d37-19e2d9be23a8@suse.com>
Date: Wed, 29 Jan 2025 14:54:41 +0100
From: Jan Beulich <jbeulich@...e.com>
To: Bjorn Helgaas <helgaas@...nel.org>
Cc: Marek Marczykowski-Górecki
<marmarek@...isiblethingslab.com>, Bjorn Helgaas <bhelgaas@...gle.com>,
Jürgen Groß <jgross@...e.com>,
Roger Pau Monné <roger.pau@...rix.com>,
Boris Ostrovsky <boris.ostrovsky@...cle.com>,
xen-devel <xen-devel@...ts.xenproject.org>, linux-kernel@...r.kernel.org,
regressions@...ts.linux.dev, Felix Fietkau <nbd@....name>,
Lorenzo Bianconi <lorenzo@...nel.org>, Ryder Lee <ryder.lee@...iatek.com>,
linux-pci@...r.kernel.org
Subject: Re: Config space access to Mediatek MT7922 doesn't work after device
reset in Xen PV dom0 (regression, Linux 6.12)
On 29.01.2025 14:28, Bjorn Helgaas 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.)
>
> If you're referring to the Configuration RRS Software Visibility
> Enable bit, that's in the PCIe Capability Root Control register, which
> is in the PCI-compatible config space (the first 256 bytes), not the
> extended config space.
Oh, I clearly didn't read Marek's earlier mail correctly. I'm sorry for that.
Jan
Powered by blists - more mailing lists