On Mon, Dec 11, 2023 at 04:05:25PM -0700, Nirmal Patel wrote:
> On Tue, 2023-12-05 at 18:27 -0600, Bjorn Helgaas wrote:
> > On Tue, Dec 05, 2023 at 03:20:27PM -0700, Nirmal Patel wrote:
> > ...
> > > Currently Hotplug is controlled by _OSC in both host and Guest.
> > > In case of guest, it seems guest BIOS hasn't implemented _OSC
> > > since all the flags are set to 0 which is not the case in host.
> >
> > I think you want pciehp to work on the VMD Root Ports in the
> > Guest, no matter what, on the assumption that any _OSC that
> > applies to host bridge A does not apply to the host bridge created
> > by the vmd driver.
> >
> > If so, we should just revert 04b12ef163d1 ("PCI: vmd: Honor ACPI
> > _OSC on PCIe features"). Since host bridge B was not enumerated
> > via ACPI, the OS owns all those features under B by default, so
> > reverting 04b12ef163d1 would leave that state.
> >
> > Obviously we'd have to first figure out another solution for the
> > AER message flood that 04b12ef163d1 resolved.
>
> If we revert 04b12ef163d1, then VMD driver will still enable AER
> blindly which is a bug. So we need to find a way to make VMD driver
> aware of AER platform setting and use that information to enable or
> disable AER for its child devices.
>
> There is a setting in BIOS that allows us to enable OS native AER
> support on the platform. This setting is located in EDK Menu ->
> Platform configuration -> system event log -> IIO error enabling ->
> OS native AER support.
>
> This setting is assigned to VMD bridge by vmd_copy_host_bridge_flags
> in patch 04b12ef163d1. Without the patch 04b12ef163d1, VMD driver
> will enable AER even if platform has disabled OS native AER support
> as mentioned earlier. This will result in an AER flood mentioned in
> 04b12e f163d1 since there is no AER handlers.
>
> I believe the rate limit will not alone fix the issue rather will
> act as a work around.
I agree with this part. A rate limit would not solve the problem of
an interrupt storm consuming the CPU. That could be addressed by
switching to polling when the rate is high or possibly other ways.
> If VMD is aware of OS native AER support setting, then we will not
> see AER flooding issue.
>
> Do you have any suggestion on how to make VMD driver aware of AER
> setting and keep it in sync with platform setting.
Well, this is the whole problem. IIUC, you're saying we should use
_OSC to negotiate for AER control below the VMD bridge, but ignore
_OSC for hotplug control.
I don't see how to read the _OSC spec and decide which things apply
below a VMD bridge and which things don't.
But I think a proposal that "_OSC doesn't apply to any devices below a
VMD bridge," that *is* a pretty generic principle. If we think that's
the right way to use _OSC, shouldn't the vmd driver be able to
configure AER for devices below the VMD bridge in any way it wants?
I'm not sure what "_OSC doesn't apply below a VMD" would mean for
things like firmware-first error logging below the VMD. Maybe
firmware-first doesn't make sense below VMD anyway because firmware
and the OS have different ideas about the Segment for those devices?
Bjorn
