Received: by 10.223.185.116 with SMTP id b49csp1454853wrg; Wed, 21 Feb 2018 19:42:44 -0800 (PST) X-Google-Smtp-Source: AH8x224lt2T+E4UfsiG9e7GgOMcZBAgqadepfnTHuDs2910p+eIsVPIW++WL+p372t7UkYLBcpz9 X-Received: by 10.101.74.10 with SMTP id s10mr4604606pgq.219.1519270964779; Wed, 21 Feb 2018 19:42:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519270964; cv=none; d=google.com; s=arc-20160816; b=nMVoMCahweg5PJ4kOrm7hL1yIBI56Y4rjL29JRqurYcZAcxHTnZ+NqJsjSqowG9Ozd rgydt3/EDpg94CNtZKID+sGZ2gFVNWO2azOO1scqUVLqSbmtxfQjhcRF5nh3OiZUg+UH lrkvQQiU/Ju8DeJOJlyYA6OdSwvLwRb5hBapOJFbhSHdJSIF4aaErws4WS6jxDg5eYDf KLyQcJ/4RCGW9zUdOU3vfuV0r2mRkCqfraKAya8a+mu5hqt0ugqv/qT2H+t9AdcJAbBi KIcU0aSgA/oAvT64Iq5rojKLDehdt0GqXpItfokPo7hdJDlcTsOlqjunBmBjoRaa8Y7N yigQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=2Wvc2t84zX3QbVscsVI+sakdZD4tLkZKtYLKItM8rUg=; b=L1P4hi+sFs+tL2jzn+h09g8iv7WevCnyevxf0a9yB53nNGhN0L/h5IEgrrnEZ5doLq cPIsw5Azl7PRB8ZG1EkIvglpbEHyYva7ZY13iytKpM3znjc6W6ghHLhCK1R44ktZln+U Mz125D4iPyIi4M1CTBZXo9IEqqpU6D9jaPone4o1QyrYTa1xAx8POksBmVJBqOg5IIWh zr3MVxfCJKjW7vlIhbOw+Iu9jX0TbmaT5PzF791w8pUfAOmHe262COGV4COCLgeKUhy2 DMIhUQNZezWR3M+im/ifqqvOv1CVe2NE6f7rcURylqPN4PNIQzUecQkdfiIQMxebDGot BMKQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=dd7xG9Ae; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a3si699681pgc.455.2018.02.21.19.42.29; Wed, 21 Feb 2018 19:42:44 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=dd7xG9Ae; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752094AbeBVDlu (ORCPT + 99 others); Wed, 21 Feb 2018 22:41:50 -0500 Received: from mail-ua0-f194.google.com ([209.85.217.194]:37986 "EHLO mail-ua0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751810AbeBVDlt (ORCPT ); Wed, 21 Feb 2018 22:41:49 -0500 Received: by mail-ua0-f194.google.com with SMTP id e25so2464352uan.5 for ; Wed, 21 Feb 2018 19:41:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2Wvc2t84zX3QbVscsVI+sakdZD4tLkZKtYLKItM8rUg=; b=dd7xG9Aeo/wDj79zlqMUqQrsS/ngyG7EanrgHOCuZRufN9Q2AhzfUF/7VMHAUg6gJW N2049sxAxmW4Shdqxm2ljiXoL8qlFoPGR3vT7oloa6JQUBeS3E/MWyPuFMafn9vdKao6 bypy9wMuHKU44U/WpGria1oij4KFoiabb2+86wL2F98eAWS2ymbWs3Y6B6Xj/eQQYAPq nlkHC99CZWH++gL2VHx6/TBN0aH/OasTAUyT7AA/rOFtxaiUxnW8IVUzqQUSlnToDWu4 q1olRA9vP3h4ViXURr/KYjXnaED899AkEvRIunR02nZ5Sl6UKTrhweofxjR6IbsvUg/N 4ELA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2Wvc2t84zX3QbVscsVI+sakdZD4tLkZKtYLKItM8rUg=; b=jlIqR92IVBSm/Ivmu6ov7zi9Hu3IbaXgBPCCEo0YbFh4MzPKR9CCc4ASNP5sWYKHVn qlegQ2qNYzWqSMKn82kRX1DAmKZhdbsMZNAdTa7Bnu3lV/ghFsb2vwVqO5/fpa0diTUb b29CbZEaMNFvHrXOzpzTGw9ym3qLMK5STZ4pBYFCUf6elKtZb1dbW8MquoPRqQ2ZRX5X rsgJEUsBtbVGVpa3yyUQlwvBH7kkxJxqSig+bGkoFcu6snxUY5G/phpCjhrCPhnW4a0N tfCKyUgveWIU5sOTb373coKiBzpMWOn5EFYbfFCOp17xpB2TYsof4qYLD2LBwVHcMzwg T3bQ== X-Gm-Message-State: APf1xPDIsmmiz4N/cSqEc8s741bPDFsN0KuewVIl/80nmeBjatl1P0Bm cqhCR5QXGRwyW++rEUsZ4Fn/dSAOZZI0pVTIWUPDHw== X-Received: by 10.159.36.105 with SMTP id 96mr4071691uaq.188.1519270907970; Wed, 21 Feb 2018 19:41:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.97.142 with HTTP; Wed, 21 Feb 2018 19:41:47 -0800 (PST) In-Reply-To: <1519255934.2867.3.camel@au1.ibm.com> References: <20180221045736.7614-1-alastair@au1.ibm.com> <1519255934.2867.3.camel@au1.ibm.com> From: Balbir Singh Date: Thu, 22 Feb 2018 14:41:47 +1100 Message-ID: Subject: Re: [PATCH] ocxl: Add get_metadata IOCTL to share OCXL information to userspace To: "Alastair D'Silva" Cc: linuxppc-dev , "linux-kernel@vger.kernel.org" , Arnd Bergmann , frederic.barrat@fr.ibm.com, Greg KH , Andrew Donnellan Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 22, 2018 at 10:32 AM, Alastair D'Silva wrote: > > On Wed, 2018-02-21 at 17:43 +1100, Balbir Singh wrote: >> On Wed, Feb 21, 2018 at 3:57 PM, Alastair D'Silva > om> wrote: >> > From: Alastair D'Silva >> > >> > Some required information is not exposed to userspace currently >> > (eg. the >> > PASID), pass this information back, along with other information >> > which >> > is currently communicated via sysfs, which saves some parsing >> > effort in >> > userspace. >> > >> > Signed-off-by: Alastair D'Silva >> > --- >> > drivers/misc/ocxl/file.c | 27 +++++++++++++++++++++++++++ >> > include/uapi/misc/ocxl.h | 22 ++++++++++++++++++++++ >> > 2 files changed, 49 insertions(+) >> > >> > diff --git a/drivers/misc/ocxl/file.c b/drivers/misc/ocxl/file.c >> > index d9aa407db06a..11514a8444e5 100644 >> > --- a/drivers/misc/ocxl/file.c >> > +++ b/drivers/misc/ocxl/file.c >> > @@ -102,10 +102,32 @@ static long afu_ioctl_attach(struct >> > ocxl_context *ctx, >> > return rc; >> > } >> > >> > +static long afu_ioctl_get_metadata(struct ocxl_context *ctx, >> > + struct ocxl_ioctl_get_metadata __user *uarg) >> >> Why do we call this metadata? Isn't this an afu_descriptor? >> > > It's metadata for the descriptor. I meant metadata is too generic, could we have other types of metadata in OCXL? > >> > +{ >> > + struct ocxl_ioctl_get_metadata arg; >> > + >> > + memset(&arg, 0, sizeof(arg)); >> > + >> > + arg.version = 0; >> >> Does it make sense to have version 0? Even if does, you can afford >> to skip initialization due to the memset above. I prefer that >> versions >> start with 1 >> > > Setting it to 0 is for the reader, not the compiler. I'm not clear on > the benefit of starting the version at 1, could you clarify? How do I distinguish between version number never set and 0? > >> > + >> > + arg.afu_version_major = ctx->afu->config.version_major; >> > + arg.afu_version_minor = ctx->afu->config.version_minor; >> > + arg.pasid = ctx->pasid; >> > + arg.pp_mmio_size = ctx->afu->config.pp_mmio_stride; >> > + arg.global_mmio_size = ctx->afu->config.global_mmio_size; >> > + >> > + if (copy_to_user(uarg, &arg, sizeof(arg))) >> > + return -EFAULT; >> > + >> > + return 0; >> > +} >> > + >> > #define CMD_STR(x) (x == OCXL_IOCTL_ATTACH ? "ATTACH" >> > : \ >> > x == OCXL_IOCTL_IRQ_ALLOC ? "IRQ_ALLOC" >> > : \ >> > x == OCXL_IOCTL_IRQ_FREE ? "IRQ_FREE" >> > : \ >> > x == OCXL_IOCTL_IRQ_SET_FD ? "IRQ_SET_FD" >> > : \ >> > + x == OCXL_IOCTL_GET_METADATA ? >> > "GET_METADATA" : \ >> > "UNKNOWN") >> > >> > static long afu_ioctl(struct file *file, unsigned int cmd, >> > @@ -157,6 +179,11 @@ static long afu_ioctl(struct file *file, >> > unsigned int cmd, >> > irq_fd.eventfd); >> > break; >> > >> > + case OCXL_IOCTL_GET_METADATA: >> > + rc = afu_ioctl_get_metadata(ctx, >> > + (struct ocxl_ioctl_get_metadata >> > __user *) args); >> > + break; >> > + >> > default: >> > rc = -EINVAL; >> > } >> > diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h >> > index 4b0b0b756f3e..16e1f48ce280 100644 >> > --- a/include/uapi/misc/ocxl.h >> > +++ b/include/uapi/misc/ocxl.h >> > @@ -32,6 +32,27 @@ struct ocxl_ioctl_attach { >> > __u64 reserved3; >> > }; >> > >> > +/* >> > + * Version contains the version of the struct. >> > + * Versions will always be backwards compatible, that is, new >> > versions will not >> > + * alter existing fields >> > + */ >> > +struct ocxl_ioctl_get_metadata { >> >> This sounds more like a function name, do we need it to be >> _get_metdata? >> > > It pretty much is a function, it returns to userspace metadata about > the descriptor being operated on. > It has a verb indicating action >> > + __u16 version; >> > + >> > + // Version 0 fields >> > + __u8 afu_version_major; >> > + __u8 afu_version_minor; >> > + __u32 pasid; >> > + >> > + __u64 pp_mmio_size; >> > + __u64 global_mmio_size; >> > + >> >> Should we document the fields? pp_ stands for per process, but is not >> very clear at first look. Why do we care to return only the size, >> what >> about lpc size? >> > > Yes, I would rather call it per_pasid_mmio_size, but consistency with > the rest of the driver (& exposed sysfs entries) is also important. > Balbir Singh.