All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jason Gunthorpe <jgg@ziepe.ca>
To: Leon Romanovsky <leon@kernel.org>
Cc: Cheng Xu <chengyou@linux.alibaba.com>,
	linux-rdma@vger.kernel.org, KaiShen@linux.alibaba.com
Subject: Re: [PATCH for-next v2 2/2] RDMA/erdma: Support non-4K page size in doorbell allocation
Date: Tue, 21 Mar 2023 11:30:13 -0300	[thread overview]
Message-ID: <ZBm/deQgMYfdPt/u@ziepe.ca> (raw)
In-Reply-To: <20230315102210.GT36557@unreal>

On Wed, Mar 15, 2023 at 12:22:10PM +0200, Leon Romanovsky wrote:
> On Wed, Mar 15, 2023 at 09:58:06AM +0800, Cheng Xu wrote:
> > 
> > 
> > On 3/14/23 10:10 PM, Leon Romanovsky wrote:
> > > On Tue, Mar 14, 2023 at 07:50:19PM +0800, Cheng Xu wrote:
> > >>
> > >>
> > <...>
> > >>
> > >> Our doorbell space is aligned to 4096, this works fine when PAGE_SIZE is
> > >> also 4096, and the doorbell space starts from the mapped page. When
> > >> PAGE_SIZE is not 4096, the doorbell space may starts from the middle of
> > >> the mapped page.
> > >>
> > >> For example, our SQ doorbell starts from the offset 4096 in PCIe bar 0.
> > >> When we map the first SQ doorbell to userspace when PAGE_SIZE is 64K,
> > >> the doorbell space starts from the offset 4096 in mmap returned address.
> > >>
> > >> So the userspace needs to know the doorbell space offset in mmaped page.
> > > 
> > > And can't you preserve same alignment in the kernel for doorbells for every page size?
> > > Just always start from 0.
> > > 
> > 
> > I've considered this option before, but unfortunately can't, at least for CQ DB.
> > The size of our PCIe bar 0 is 512K, and offset [484K, 508K] are CQ doorbells.
> > CQ doorbell space is located in offset [36K, 60K] when PAGE_SIZE = 64K, and can't
> > start from offset 0 in this case.
> > 
> > Another reason is that we want to organize SQ doorbell space in unit of 4096.
> > In current implementation, each ucontext will be assigned a SQ doorbell space
> > for both normal doorbell and direct wqe usage. Unit of 4096, compared with
> > larger unit, more ucontexts can be assigned exclusive doorbell space for direct
> > wqe.
> 
> I have a feeling that there is an existing API for it already.
> Let's give a chance for Jason to chime in.

This sounds similar to how mlx5 chops up its doorbell space

But I don't understand your device security model.

In mlx5 it is not allowed to share doorbells between unrelated
processes. Doorbells have built in security and a doorbell can only
trigger QP/CQ's that are explicitly linked to that doorbell.

Thus mlx5 is careful to only mmap doorbells that are linked to the
QPs. On 64K page size userspace receives alot of doorbells per mmap,
all linked to the same security context.

Improperly sharing MMIO pages can result in various security problems
if a hostile userspace can write arbitary things to MMIO space.

Here you seem to be talking about overmapping stuff. What is the
security argument that it is safe to leak to userspace parts of the
device MMIO BAR beyond that strictly cotnained to the single doorbell?

This has to be clearly explained in the commit message and a comment.

Jason

  reply	other threads:[~2023-03-21 14:30 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-07 10:29 [PATCH for-next v2 0/2] RDMA/erdma: Add non-4K page size support Cheng Xu
2023-03-07 10:29 ` [PATCH for-next v2 1/2] RDMA/erdma: Use fixed hardware page size Cheng Xu
2023-03-24 14:34   ` Jason Gunthorpe
2023-03-07 10:29 ` [PATCH for-next v2 2/2] RDMA/erdma: Support non-4K page size in doorbell allocation Cheng Xu
2023-03-14 10:23   ` Leon Romanovsky
     [not found]     ` <5b0cc34d-a185-d9b4-c312-27bc959d929d@linux.alibaba.com>
2023-03-14 11:34       ` Cheng Xu
2023-03-14 11:50     ` Cheng Xu
2023-03-14 14:10       ` Leon Romanovsky
2023-03-15  1:58         ` Cheng Xu
2023-03-15 10:22           ` Leon Romanovsky
2023-03-21 14:30             ` Jason Gunthorpe [this message]
2023-03-22  7:05               ` Cheng Xu
2023-03-22 11:54                 ` Jason Gunthorpe
2023-03-22 13:30                   ` Cheng Xu
2023-03-22 14:01                     ` Jason Gunthorpe
2023-03-22 15:09                       ` Gal Pressman
2023-03-23  6:57                       ` Cheng Xu
2023-03-23 11:53                         ` Jason Gunthorpe
2023-03-23 12:33                           ` Cheng Xu
2023-03-23 13:05                             ` Jason Gunthorpe
2023-03-23 14:10                               ` Cheng Xu
2023-03-23 14:18                                 ` Jason Gunthorpe
2023-03-26  0:10                                   ` Cheng Xu

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=ZBm/deQgMYfdPt/u@ziepe.ca \
    --to=jgg@ziepe.ca \
    --cc=KaiShen@linux.alibaba.com \
    --cc=chengyou@linux.alibaba.com \
    --cc=leon@kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    /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.