linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
To: linuxppc-dev@lists.ozlabs.org
Cc: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>,
	Frederic Barrat <fbarrat@linux.vnet.ibm.com>,
	Andrew Donnellan <andrew.donnellan@au1.ibm.com>,
	Ian Munsie <imunsie@au1.ibm.com>,
	Christophe Lombard <christophe_lombard@fr.ibm.com>,
	Philippe Bergheaud <philippe.bergheaud@fr.ibm.com>,
	Greg Kurz <gkurz@linux.vnet.ibm.com>
Subject: [PATCH 0/3] cxl: Provide user-space r/o access to the AFU descriptor
Date: Tue, 14 Mar 2017 09:36:03 +0530	[thread overview]
Message-ID: <20170314040606.16894-1-vaibhav@linux.vnet.ibm.com> (raw)

Hi,

This patch-set provides a fix for libcxl github issue#20 
"libcxl doesn't handle a mmio read of 0xfffffff... (all 1's) correctly" at
https://github.com/ibm-capi/libcxl/issues/20.

The issue arises as libcxl uses mmio read values from problem-state-area(PSA) to
determine if the card had fenced or not. When it reads a value of 0xFFs (all 1)
it assumes that the card has fenced and returns an error for the mmio read.
Unfortunately 0xFFs can be a valid value in PSA of some some AFUs and in such
cases libcxl incorrectly assumes the card to be fenced and indicate and error to
the caller.

To fix this issue, the patch-set provides direct and read-only access of the afu
descriptor to libcxl via a binary sysfs attribute named 'afu_desc'. Libcxl can
mmap this attribute to process address space and if an mmio read returns 0xFFs
it tries reading contents of afu_desc at an offset whose contents != ~0x0ULL. If
the card is fenced read of the same offset will have contents == ~0x0ULL in
which case libcxl can indicate an error to the caller about the fenced card else
the read of 0xFFs is a valid read.


There are three patchset in this series:

- First patch refactors the function cxl_pci_afu_err_buffer() and moves its
  implementation to 'native.c'. It also moves the core logic of the function
  to a new function __aligned_memcpy().

- Second patch introduces a new sysfs attribute named afu_desc to be used by
  libcxl to read raw contents of afu descriptor.

- Third patch provides native implementations for new cxl backend-ops introduced
  in the previous patch. Most importantly it implements the afu_desc_mmap 
  backend-op thats mmaps the afu descriptor to a given vma.

Additional related changes apart from this patch-set:

- Corresponding libcxl changes are posted as a pull request#25 
  "libcxl: Check afu link when read from PSA mmio return all FFs" at
  https://github.com/ibm-capi/libcxl/pull/25

- Patch "kernfs: Check KERNFS_HAS_RELEASE before calling kernfs_release_file()"
  which fixes a kernel oops occurring while removing a bin_attribute from sysfs
  at https://patchwork.ozlabs.org/patch/738536/.

Vaibhav Jain (3):
  cxl: Re-factor cxl_pci_afu_read_err_buffer()
  cxl: Introduce afu_desc sysfs attribute
  cxl: Provide user-space access to afu descriptor on bare metal

 Documentation/ABI/testing/sysfs-class-cxl |  9 ++++
 drivers/misc/cxl/cxl.h                    | 15 ++++--
 drivers/misc/cxl/native.c                 | 89 ++++++++++++++++++++++++++++++-
 drivers/misc/cxl/pci.c                    | 47 ++--------------
 drivers/misc/cxl/sysfs.c                  | 45 ++++++++++++++++
 5 files changed, 157 insertions(+), 48 deletions(-)

-- 
2.9.3

             reply	other threads:[~2017-03-14  4:07 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-14  4:06 Vaibhav Jain [this message]
2017-03-14  4:06 ` [PATCH 1/3] cxl: Re-factor cxl_pci_afu_read_err_buffer() Vaibhav Jain
2017-03-17  4:34   ` Andrew Donnellan
2017-03-21  4:38     ` Vaibhav Jain
2017-03-17 10:51   ` Frederic Barrat
2017-03-14  4:06 ` [PATCH 2/3] cxl: Introduce afu_desc sysfs attribute Vaibhav Jain
2017-03-17 11:19   ` Frederic Barrat
2017-03-21  5:07     ` Vaibhav Jain
2017-03-20  7:42   ` Andrew Donnellan
2017-03-14  4:06 ` [PATCH 3/3] cxl: Provide user-space access to afu descriptor on bare metal Vaibhav Jain

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=20170314040606.16894-1-vaibhav@linux.vnet.ibm.com \
    --to=vaibhav@linux.vnet.ibm.com \
    --cc=andrew.donnellan@au1.ibm.com \
    --cc=christophe_lombard@fr.ibm.com \
    --cc=fbarrat@linux.vnet.ibm.com \
    --cc=gkurz@linux.vnet.ibm.com \
    --cc=imunsie@au1.ibm.com \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=philippe.bergheaud@fr.ibm.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 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).