Received: by 10.223.185.116 with SMTP id b49csp575043wrg; Wed, 21 Feb 2018 03:28:06 -0800 (PST) X-Google-Smtp-Source: AH8x227FFX609hpZq7i62hXIrS7yoi1ANonN/m1BfYSjCbvFJRxprzwYA84purZYeVGaMGOrxUns X-Received: by 2002:a17:902:9683:: with SMTP id n3-v6mr2803393plp.177.1519212486827; Wed, 21 Feb 2018 03:28:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519212486; cv=none; d=google.com; s=arc-20160816; b=cd8FFai2/VfjqllrPL38nCdMVDwX7lU2Sb17hGMyQvmkn4zmEiBvQh1QAOjIyRdtif wa/nKFjXbTepSMmlZwsaHfXtIDl024mT5eNgHhX2e5kV4lfi6lq1/4gL1CmgpjyqtZKR hcVn8Ko6gQnMZz3jqw1ZPWSr3JRkrAr85ncbtZuM0HMBw+KHlzONouxSiVsKX7XcnOiE cvattiohl/Fp5D5W4wZy4kZ350kI1jikqTgvFJogTZlwz76n/4tJrOnGN5EDfkT/hXT8 kgex7OUvhtxVagMhqgl71sEQQfnvdF6t85TJ2c6lfZrwEfSZR6izt5gN/7o+zwJvp8J2 HN5w== 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 :content-language:in-reply-to:mime-version:user-agent:date:from :references:cc:to:subject:arc-authentication-results; bh=TbcmrtlcCkyo8qx9GSKZmI1rJaxRs8hamEbsJhjvnk0=; b=kjltxDVZ/DLm+FiodetCW/j1I1y6idwg5iuhAAyoR+LAK7ipZzUlPbNjHxm3P3bN9K OBEJdXij0HJf9vbFPHR4mUcBHN4N4P3wilmX8lG1XT4aY4yGtGG1fj3OTqhWIHI19KXP uR5OD+2ylt935aEsyLenCsDG4e0oQrwwhvMe0AA3em6yx/YM7P5ZuTMpGNSTn0vIBM2f FHr2a+H0on3M0HRR+vwTgEfqpeLY4AvK1HC2xXzbJVE1mt3GmQGgSpX/ITYtEX4cJY8O Of4uVTntdACjhEkDmTpya7F8opqRkYmzPdjybynSu6Pz2ZM0BGocvYfR+NnF3sUiuTXt kpjw== 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 bh5-v6si13119171plb.520.2018.02.21.03.27.52; Wed, 21 Feb 2018 03:28:06 -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 S1753880AbeBULZx (ORCPT + 99 others); Wed, 21 Feb 2018 06:25:53 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:54994 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753175AbeBULZv (ORCPT ); Wed, 21 Feb 2018 06:25:51 -0500 Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1LBOeXS088813 for ; Wed, 21 Feb 2018 06:25:51 -0500 Received: from e06smtp12.uk.ibm.com (e06smtp12.uk.ibm.com [195.75.94.108]) by mx0a-001b2d01.pphosted.com with ESMTP id 2g96x4jbk2-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 21 Feb 2018 06:25:51 -0500 Received: from localhost by e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 21 Feb 2018 11:25:48 -0000 Received: from b06cxnps3075.portsmouth.uk.ibm.com (9.149.109.195) by e06smtp12.uk.ibm.com (192.168.101.142) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 21 Feb 2018 11:25:44 -0000 Received: from d06av23.portsmouth.uk.ibm.com (d06av23.portsmouth.uk.ibm.com [9.149.105.59]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id w1LBPiZV63570122; Wed, 21 Feb 2018 11:25:44 GMT Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 79ABDA4040; Wed, 21 Feb 2018 11:18:55 +0000 (GMT) Received: from d06av23.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7ECBEA4051; Wed, 21 Feb 2018 11:18:54 +0000 (GMT) Received: from [9.164.142.189] (unknown [9.164.142.189]) by d06av23.portsmouth.uk.ibm.com (Postfix) with ESMTP; Wed, 21 Feb 2018 11:18:54 +0000 (GMT) Subject: Re: [PATCH] ocxl: Add get_metadata IOCTL to share OCXL information to userspace To: Balbir Singh , "Alastair D'Silva" Cc: Arnd Bergmann , frederic.barrat@fr.ibm.com, Greg KH , "linux-kernel@vger.kernel.org" , linuxppc-dev , Andrew Donnellan , "Alastair D'Silva" References: <20180221045736.7614-1-alastair@au1.ibm.com> From: Frederic Barrat Date: Wed, 21 Feb 2018 12:25:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 x-cbid: 18022111-0008-0000-0000-000004D2AD7E X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 18022111-0009-0000-0000-00001E65B4F5 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-02-21_04:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=2 malwarescore=0 lowpriorityscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1802210141 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Le 21/02/2018 à 07:43, Balbir Singh a écrit : > On Wed, Feb 21, 2018 at 3:57 PM, Alastair D'Silva 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? > >> +{ >> + 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 > >> + >> + 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? > >> + __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? My bad, I forgot to mention it before. There's a somewhat high-level description which needs updating in: Documentation/accelerators/ocxl.rst It doesn't go down to the level of the structure members, but at least all ioctl commands should have a brief description. lpc_size could be added. It's currently useless to the library, but doesn't hurt. The one which was giving me troubles on a previous version of this patch was the lpc numa node ID, since that was experimental code and felt out of place considering what's been upstreamed in skiboot and linux so far. Fred >> + // End version 0 fields >> + >> + __u64 reserved[13]; // Total of 16*u64 >> +}; > > > Balbir Singh. >