linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nirmal Patel <nirmal.patel@linux.intel.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH] PCI: vmd: Enable Hotplug based on BIOS setting on VMD rootports
Date: Tue, 31 Oct 2023 12:59:34 -0700	[thread overview]
Message-ID: <f0b9e19c7a976f7a81b55f432a4ed29324b319fc.camel@linux.intel.com> (raw)
In-Reply-To: <20231031153144.GA10760@bhelgaas>

On Tue, 2023-10-31 at 10:31 -0500, Bjorn Helgaas wrote:
> On Mon, Oct 30, 2023 at 04:16:54PM -0400, Nirmal Patel wrote:
> > VMD Hotplug should be enabled or disabled based on VMD rootports'
> > Hotplug configuration in BIOS. is_hotplug_bridge is set on each
> > VMD rootport based on Hotplug capable bit in SltCap in probe.c.
> > Check is_hotplug_bridge and enable or disable native_pcie_hotplug
> > based on that value.
> > 
> > Currently VMD driver copies ACPI settings or platform
> > configurations
> > for Hotplug, AER, DPC, PM, etc and enables or disables these
> > features
> > on VMD bridge which is not correct in case of Hotplug.
> 
> This needs some background about why it's correct to copy the ACPI
> settings in the case of AER, DPC, PM, etc, but incorrect for hotplug.
> 
> > Also during the Guest boot up, ACPI settings along with VMD UEFI
> > driver are not present in Guest BIOS which results in assigning
> > default values to Hotplug, AER, DPC, etc. As a result Hotplug is
> > disabled on VMD in the Guest OS.
> > 
> > This patch will make sure that Hotplug is enabled properly in Host
> > as well as in VM.
> 
> Did we come to some consensus about how or whether _OSC for the host
> bridge above the VMD device should apply to devices in the separate
> domain below the VMD?
We are not able to come to any consensus. Someone suggested to copy
either all _OSC flags or none. But logic behind that assumption is
that the VMD is a bridge device which is not completely true. VMD is an
endpoint device and it owns its domain.

Also please keep this in your consideration, since Guest BIOS
doesn't have _OSC implementation, all of the flags Hotplug, AER, DPC
are set to power state default value and VMD's very important hotplug
functionality is broken.

The patch 04b12ef163d1 assumes VMD is a bridge device and borrows/
*imposes system settings* for AER, DPC, Hotplug, PM, etc on VMD.
VMD is*type 0 PCI endpoint* device and all the PCI devices under VMD
are *privately *owned by VMD not by the OS.

Also VMD has its own Hotplug setting for its rootports in BIOS under
VMD settings that are different from global BIOS system settings. It is
these settings that give VMD its own unique functionality.

That is why I suggested three solutions but never got any confirmation.

#1: Revert the patch 04b12ef163d1 which was added under wrong
assumption. This patch didn't need to be added to VMD code if AER
was disabled from BIOS platform settings.

#2: VMD driver disables AER by copying AER BIOS system settings
which the patch 04b12ef163d1 does but do not change Hotplug.
I proposed this patch and didn't get approval.

#3: If hotplug is enabled on VMD root ports, make sure hotplug is
enabled on the bridge rootports are connected to. The proposed patch
does that.

Can we please come to some decision? VM Hotplug is an important part of
VMD and customers are reporting VM Hotplug issues. I would like to get
some progress on this one.

Thanks
nirmal
> I think this warrants some clarification and possibly discussion in
> the PCI firmware SIG.
> 
> At the very least, the commit log should mention _OSC and say
> something about the fact that this is assuming PCIe hotplug ownership
> for devices below VMD, regardless of what the upstream _OSC said.
> 
> > Signed-off-by: Nirmal Patel <nirmal.patel@linux.intel.com>
> > ---
> > ---
> >  drivers/pci/controller/vmd.c | 11 ++++++++++-
> >  1 file changed, 10 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/pci/controller/vmd.c
> > b/drivers/pci/controller/vmd.c
> > index 769eedeb8802..e39eaef5549a 100644
> > --- a/drivers/pci/controller/vmd.c
> > +++ b/drivers/pci/controller/vmd.c
> > @@ -720,6 +720,7 @@ static int vmd_enable_domain(struct vmd_dev
> > *vmd, unsigned long features)
> >  	resource_size_t membar2_offset = 0x2000;
> >  	struct pci_bus *child;
> >  	struct pci_dev *dev;
> > +	struct pci_host_bridge *vmd_bridge;
> >  	int ret;
> >  
> >  	/*
> > @@ -886,8 +887,16 @@ static int vmd_enable_domain(struct vmd_dev
> > *vmd, unsigned long features)
> >  	 * and will fail pcie_bus_configure_settings() early. It can
> > instead be
> >  	 * run on each of the real root ports.
> >  	 */
> > -	list_for_each_entry(child, &vmd->bus->children, node)
> > +	vmd_bridge = to_pci_host_bridge(vmd->bus->bridge);
> > +	list_for_each_entry(child, &vmd->bus->children, node) {
> >  		pcie_bus_configure_settings(child);
> > +		/*
> > +		 * When Hotplug is enabled on vmd root-port, enable it
> > on vmd
> > +		 * bridge.
> > +		 */
> > +		if (child->self->is_hotplug_bridge)
> > +			vmd_bridge->native_pcie_hotplug = 1;
> > +	}
> >  
> >  	pci_bus_add_devices(vmd->bus);
> >  
> > -- 
> > 2.31.1
> > 


  reply	other threads:[~2023-10-31 19:52 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-30 20:16 [PATCH] PCI: vmd: Enable Hotplug based on BIOS setting on VMD rootports Nirmal Patel
2023-10-31 15:31 ` Bjorn Helgaas
2023-10-31 19:59   ` Nirmal Patel [this message]
2023-10-31 23:26     ` Nirmal Patel
2023-11-01 22:20     ` Bjorn Helgaas
2023-11-02 20:07       ` Nirmal Patel
2023-11-02 20:41         ` Bjorn Helgaas
2023-11-02 23:49           ` Nirmal Patel
2023-11-07 21:50             ` Nirmal Patel
2023-11-07 22:30               ` Bjorn Helgaas
2023-11-08 14:49                 ` Kai-Heng Feng
2023-11-08 19:44                   ` Nirmal Patel
2023-11-14 21:07                   ` Nirmal Patel
2023-12-06  2:18                     ` Kai-Heng Feng
2023-12-06 16:30                       ` Bjorn Helgaas
2023-12-11 23:19                         ` Nirmal Patel
2023-12-12  3:20                           ` Kai-Heng Feng
2023-11-14 23:29                 ` Nirmal Patel
2023-10-31 20:11   ` Nirmal Patel

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=f0b9e19c7a976f7a81b55f432a4ed29324b319fc.camel@linux.intel.com \
    --to=nirmal.patel@linux.intel.com \
    --cc=helgaas@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).