All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: xuyandong <xuyandong2@huawei.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Yinghai Lu <yinghai@kernel.org>,
	Jesse Barnes <jbarnes@virtuousgeek.org>,
	"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
	Sagi Grimberg <sagi@grimberg.me>,
	Ofer Hayut <ofer@lightbitslabs.com>,
	Roy Shterman <roys@lightbitslabs.com>,
	Keith Busch <keith.busch@intel.com>,
	"Wangzhou (B)" <wangzhou1@hisilicon.com>
Subject: Re: [PATCH v3] PCI: avoid bridge feature re-probing on hotplug
Date: Tue, 22 Jan 2019 08:53:56 -0500	[thread overview]
Message-ID: <20190122085336-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <7CECC2DFC21538489F72729DF5EFB4D909EC77D4@dggemm501-mbs.china.huawei.com>

Thanks a lot for the testing!
I'll play with it today hopefully.

On Tue, Jan 22, 2019 at 05:31:10AM +0000, xuyandong wrote:
> Hi Bjorn and Michael
> 
> After trying to reproduce the problem for a whole day, the bug did not show up
> any more. So I think the new patch does solve this problem.
> 
> > -----Original Message-----
> > From: Bjorn Helgaas [mailto:helgaas@kernel.org]
> > Sent: Sunday, January 20, 2019 4:13 AM
> > To: Michael S. Tsirkin <mst@redhat.com>
> > Cc: linux-kernel@vger.kernel.org; xuyandong <xuyandong2@huawei.com>;
> > Yinghai Lu <yinghai@kernel.org>; Jesse Barnes <jbarnes@virtuousgeek.org>;
> > linux-pci@vger.kernel.org; Sagi Grimberg <sagi@grimberg.me>; Ofer Hayut
> > <ofer@lightbitslabs.com>; Roy Shterman <roys@lightbitslabs.com>; Keith
> > Busch <keith.busch@intel.com>; Wangzhou (B) <wangzhou1@hisilicon.com>
> > Subject: [PATCH v3] PCI: avoid bridge feature re-probing on hotplug
> > 
> > I gave up trying to reproduce the problem and test this patch with qemu; can
> > you guys (Michael and Xu (sorry if I mangled your name)) give this a try?
> > 
> > I cc'd a few other people who have noticed this issue in the past, so just FYI for
> > them.
> > 
> > Bjorn
> > 
> > 
> > commit dd21b922db366ba069291b6fef2a8ce6768756a2
> > Author: Bjorn Helgaas <bhelgaas@google.com>
> > Date:   Sat Jan 19 11:35:04 2019 -0600
> > 
> >     PCI: Probe bridge window attributes once at enumeration-time
> > 
> >     pci_bridge_check_ranges() determines whether a bridge supports the
> > optional
> >     I/O and prefetchable memory windows and sets the flag bits in the bridge
> >     resources.  This could be done once during enumeration except that the
> >     resource allocation code completely clears the flag bits, e.g., in the
> >     pci_assign_unassigned_bridge_resources() path.
> > 
> >     The problem was that in some cases pci_bridge_check_ranges() *changes*
> > the
> >     window registers to determine whether they're writable, and this may break
> >     concurrent accesses to devices behind the bridge.
> > 
> >     Add a new pci_read_bridge_windows() to determine whether a bridge
> > supports
> >     the optional windows, call it once during enumeration, remember the
> >     results, and change pci_bridge_check_ranges() to set the flag bits based on
> >     those remembered results.
> > 
> >     Link: https://lore.kernel.org/linux-pci/1506151482-113560-1-git-send-email-
> > wangzhou1@hisilicon.com
> >     Link: https://lists.gnu.org/archive/html/qemu-devel/2018-12/msg02082.html
> >     Reported-by: xuyandong <xuyandong2@huawei.com>
> >     Cc: Sagi Grimberg <sagi@grimberg.me>
> >     Cc: Ofer Hayut <ofer@lightbitslabs.com>
> >     Cc: Roy Shterman <roys@lightbitslabs.com>
> >     Cc: Keith Busch <keith.busch@intel.com>
> >     Cc: Zhou Wang <wangzhou1@hisilicon.com>
> > 
> > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index
> > 257b9f6f2ebb..2ef8b954c65a 100644
> > --- a/drivers/pci/probe.c
> > +++ b/drivers/pci/probe.c
> > @@ -348,6 +348,57 @@ static void pci_read_bases(struct pci_dev *dev,
> > unsigned int howmany, int rom)
> >  	}
> >  }
> > 
> > +static void pci_read_bridge_windows(struct pci_dev *bridge) {
> > +	u16 io;
> > +	u32 pmem, tmp;
> > +
> > +	pci_read_config_word(bridge, PCI_IO_BASE, &io);
> > +	if (!io) {
> > +		pci_write_config_word(bridge, PCI_IO_BASE, 0xe0f0);
> > +		pci_read_config_word(bridge, PCI_IO_BASE, &io);
> > +		pci_write_config_word(bridge, PCI_IO_BASE, 0x0);
> > +	}
> > +	if (io)
> > +		bridge->io_window = 1;
> > +
> > +	/*
> > +	 * DECchip 21050 pass 2 errata: the bridge may miss an address
> > +	 * disconnect boundary by one PCI data phase.  Workaround: do not
> > +	 * use prefetching on this device.
> > +	 */
> > +	if (bridge->vendor == PCI_VENDOR_ID_DEC && bridge->device ==
> > 0x0001)
> > +		return;
> > +
> > +	pci_read_config_dword(bridge, PCI_PREF_MEMORY_BASE, &pmem);
> > +	if (!pmem) {
> > +		pci_write_config_dword(bridge, PCI_PREF_MEMORY_BASE,
> > +					       0xffe0fff0);
> > +		pci_read_config_dword(bridge, PCI_PREF_MEMORY_BASE,
> > &pmem);
> > +		pci_write_config_dword(bridge, PCI_PREF_MEMORY_BASE,
> > 0x0);
> > +	}
> > +	if (!pmem)
> > +		return;
> > +
> > +	bridge->pref_window = 1;
> > +
> > +	if ((pmem & PCI_PREF_RANGE_TYPE_MASK) ==
> > PCI_PREF_RANGE_TYPE_64) {
> > +
> > +		/*
> > +		 * Bridge claims to have a 64-bit prefetchable memory
> > +		 * window; verify that the upper bits are actually
> > +		 * writable.
> > +		 */
> > +		pci_read_config_dword(bridge, PCI_PREF_BASE_UPPER32,
> > &pmem);
> > +		pci_write_config_dword(bridge, PCI_PREF_BASE_UPPER32,
> > +				       0xffffffff);
> > +		pci_read_config_dword(bridge, PCI_PREF_BASE_UPPER32,
> > &tmp);
> > +		pci_write_config_dword(bridge, PCI_PREF_BASE_UPPER32,
> > pmem);
> > +		if (tmp)
> > +			bridge->pref_64_window = 1;
> > +	}
> > +}
> > +
> >  static void pci_read_bridge_io(struct pci_bus *child)  {
> >  	struct pci_dev *dev = child->self;
> > @@ -1739,6 +1790,7 @@ int pci_setup_device(struct pci_dev *dev)
> >  		pci_read_irq(dev);
> >  		dev->transparent = ((dev->class & 0xff) == 1);
> >  		pci_read_bases(dev, 2, PCI_ROM_ADDRESS1);
> > +		pci_read_bridge_windows(dev);
> >  		set_pcie_hotplug_bridge(dev);
> >  		pos = pci_find_capability(dev, PCI_CAP_ID_SSVID);
> >  		if (pos) {
> > diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c index
> > ed960436df5e..1941bb0a6c13 100644
> > --- a/drivers/pci/setup-bus.c
> > +++ b/drivers/pci/setup-bus.c
> > @@ -735,58 +735,21 @@ int pci_claim_bridge_resource(struct pci_dev
> > *bridge, int i)
> >     base/limit registers must be read-only and read as 0. */  static void
> > pci_bridge_check_ranges(struct pci_bus *bus)  {
> > -	u16 io;
> > -	u32 pmem;
> >  	struct pci_dev *bridge = bus->self;
> > -	struct resource *b_res;
> > +	struct resource *b_res = &bridge->resource[PCI_BRIDGE_RESOURCES];
> > 
> > -	b_res = &bridge->resource[PCI_BRIDGE_RESOURCES];
> >  	b_res[1].flags |= IORESOURCE_MEM;
> > 
> > -	pci_read_config_word(bridge, PCI_IO_BASE, &io);
> > -	if (!io) {
> > -		pci_write_config_word(bridge, PCI_IO_BASE, 0xe0f0);
> > -		pci_read_config_word(bridge, PCI_IO_BASE, &io);
> > -		pci_write_config_word(bridge, PCI_IO_BASE, 0x0);
> > -	}
> > -	if (io)
> > +	if (bridge->io_window)
> >  		b_res[0].flags |= IORESOURCE_IO;
> > 
> > -	/*  DECchip 21050 pass 2 errata: the bridge may miss an address
> > -	    disconnect boundary by one PCI data phase.
> > -	    Workaround: do not use prefetching on this device. */
> > -	if (bridge->vendor == PCI_VENDOR_ID_DEC && bridge->device ==
> > 0x0001)
> > -		return;
> > -
> > -	pci_read_config_dword(bridge, PCI_PREF_MEMORY_BASE, &pmem);
> > -	if (!pmem) {
> > -		pci_write_config_dword(bridge, PCI_PREF_MEMORY_BASE,
> > -					       0xffe0fff0);
> > -		pci_read_config_dword(bridge, PCI_PREF_MEMORY_BASE,
> > &pmem);
> > -		pci_write_config_dword(bridge, PCI_PREF_MEMORY_BASE,
> > 0x0);
> > -	}
> > -	if (pmem) {
> > +	if (bridge->pref_window) {
> >  		b_res[2].flags |= IORESOURCE_MEM |
> > IORESOURCE_PREFETCH;
> > -		if ((pmem & PCI_PREF_RANGE_TYPE_MASK) ==
> > -		    PCI_PREF_RANGE_TYPE_64) {
> > +		if (bridge->pref_64_window) {
> >  			b_res[2].flags |= IORESOURCE_MEM_64;
> >  			b_res[2].flags |= PCI_PREF_RANGE_TYPE_64;
> >  		}
> >  	}
> > -
> > -	/* double check if bridge does support 64 bit pref */
> > -	if (b_res[2].flags & IORESOURCE_MEM_64) {
> > -		u32 mem_base_hi, tmp;
> > -		pci_read_config_dword(bridge, PCI_PREF_BASE_UPPER32,
> > -					 &mem_base_hi);
> > -		pci_write_config_dword(bridge, PCI_PREF_BASE_UPPER32,
> > -					       0xffffffff);
> > -		pci_read_config_dword(bridge, PCI_PREF_BASE_UPPER32,
> > &tmp);
> > -		if (!tmp)
> > -			b_res[2].flags &= ~IORESOURCE_MEM_64;
> > -		pci_write_config_dword(bridge, PCI_PREF_BASE_UPPER32,
> > -				       mem_base_hi);
> > -	}
> >  }
> > 
> >  /* Helper function for sizing routines: find first available diff --git
> > a/include/linux/pci.h b/include/linux/pci.h index 65f1d8c2f082..40b327b814aa
> > 100644
> > --- a/include/linux/pci.h
> > +++ b/include/linux/pci.h
> > @@ -373,6 +373,9 @@ struct pci_dev {
> >  	bool		match_driver;		/* Skip attaching driver */
> > 
> >  	unsigned int	transparent:1;		/* Subtractive decode bridge
> > */
> > +	unsigned int	io_window:1;		/* Bridge has I/O window */
> > +	unsigned int	pref_window:1;		/* Bridge has pref mem
> > window */
> > +	unsigned int	pref_64_window:1;	/* Pref mem window is 64-bit
> > */
> >  	unsigned int	multifunction:1;	/* Multi-function device */
> > 
> >  	unsigned int	is_busmaster:1;		/* Is busmaster */

  reply	other threads:[~2019-01-22 13:54 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-18  0:45 [PATCH v2] PCI: avoid bridge feature re-probing on hotplug Michael S. Tsirkin
2018-12-20 19:49 ` Bjorn Helgaas
2018-12-20 21:26   ` Michael S. Tsirkin
2018-12-20 22:31     ` Bjorn Helgaas
2018-12-20 22:36       ` Michael S. Tsirkin
2019-01-07 15:01         ` Michael S. Tsirkin
2019-01-15  4:07         ` Michael S. Tsirkin
2019-01-15 22:23           ` Bjorn Helgaas
2019-01-19 20:12 ` [PATCH v3] " Bjorn Helgaas
2019-01-20 14:49   ` Michael S. Tsirkin
2019-01-22  5:31   ` xuyandong
2019-01-22 13:53     ` Michael S. Tsirkin [this message]
2019-01-22 18:58     ` Bjorn Helgaas

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=20190122085336-mutt-send-email-mst@kernel.org \
    --to=mst@redhat.com \
    --cc=helgaas@kernel.org \
    --cc=jbarnes@virtuousgeek.org \
    --cc=keith.busch@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=ofer@lightbitslabs.com \
    --cc=roys@lightbitslabs.com \
    --cc=sagi@grimberg.me \
    --cc=wangzhou1@hisilicon.com \
    --cc=xuyandong2@huawei.com \
    --cc=yinghai@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 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.