Linux-ACPI Archive on lore.kernel.org
 help / color / Atom feed
From: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
To: Jonathan Cameron <Jonathan.Cameron@Huawei.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
	Ira Weiny <ira.weiny@intel.com>,
	linux-cxl@vger.kernel.org, Linux PCI <linux-pci@vger.kernel.org>,
	Bjorn Helgaas <helgaas@kernel.org>,
	Ben Widawsky <ben.widawsky@intel.com>,
	Chris Browy <cbrowy@avery-design.com>,
	Linux ACPI <linux-acpi@vger.kernel.org>,
	"Schofield, Alison" <alison.schofield@intel.com>,
	Vishal L Verma <vishal.l.verma@intel.com>,
	Linuxarm <linuxarm@huawei.com>, Fangjian <f.fangjian@huawei.com>
Subject: Re: [RFC PATCH v3 2/4] PCI/doe: Add Data Object Exchange support
Date: Fri, 14 May 2021 12:15:38 +0100
Message-ID: <20210514111538.GA16218@lpieralisi> (raw)
In-Reply-To: <20210514094755.00002081@Huawei.com>

On Fri, May 14, 2021 at 09:47:55AM +0100, Jonathan Cameron wrote:
> On Thu, 13 May 2021 14:20:38 -0700
> Dan Williams <dan.j.williams@intel.com> wrote:
> 
> > On Tue, May 11, 2021 at 9:52 AM Jonathan Cameron
> > <Jonathan.Cameron@huawei.com> wrote:
> > >
> > > On Thu, 6 May 2021 14:59:34 -0700
> > > Ira Weiny <ira.weiny@intel.com> wrote:
> > >  
> > > > On Tue, Apr 20, 2021 at 12:54:49AM +0800, Jonathan Cameron wrote:  
> > > > > +
> > > > > +static int pci_doe_send_req(struct pci_doe *doe, struct pci_doe_exchange *ex)
> > > > > +{
> > > > > +   struct pci_dev *pdev = doe->pdev;
> > > > > +   u32 val;
> > > > > +   int i;
> > > > > +
> > > > > +   /*
> > > > > +    * Check the DOE busy bit is not set. If it is set, this could indicate
> > > > > +    * someone other than Linux (e.g. firmware) is using the mailbox. Note
> > > > > +    * it is expected that firmware and OS will negotiate access rights via
> > > > > +    * an, as yet to be defined method.
> > > > > +    */
> > > > > +   pci_read_config_dword(pdev, doe->cap + PCI_DOE_STATUS, &val);
> > > > > +   if (FIELD_GET(PCI_DOE_STATUS_BUSY, val))
> > > > > +           return -EBUSY;  
> > > >
> > > > In discussion with Dan we believe that user space could also be issuing
> > > > commands and would potentially cause us to be locked out.
> > > >
> > > > We agree that firmware should be out of the way here and if it is blocking
> > > > the OS there is not much we can do about it.
> > > >
> > > > However, if user space is using the mailbox we need to synchronize with them
> > > > via pci_cfg_access_[try]lock().  This should avoid this EBUSY condition.  
> > >
> > > Hi Ira, thanks for taking a look.
> > >
> > > So the question here is whether we can ever safely work with a
> > > userspace that is accessing the DOE.  I think the answer is no we can't.
> > >
> > > We'd have no way of knowing that userspace left the DOE in a clean state
> > > without resetting every time we want to use it (which can take 1 second)
> > > or doing significant sanity checking (can we tell if something is
> > > in flight?).  Note that if userspace and kernel were talking different
> > > protocols nothing sensible could be done to prevent them receiving each
> > > other's answers (unless you can rely on userspace holding the lock until
> > > it is done - which you can't as who trusts userspace?)  
> > 
> > There is no ability for userpsace to lock out the kernel, only kernel
> > locking out userspace.
> 
> Hi Dan,
> 
> Got it. Writing userspace to code with arbitrary kernel
> breakage of exchanges userspace initialized is going to be nasty. 
> 
> > 
> > > You could do
> > > something horrible like back off after peeking at the protocol to see
> > > if it might be yours, but even that only works assuming the two are
> > > trying to talk different protocols (talking the same protocol isn't allowed
> > > but no way to enforce that using just pci_cfg_access_lock()).  
> > 
> > Wait why isn't pci_cfg_access_lock() sufficient? The userspace DOE
> > transfer is halted, the kernel validates the state of DOE, does it's
> > work and releases the lock.
> 
> It's that 'validate the state of the DOE' which is the problem.  I 'think'
> the only way to do that is to issue an abort every time and I'm really
> not liking the fact that adds a potential 1 second sleep to every
> DOE access from the kernel.

IIUC an abort would mean game over for *every* transaction in flight,
not sure that's the best way of preventing userspace from mingling
but as you mentioned I don't think there is a way around it with the
current protocol.

I don't see how a lock would solve this issue either - how would it ?

Basically you have to stop userspace from issuing requests for the
duration of a request/response (per-protocol) session, right ?

Lorenzo

  reply index

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-19 16:54 [RFC PATCH v3 0/4] PCI Data Object Exchange support + CXL CDAT Jonathan Cameron
2021-04-19 16:54 ` [RFC PATCH v3 1/4] PCI: Add vendor ID for the PCI SIG Jonathan Cameron
2021-04-19 16:54 ` [RFC PATCH v3 2/4] PCI/doe: Add Data Object Exchange support Jonathan Cameron
2021-05-06 21:59   ` Ira Weiny
2021-05-11 16:50     ` Jonathan Cameron
2021-05-13 21:20       ` Dan Williams
2021-05-14  8:47         ` Jonathan Cameron
2021-05-14 11:15           ` Lorenzo Pieralisi [this message]
2021-05-14 12:39             ` Jonathan Cameron
2021-05-14 18:37           ` Dan Williams
2021-05-17  8:40             ` Jonathan Cameron
2021-05-17  8:51               ` Greg KH
2021-05-17 17:21               ` Dan Williams
2021-05-18 10:04                 ` Jonathan Cameron
2021-05-19 14:18                   ` Dan Williams
2021-05-19 15:11                     ` Jonathan Cameron
2021-05-19 15:29                       ` Dan Williams
2021-05-19 16:20                         ` Jonathan Cameron
2021-05-19 16:33                           ` Jonathan Cameron
2021-05-19 16:53                             ` Dan Williams
2021-05-19 17:00                               ` Jonathan Cameron
2021-05-19 19:20                                 ` Dan Williams
2021-05-19 20:18                                   ` Jonathan Cameron
2021-05-19 23:51                                     ` Dan Williams
2021-05-20  0:16                                       ` Dan Williams
2021-05-20  8:22                                       ` Jonathan Cameron
2021-05-07  9:36   ` Jonathan Cameron
2021-05-07 23:10   ` Bjorn Helgaas
2021-05-12 12:44     ` Jonathan Cameron
2021-04-19 16:54 ` [RFC PATCH v3 3/4] cxl/mem: Add CDAT table reading from DOE Jonathan Cameron
2021-04-19 16:54 ` [RFC PATCH v3 4/4] cxl/mem: Add a debug parser for CDAT commands Jonathan Cameron

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=20210514111538.GA16218@lpieralisi \
    --to=lorenzo.pieralisi@arm.com \
    --cc=Jonathan.Cameron@Huawei.com \
    --cc=alison.schofield@intel.com \
    --cc=ben.widawsky@intel.com \
    --cc=cbrowy@avery-design.com \
    --cc=dan.j.williams@intel.com \
    --cc=f.fangjian@huawei.com \
    --cc=helgaas@kernel.org \
    --cc=ira.weiny@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-cxl@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linuxarm@huawei.com \
    --cc=vishal.l.verma@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

Linux-ACPI Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-acpi/0 linux-acpi/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-acpi linux-acpi/ https://lore.kernel.org/linux-acpi \
		linux-acpi@vger.kernel.org
	public-inbox-index linux-acpi

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-acpi


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git