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 [thread overview]
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
next prev parent reply other threads:[~2021-05-14 11:15 UTC|newest]
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
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).