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) \
>
next prev parent 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 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).