From: Bjorn Helgaas <helgaas@kernel.org>
To: Nirmal Patel <nirmal.patel@linux.intel.com>
Cc: linux-pci@vger.kernel.org, samruddh.dhope@intel.com,
"Rafael J. Wysocki" <rjw@rjwysocki.net>,
Kai-Heng Feng <kai.heng.feng@canonical.com>
Subject: Re: [PATCH v2] PCI: vmd: Enable Hotplug based on BIOS setting on VMD rootports
Date: Thu, 1 Feb 2024 16:22:45 -0600 [thread overview]
Message-ID: <20240201222245.GA650725@bhelgaas> (raw)
In-Reply-To: <2cf8a41181e07ec15dbc95e42c527b6429db8c50.camel@linux.intel.com>
On Tue, Jan 16, 2024 at 01:37:32PM -0700, Nirmal Patel wrote:
> On Fri, 2024-01-12 at 16:55 -0600, Bjorn Helgaas wrote:
> ...
> > I think we're converging on the idea that since VMD is effectively
> > *not* an ACPI host bridge and doesn't have its own _OSC, the _OSC
> > that applies to the VMD endpoint does *not* apply to the hierarchy
> > below the VMD. In that case, the default is that the OS owns all
> > the features (hotplug, AER, etc) below the VMD.
>
> Well there will be few problems if VMD owns/assigns all the flags by
> itself. We discussed all of the potential problems but due to the
> holidays I think I should summarize them again.
>
> #1 : Currently there is no way to pass the information about AER,
> DPC, etc to VMD driver from BIOS or from boot parameter. For
> example, if VMD blindly enables AER and platform has AER disabled,
> then we will see AERs from devices under VMD but user have no way to
> toggle it since we rejected idea of adding boot parameter for AER,
> DPC under VMD. I believe you also didn't like the idea of sysfs knob
> suggested by Kai-Heng.
>
> #2 : Even if we use VMD hardware register to store AER, DPC and make
> UEFI VMD driver to write information about Hotplug, DPC, AER, we
> still dont have a way to change the setting if user wants to alter
> them. Also the issue will still persist in client platforms since we
> don't own their UEFI VMD driver. It will be a huge effort.
>
> #3 : At this moment, user can enable/disable only Hotplug in VMD
> BIOS settings (meaning no AER, DPC, LTR, etc)and VMD driver can read
> it from SltCap register. This means BIOS needs to add other settings
> and VMD needs to figure out to read them which at this moment VMD
> can't do it.
>
> #4 : consistency with Host OS and Guest OS.
>
> I believe the current proposed patch is the best option which
> requires minimal changes without breaking other platform features
> and unblock our customers. This issues has been a blocker for us.
>
> For your concerns regarding how VMD can own all the _OSC features, i
> am open to other ideas and will discuss with the architect if they
> have any suggestions.
As I understand it, the basic model of PCIe features is:
- If platform doesn't have a way to negotiate ownership of PCIe
features, the OS owns them by default, e.g., on non-ACPI systems.
- If platform does have a way to negotiate, e.g., ACPI _OSC, the
platform owns the features until it grants ownership to the OS.
- If the OS has ownership (either by default or granted by
platform), it can use the feature if the hardware device
advertises support.
I think this model applies to all PCIe features, including hotplug,
AER, DPC, etc., and the OS uses _OSC and the Capabilities in device
config space to determine whether to use the features.
_OSC is the obvious way for a platform to use BIOS settings to
influence what the OS does. I think the problem with VMD is that you
have a guest OS running on a platform (the guest VM) where you want a
host BIOS setting to control things in that guest platform, but
there's currently no way to influence the _OSC seen by the guest.
I think we need to:
- Clarify whether _OSC only applies in the domain of the host bridge
where it appears, i.e., an _OSC in a host bridge to domain 0000
obviously applies to a VMD Endpoint in domain 0000; does it also
apply to devices in the domain 10000 *below* the VMD Endpoint?
- Describe what the VMD bridge does with events below it. E.g.,
normally a Root Port that receives an error Message generates an
interrupt depending on its Interrupt Disable and Error Reporting
Enable bits. What happens when it's a VMD Root Port? Does it
forward an error Message up via the VMD Endpoint? Generate an
interrupt via the VMD Endpoint? If so, which interrupt?
The question of where _OSC applies feels like an architectural thing.
The question of how AER, DPC, hotplug, etc. events are forwarded
across the VMD Root Port/Endpoint might be, too, or maybe that's all
driver-specific, I dunno. Either way, I think it's worth documenting
somehow.
Bjorn
next prev parent reply other threads:[~2024-02-01 22:23 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-27 21:17 [PATCH v2] PCI: vmd: Enable Hotplug based on BIOS setting on VMD rootports Nirmal Patel
2023-12-02 0:07 ` Bjorn Helgaas
2023-12-05 22:20 ` Nirmal Patel
2023-12-06 0:27 ` Bjorn Helgaas
2023-12-11 23:05 ` Nirmal Patel
2023-12-12 21:13 ` Bjorn Helgaas
2023-12-14 1:07 ` Nirmal Patel
2023-12-14 19:23 ` Bjorn Helgaas
2023-12-14 22:22 ` Nirmal Patel
2024-01-12 0:02 ` Nirmal Patel
2024-01-12 22:55 ` Bjorn Helgaas
2024-01-16 20:37 ` Nirmal Patel
2024-01-17 0:49 ` Bjorn Helgaas
2024-02-01 21:16 ` Bjorn Helgaas
2024-02-01 18:38 ` Nirmal Patel
2024-02-01 23:00 ` Bjorn Helgaas
2024-02-07 0:27 ` Nirmal Patel
2024-02-07 18:55 ` Bjorn Helgaas
2024-02-13 17:47 ` Nirmal Patel
2024-03-06 22:27 ` Nirmal Patel
2024-03-07 6:44 ` Kai-Heng Feng
2024-03-08 0:09 ` Nirmal Patel
2024-03-15 1:29 ` Kai-Heng Feng
2024-03-22 20:57 ` Nirmal Patel
2024-03-22 21:37 ` Bjorn Helgaas
2024-03-22 22:43 ` Paul M Stillwell Jr
2024-03-22 23:36 ` Bjorn Helgaas
2024-03-25 15:10 ` Paul M Stillwell Jr
2024-03-26 0:17 ` Nirmal Patel
2024-03-26 1:59 ` Kai-Heng Feng
2024-03-26 15:51 ` Paul M Stillwell Jr
2024-03-26 16:03 ` Paul M Stillwell Jr
2024-03-26 21:08 ` Bjorn Helgaas
2024-04-02 16:10 ` Paul M Stillwell Jr
2024-02-01 22:22 ` Bjorn Helgaas [this message]
2024-01-16 23:54 ` Bjorn Helgaas
2024-02-14 13:43 ` Lorenzo Pieralisi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240201222245.GA650725@bhelgaas \
--to=helgaas@kernel.org \
--cc=kai.heng.feng@canonical.com \
--cc=linux-pci@vger.kernel.org \
--cc=nirmal.patel@linux.intel.com \
--cc=rjw@rjwysocki.net \
--cc=samruddh.dhope@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.