All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Bjorn Helgaas <helgaas@kernel.org>
Cc: francisco.munoz.ruiz@linux.intel.com, lorenzo.pieralisi@arm.com,
	jonathan.derrick@linux.dev, linux-pci@vger.kernel.org,
	Nirmal Patel <nirmal.patel@linux.intel.com>,
	Myron Stowe <myron.stowe@redhat.com>
Subject: Re: [PATCH V2] PCI: vmd: Fix secondary bus reset for Intel bridges
Date: Thu, 3 Nov 2022 11:15:36 -0600	[thread overview]
Message-ID: <20221103111536.3cf450fd.alex.williamson@redhat.com> (raw)
In-Reply-To: <20221102234221.GA8153@bhelgaas>

On Wed, 2 Nov 2022 18:42:21 -0500
Bjorn Helgaas <helgaas@kernel.org> wrote:

> [+cc Alex, Myron]
> 
> On Mon, Oct 31, 2022 at 02:45:01PM -0700, francisco.munoz.ruiz@linux.intel.com wrote:
> > From: Francisco Munoz <francisco.munoz.ruiz@linux.intel.com>
> > 
> > The reset was never applied in the current implementation because Intel
> > Bridges owned by VMD are parentless. Internally, pci_reset_bus applies
> > a reset to the parent of the pci device supplied as argument, but in this
> > case it failed because there wasn't a parent.
> > 
> > In more detail, this change allows the VMD driver to enumerate NVMe devices
> > in pass-through configurations when host reboots are performed. Commit id
> > “6aab5622296b990024ee67dd7efa7d143e7558d0” attempted to fix this, but
> > later we discovered that the code inside pci_reset_bus wasn’t triggering
> > secondary bus resets.  Therefore, we updated the parameters passed to
> > it, and now NVMe SSDs attached to VMD bridges are properly enumerated in
> > VT-d pass-through scenarios.  
> 
> Did you mean "guest reboots" above?  If the *host* reboots, I assume
> everybody (host and guests) starts over, so a reset wouldn't really
> apply.
> 
> Is the scenario that the VMD device is passed through to a guest, and
> the guest OS is running vmd_probe() and vmd_enable_domain()?
> 
> I thought VFIO already had something to reset devices between guests.
> But maybe this is different because from the point of view of VFIO,
> the pass-through happens only once, and during that single session,
> the guest OS reboots several times, so you want vmd_probe() to reset
> the downstream devices?
> 
> Should this have a Fixes: tag for 6aab5622296b?
> 
> s/pci/PCI/ above in English text.
> 
> Also add "()" after function names.
> 
> Use the typical 12-char SHA1 + subject citation, e.g., 6aab5622296b
> ("PCI: vmd: Clean up domain before enumeration").
> 
> > Signed-off-by: Francisco Munoz <francisco.munoz.ruiz@linux.intel.com>
> > Reviewed-by: Nirmal Patel <nirmal.patel@linux.intel.com>
> > ---
> >  drivers/pci/controller/vmd.c | 12 ++++++++++--
> >  1 file changed, 10 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/pci/controller/vmd.c b/drivers/pci/controller/vmd.c
> > index e06e9f4fc50f..34d6ba675440 100644
> > --- a/drivers/pci/controller/vmd.c
> > +++ b/drivers/pci/controller/vmd.c
> > @@ -859,8 +859,16 @@ static int vmd_enable_domain(struct vmd_dev *vmd, unsigned long features)
> >  
> >  	pci_scan_child_bus(vmd->bus);
> >  	vmd_domain_reset(vmd);
> > -	list_for_each_entry(child, &vmd->bus->children, node)
> > -		pci_reset_bus(child->self);
> > +
> > +	list_for_each_entry(child, &vmd->bus->children, node) {
> > +		if (!list_empty(&child->devices)) {
> > +			pci_reset_bus(list_first_entry(&child->devices,
> > +						       struct pci_dev,
> > +						       bus_list));

Do you want to test the return value here to avoid another case of not
actually doing what we expect it to do?  WARN_ON perhaps?  Thanks,

Alex

> > +			break;
> > +		}
> > +	}
> > +
> >  	pci_assign_unassigned_bus_resources(vmd->bus);
> >  
> >  	/*
> > -- 
> > 2.25.1
> > 
> > Hi Bjorn,
> > 
> > I updated the commit message with more details. Hopefully, this will 
> > clarify its purpose.
> > 
> > Thanks,
> > Francisco.  
> 


      parent reply	other threads:[~2022-11-03 17:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-23 20:37 [PATCH] PCI: vmd: Fix secondary bus reset for Intel bridges francisco.munoz.ruiz
2022-09-26 21:07 ` Jonathan Derrick
2022-10-06 18:26   ` Munoz Ruiz, Francisco
2022-10-06 19:21     ` Bjorn Helgaas
2022-10-24 20:45 ` Bjorn Helgaas
2022-10-31 21:45   ` [PATCH V2] " francisco.munoz.ruiz
2022-11-02 23:42     ` Bjorn Helgaas
2022-11-03  3:58       ` Munoz Ruiz, Francisco
2022-11-03 17:15       ` Alex Williamson [this message]

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=20221103111536.3cf450fd.alex.williamson@redhat.com \
    --to=alex.williamson@redhat.com \
    --cc=francisco.munoz.ruiz@linux.intel.com \
    --cc=helgaas@kernel.org \
    --cc=jonathan.derrick@linux.dev \
    --cc=linux-pci@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=myron.stowe@redhat.com \
    --cc=nirmal.patel@linux.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.