Received: by 10.223.185.116 with SMTP id b49csp1271894wrg; Wed, 21 Feb 2018 15:33:46 -0800 (PST) X-Google-Smtp-Source: AH8x224etSDb+YWM/orUxlMTaWtnk1BWoyFZUFobnOXc8Bv+5btmjeRD/brdOEKY47W6DskYd+l1 X-Received: by 10.101.92.66 with SMTP id v2mr3998018pgr.341.1519256026245; Wed, 21 Feb 2018 15:33:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519256026; cv=none; d=google.com; s=arc-20160816; b=oL1O/oB2AudlIU7Ukk6RovBc1R0tVF8LSPba6SEHE14czcmUWRk7o5ECKlejzSA+ZN OJ4sk1KWecUVe6pdxWrAYV5wt+Wkz40+EwBgAdh6bmBraZGIDNUKkbUHQ6ed+FRXYp3v GpI9ttQxQxGqIrNOIvleVWSJo+FZxVjcgE/Dp5BLM4iCi9BSLHu630tu4v4GpQPwm+AS 4EQhAKLFXplvmnfjPLmHBMa2Mo4nHWW4lYgOFz0auFjbvdAGFb2637XRQ8+8ooBQyJp0 rkwE+KttbPik4TVQ5mnJHoBPNhg2gV6En9xWXzOyusI4d4XzTjZBrU5/ObRSxhs1ToSY E5Cw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:content-transfer-encoding :mime-version:organization:references:in-reply-to:date:cc:to:from :subject:arc-authentication-results; bh=TQJIARAYyuAPN5zamdEjPSSH+iU1z05eed3db8dCAGw=; b=CLXNbuDoRY8QilEvVYqFbd/TVfBfUT/uJyTxxw8RaeCQv+fTMWqvBDuW2+wIIytyHo ux76IlAr/wROS2+Z0x0yzfr1ijqoaihjnA9QpfLSpeCyR9/DhbTYnpJFsvWzizgOjsXk L7D188vMioTrxe4oShTqfkDO+jkJPIzkTzTzUF/d7sbeqhX4Wrz/zntR4Xv2rNEXq3/I B2jlAsgyDg/Fc+sTnk2PqB4vOUeSoKXObsBIyGHKNSoaWBKll4P6IgCRXLwvHHViHht2 +Udu1nilLEXsUr10ZSDmCGcrT8Yo55DogbwrgyQNYfGdVUGNQEqKwLdxRUSrAtipNgbl DMhA== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 3-v6si3746290pln.468.2018.02.21.15.33.32; Wed, 21 Feb 2018 15:33:46 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751401AbeBUXcZ (ORCPT + 99 others); Wed, 21 Feb 2018 18:32:25 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:53212 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750805AbeBUXcY (ORCPT ); Wed, 21 Feb 2018 18:32:24 -0500 Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1LNUY0L120930 for ; Wed, 21 Feb 2018 18:32:23 -0500 Received: from e06smtp10.uk.ibm.com (e06smtp10.uk.ibm.com [195.75.94.106]) by mx0a-001b2d01.pphosted.com with ESMTP id 2g9j9ggdkx-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 21 Feb 2018 18:32:23 -0500 Received: from localhost by e06smtp10.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 21 Feb 2018 23:32:21 -0000 Received: from b06cxnps4075.portsmouth.uk.ibm.com (9.149.109.197) by e06smtp10.uk.ibm.com (192.168.101.140) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 21 Feb 2018 23:32:17 -0000 Received: from d06av22.portsmouth.uk.ibm.com (d06av22.portsmouth.uk.ibm.com [9.149.105.58]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w1LNWHus35193064; Wed, 21 Feb 2018 23:32:17 GMT Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 941C54C050; Wed, 21 Feb 2018 23:25:53 +0000 (GMT) Received: from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E4CAC4C044; Wed, 21 Feb 2018 23:25:52 +0000 (GMT) Received: from ozlabs.au.ibm.com (unknown [9.192.253.14]) by d06av22.portsmouth.uk.ibm.com (Postfix) with ESMTP; Wed, 21 Feb 2018 23:25:52 +0000 (GMT) Received: from adsilva.ozlabs.ibm.com (haven.au.ibm.com [9.192.254.114]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.au.ibm.com (Postfix) with ESMTPSA id 03393A0146; Thu, 22 Feb 2018 10:32:15 +1100 (AEDT) Subject: Re: [PATCH] ocxl: Add get_metadata IOCTL to share OCXL information to userspace From: "Alastair D'Silva" To: Balbir Singh Cc: linuxppc-dev , "linux-kernel@vger.kernel.org" , Arnd Bergmann , frederic.barrat@fr.ibm.com, Greg KH , Andrew Donnellan Date: Thu, 22 Feb 2018 10:32:14 +1100 In-Reply-To: References: <20180221045736.7614-1-alastair@au1.ibm.com> Organization: IBM Australia Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.5 (3.26.5-1.fc27) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 18022123-0040-0000-0000-000004153A27 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18022123-0041-0000-0000-000026184D43 Message-Id: <1519255934.2867.3.camel@au1.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-02-21_08:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1802210279 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > > +{ > > + 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? > > + > > + 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. > > + __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. > > + // End version 0 fields > > + > > + __u64 reserved[13]; // Total of 16*u64 > > +}; > > > Balbir Singh. > -- Alastair D'Silva Open Source Developer Linux Technology Centre, IBM Australiamob: 0423 762 819