On Tue, 2023-12-12 at 15:13 -0600, Bjorn Helgaas wrote:
> 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.
Because VMD has it's own hotplug BIOS setting which allows vmd to
enable or disable hotplug on it's domain. However we dont have VMD
specific AER, DPC, LTR settings. Is it okay if we include an additional
check for hotplug? i.e. Hotplug capable bit in SltCap register which
reflects VMD BIOS hotplug setting.
Another way is to overwrite _OSC setting for hotplug only in Guest OS.
If we make VMD driver aware of Host or Guest environment, only in case
of Guest we overwrite _OSC hotplug using SltCap register and we don't
revert the 04b12ef163d1.
>
> 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
