All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Sean O. Stalley" <sean.stalley@intel.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: linux-pci@vger.kernel.org, mj@ucw.cz, bhelgaas@google.com,
	david.daney@cavium.com
Subject: Re: [PATCH 1/2] pci: Identify Enhanced Allocation (EA) BAR Equivalent resources
Date: Fri, 22 Jan 2016 09:48:41 -0800	[thread overview]
Message-ID: <20160122174841.GA2913@sean.stalley.intel.com> (raw)
In-Reply-To: <1453415330.32741.384.camel@redhat.com>

On Thu, Jan 21, 2016 at 03:28:50PM -0700, Alex Williamson wrote:
> On Thu, 2016-01-21 at 14:13 -0800, Sean O. Stalley wrote:
> > From: Alex Williamson <alex.williamson@redhat.com>
> > 
> > We've done a pretty good job of abstracting EA from drivers, but there
> > are some properties of BAR Equivalent resources that don't really jive
> > with traditional PCI BARs.  In particular, natural alignment is only
> > encouraged, not required.
> > 
> > Why does this matter?  There are drivers like vfio-pci that will
> > happily gobble up the EA abstraction that's been implemented and
> > expose a device using EA to userspace as if those resources are
> > traditional BARs.  Pretty cool.  The vfio API is bus agnostic, so it
> > doesn't care about alignment.  The problem comes with PCI config space
> > emulation where we don't let userspace manipulate the BAR value, but
> > we do emulate BAR sizing.  The abstraction kind of falls apart if
> > userspace gets garbage when they try to size what appears to be a
> > traditional BAR, but is actually a BAR equivalent.
> > 
> > We could simply round up the size in vfio to make it naturally
> > aligned, but then we're imposing artificial sizes to the user and we
> > have the discontinuity that BAR size emulation and vfio region size
> > reporting don't agree on the size.  I think what we want to do is
> > expose EA to the user, reporting traditional BARs with BEIs as
> > zero-sized and providing additional regions for the user to access
> > each EA region, whether it has a BEI or not.
> > 
> > To facilitate that, a flag indicating whether a PCI resource is a
> > traditional BAR or BAR equivalent seems much nicer than attempting
> > to size the BAR ourselves or deducing it through the EA capability.
> > 
> > Thoughts?
> > 
> > Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> > ---
> 
> Feel free to rewrite this changelog and tailor it to the use case
> that's currently driving the change.  Add a sign-off for yourself too
> since the patch is passing through your hands.  Thanks,

Will do. I noticed it didn't fit, but didn't want to change it was in your name.
I'll rewrite the commit message to explain the current use-case.

Thanks,
Sean

> Alex
> 
> >  drivers/pci/pci.c      | 2 +-
> >  include/linux/ioport.h | 2 ++
> >  2 files changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
> > index d1a7105..8ff678c 100644
> > --- a/drivers/pci/pci.c
> > +++ b/drivers/pci/pci.c
> > @@ -2229,7 +2229,7 @@ void pci_pm_init(struct pci_dev *dev)
> >  
> >  static unsigned long pci_ea_flags(struct pci_dev *dev, u8 prop)
> >  {
> > -	unsigned long flags = IORESOURCE_PCI_FIXED;
> > +	unsigned long flags = IORESOURCE_PCI_FIXED | IORESOURCE_PCI_EA_BEI;
> >  
> >  	switch (prop) {
> >  	case PCI_EA_P_MEM:
> > diff --git a/include/linux/ioport.h b/include/linux/ioport.h
> > index 24bea08..5acc194 100644
> > --- a/include/linux/ioport.h
> > +++ b/include/linux/ioport.h
> > @@ -105,6 +105,8 @@ struct resource {
> >  /* PCI control bits.  Shares IORESOURCE_BITS with above PCI ROM.  */
> >  #define IORESOURCE_PCI_FIXED		(1<<4)	/* Do not move resource */
> >  
> > +/* PCI Enhanced Allocation defined BAR equivalent resource */
> > +#define IORESOURCE_PCI_EA_BEI		(1<<5)
> >  
> >  /* helpers to define resources */
> >  #define DEFINE_RES_NAMED(_start, _size, _name, _flags)			\
> 

  reply	other threads:[~2016-01-22 17:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-21 22:13 [PATCH 0/2] pci/lspci: Identify Enhanced Allocation (EA) Resources Sean O. Stalley
2016-01-21 22:13 ` [PATCH 1/2] pci: Identify Enhanced Allocation (EA) BAR Equivalent resources Sean O. Stalley
2016-01-21 22:28   ` Alex Williamson
2016-01-22 17:48     ` Sean O. Stalley [this message]
2016-01-21 22:13 ` [PATCH 2/2] Add support for enhanced allocation regions Sean O. Stalley
  -- strict thread matches above, loose matches on Subject: below --
2016-01-22 22:04 [PATCH 0/2] pci/lspci: Identify Enhanced Allocation (EA) Resources Sean O. Stalley
2016-01-22 22:04 ` [PATCH 1/2] pci: Identify Enhanced Allocation (EA) BAR Equivalent resources Sean O. Stalley
2016-02-04 23:13   ` 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=20160122174841.GA2913@sean.stalley.intel.com \
    --to=sean.stalley@intel.com \
    --cc=alex.williamson@redhat.com \
    --cc=bhelgaas@google.com \
    --cc=david.daney@cavium.com \
    --cc=linux-pci@vger.kernel.org \
    --cc=mj@ucw.cz \
    /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.