[{"id":1765113,"web_url":"http://patchwork.ozlabs.org/comment/1765113/","msgid":"<20170908165624.22dca915@roar.ozlabs.ibm.com>","date":"2017-09-08T06:56:24","subject":"Re: [PATCH v3 2/2] cxl: Enable global TLBIs for cxl contexts","submitter":{"id":69513,"url":"http://patchwork.ozlabs.org/api/people/69513/","name":"Nicholas Piggin","email":"nicholas.piggin@gmail.com"},"content":"On Sun, 3 Sep 2017 20:15:13 +0200\nFrederic Barrat wrote:\n\n> The PSL and nMMU need to see all TLB invalidations for the memory\n> contexts used on the adapter. For the hash memory model, it is done by\n> making all TLBIs global as soon as the cxl driver is in use. For\n> radix, we need something similar, but we can refine and only convert\n> to global the invalidations for contexts actually used by the device.\n> \n> The new mm_context_add_copro() API increments the 'active_cpus' count\n> for the contexts attached to the cxl adapter. As soon as there's more\n> than 1 active cpu, the TLBIs for the context become global. Active cpu\n> count must be decremented when detaching to restore locality if\n> possible and to avoid overflowing the counter.\n> \n> The hash memory model support is somewhat limited, as we can't\n> decrement the active cpus count when mm_context_remove_copro() is\n> called, because we can't flush the TLB for a mm on hash. So TLBIs\n> remain global on hash.\n\nSorry I didn't look at this earlier and just wading in here a bit, but\nwhat do you think of using mmu notifiers for invalidating nMMU and\ncoprocessor caches, rather than put the details into the host MMU\nmanagement? npu-dma.c already looks to have almost everything covered\nwith its notifiers (in that it wouldn't have to rely on tlbie coming\nfrom host MMU code).\n\nThis change is not too bad today, but if we get to more complicated\nMMU/nMMU TLB management like directed invalidation of particular units,\nthen putting more knowledge into the host code will end up being\ncomplex I think.\n\nI also want to also do optimizations on the core code that assumes we\nonly have to take care of other CPUs, e.g.,\n\nhttps://patchwork.ozlabs.org/patch/811068/\n\nOr, another example, directed IPI invalidations from the mm_cpumask\nbitmap.\n\nI realize you want to get something merged! For the merge window and\nbackports this seems fine. I think it would be nice soon afterwards to\nget nMMU knowledge out of the core code... Though I also realize with\nour tlbie instruction that does everything then it may be tricky to\nmake a really optimal notifier.\n\nThanks,\nNick\n\n> \n> Signed-off-by: Frederic Barrat \n> Fixes: f24be42aab37 (\"cxl: Add psl9 specific code\")\n> ---\n> Changelog:\n> v3: don't decrement active cpus count with hash, as we don't know how to flush\n> v2: Replace flush_tlb_mm() by the new flush_all_mm() to flush the TLBs\n> and PWCs (thanks to Ben)","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xpSpG56ZFz9sDB\n\tfor ;\n\tFri, 8 Sep 2017 16:58:30 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xpSpG3s1hzDrbf\n\tfor ;\n\tFri, 8 Sep 2017 16:58:30 +1000 (AEST)","from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com\n\t[IPv6:2607:f8b0:400e:c05::22c])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3xpSmL5Kz8zDrZx\n\tfor ;\n\tFri, 8 Sep 2017 16:56:50 +1000 (AEST)","by mail-pg0-x22c.google.com with SMTP id m9so3540487pgd.3\n\tfor ;\n\tThu, 07 Sep 2017 23:56:50 -0700 (PDT)","from roar.ozlabs.ibm.com (203-219-56-202.tpgi.com.au.\n\t[203.219.56.202]) by smtp.gmail.com with ESMTPSA id\n\tn18sm2089372pgd.69.2017.09.07.23.56.44\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tThu, 07 Sep 2017 23:56:48 -0700 (PDT)"],"Authentication-Results":["ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"e0i49w6y\"; dkim-atps=neutral","lists.ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"e0i49w6y\"; dkim-atps=neutral","ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=gmail.com\n\t(client-ip=2607:f8b0:400e:c05::22c; helo=mail-pg0-x22c.google.com;\n\tenvelope-from=nicholas.piggin@gmail.com; receiver=)","lists.ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"e0i49w6y\"; dkim-atps=neutral"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=date:from:to:cc:subject:message-id:in-reply-to:references\n\t:mime-version:content-transfer-encoding;\n\tbh=q7qFhzXReHYrQ+0b/GbN/AVe7hvZ/+vSlA4ZdEHezNA=;\n\tb=e0i49w6yjBf26R5Y0ZGdab85SCRnq24eUHS6OrLMyklwYG9McwziBYgzh5a50n2SIh\n\tL1itQyI5TCct+Z/YPXyPHhhQCKHx8jerdc4svkz1m6u1W0oHmlwks6kyOle9gxSIjN/o\n\tCHJ3e10rdK7ApqY/w9gr0n5KoNAn+ekRxp8iSDPX8P+uc48Kvue5KGMF0nOP6KU3dX49\n\tskdwquz9w4KSaV8BD9Js1ptXvJJNVaaC+7+hRItz3qlr9nMeh7pr5PvXmMfK+0/6brfj\n\tSAV2xmPtF/WGZPF1dwCbETUkxQZDJ3V2y6qQXztOYtmdZup/wtpgeFpAu8mjwDh4+/L0\n\tyU5w==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to\n\t:references:mime-version:content-transfer-encoding;\n\tbh=q7qFhzXReHYrQ+0b/GbN/AVe7hvZ/+vSlA4ZdEHezNA=;\n\tb=sxuYuteJY36nnH6HRstte213OwZZ1b9I6s/kHow82WO41NlIaVU8zBMF88zTHzvxo+\n\tEPzoDNdzBc4G/7zuPbflz9aSKBl2rkhlfcE/q+xTBut3lXFpYJPcLzgQSp48KV/oBTY4\n\tTdEr3NbI7eoM5ptfAc4mCYRj9P17ne7NeSq3oOD7/JmbFTxQCyDKU3hssbQMZ0ZpjMbT\n\t8B6b+Sa444/xcA0e3Nx0VBhS6qW1qajNyHdzsquZZTU1VAxjNUNeel1JX+CnRa4JgGWM\n\tS0STKD8UQHDW4kSPlLe1ZfnMOb5csBZIS1BCqRDn9mfIPSrTBEGAav1kIIKaLMxjoJPS\n\tiXCQ==","X-Gm-Message-State":"AHPjjUgrK0oT1m5c5uwdqwj9wZJ2g9pYOD08Yy4hyyTZYDgXt5Nn7rtS\n\tj4EOvmQRukm5PA==","X-Google-Smtp-Source":"ADKCNb4nrFfIf5ZKqcBPumduexon9loFZMNqcNNXBMiqbtqVd68ulX5TlZO5e8gjSxFa5oVQ3v5rjw==","X-Received":"by 10.84.129.193 with SMTP id b59mr2349066plb.52.1504853808329; \n\tThu, 07 Sep 2017 23:56:48 -0700 (PDT)","Date":"Fri, 8 Sep 2017 16:56:24 +1000","From":"Nicholas Piggin ","To":"Frederic Barrat ","Subject":"Re: [PATCH v3 2/2] cxl: Enable global TLBIs for cxl contexts","Message-ID":"<20170908165624.22dca915@roar.ozlabs.ibm.com>","In-Reply-To":"<20170903181513.29635-2-fbarrat@linux.vnet.ibm.com>","References":"<20170903181513.29635-1-fbarrat@linux.vnet.ibm.com>\n\t<20170903181513.29635-2-fbarrat@linux.vnet.ibm.com>","X-Mailer":"Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu)","MIME-Version":"1.0","Content-Type":"text/plain; charset=US-ASCII","Content-Transfer-Encoding":"7bit","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.23","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"alistair@popple.id.au, clombard@linux.vnet.ibm.com,\n\tvaibhav@linux.vnet.ibm.com, andrew.donnellan@au1.ibm.com,\n\tlinuxppc-dev@lists.ozlabs.org","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1765129,"web_url":"http://patchwork.ozlabs.org/comment/1765129/","msgid":"","date":"2017-09-08T07:34:39","subject":"Re: [PATCH v3 2/2] cxl: Enable global TLBIs for cxl contexts","submitter":{"id":67555,"url":"http://patchwork.ozlabs.org/api/people/67555/","name":"Frederic Barrat","email":"fbarrat@linux.vnet.ibm.com"},"content":"Le 08/09/2017 à 08:56, Nicholas Piggin a écrit :\n> On Sun, 3 Sep 2017 20:15:13 +0200\n> Frederic Barrat wrote:\n> \n>> The PSL and nMMU need to see all TLB invalidations for the memory\n>> contexts used on the adapter. For the hash memory model, it is done by\n>> making all TLBIs global as soon as the cxl driver is in use. For\n>> radix, we need something similar, but we can refine and only convert\n>> to global the invalidations for contexts actually used by the device.\n>>\n>> The new mm_context_add_copro() API increments the 'active_cpus' count\n>> for the contexts attached to the cxl adapter. As soon as there's more\n>> than 1 active cpu, the TLBIs for the context become global. Active cpu\n>> count must be decremented when detaching to restore locality if\n>> possible and to avoid overflowing the counter.\n>>\n>> The hash memory model support is somewhat limited, as we can't\n>> decrement the active cpus count when mm_context_remove_copro() is\n>> called, because we can't flush the TLB for a mm on hash. So TLBIs\n>> remain global on hash.\n> \n> Sorry I didn't look at this earlier and just wading in here a bit, but\n> what do you think of using mmu notifiers for invalidating nMMU and\n> coprocessor caches, rather than put the details into the host MMU\n> management? npu-dma.c already looks to have almost everything covered\n> with its notifiers (in that it wouldn't have to rely on tlbie coming\n> from host MMU code).\n\nDoes npu-dma.c really do mmio nMMU invalidations? My understanding was \nthat those atsd_launch operations are really targeted at the device \nbehind the NPU, i.e. the nvidia card.\nAt some point, it was not possible to do mmio invalidations on the nMMU. \nAt least on dd1. I'm checking with the nMMU team the status on dd2.\n\nAlistair: is your code really doing a nMMU invalidation? Considering \nyou're trying to also reuse the mm_context_add_copro() from this patch, \nI think I know the answer.\n\nThere are also other components relying on broadcasted invalidations \nfrom hardware: the PSL (for capi FPGA) and the XSL on the Mellanox CX5 \ncard, when in capi mode. They rely on hardware TLBIs, snooped and \nforwarded to them by the CAPP.\nFor the PSL, we do have a mmio interface to do targeted invalidations, \nbut it was removed from the capi architecture (and left as a debug \nfeature for our PSL implementation), because the nMMU would be out of \nsync with the PSL (due to the lack of interface to sync the nMMU, as \nmentioned above).\nFor the XSL on the Mellanox CX5, it's even more complicated. AFAIK, they \ndo have a way to trigger invalidations through software, though the \ninterface is private and Mellanox would have to be involved. They've \nalso stated the performance is much worse through software invalidation.\n\nAnother consideration is performance. Which is best? Short of having \nreal numbers, it's probably hard to know for sure.\n\nSo the road of getting rid of hardware invalidations for external \ncomponents, if at all possible or even desirable, may be long.\n\n Fred\n\n\n\n> This change is not too bad today, but if we get to more complicated\n> MMU/nMMU TLB management like directed invalidation of particular units,\n> then putting more knowledge into the host code will end up being\n> complex I think.\n> \n> I also want to also do optimizations on the core code that assumes we\n> only have to take care of other CPUs, e.g.,\n> \n> https://urldefense.proofpoint.com/v2/url?u=https-3A__patchwork.ozlabs.org_patch_811068_&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=647QnUvvBMO2f-DWP2xkeFceXDYSjpgHeTL3m_I9fiA&m=VaerDVXunKigctgE7NLm8VjaTR90W1m08iMcohAAnPo&s=y25SSoLEB8zDwXOLaTb8FFSpX_qSKiIG3Z5Cf1m7xnw&e=\n> \n> Or, another example, directed IPI invalidations from the mm_cpumask\n> bitmap.\n> \n> I realize you want to get something merged! For the merge window and\n> backports this seems fine. I think it would be nice soon afterwards to\n> get nMMU knowledge out of the core code... Though I also realize with\n> our tlbie instruction that does everything then it may be tricky to\n> make a really optimal notifier.\n> \n> Thanks,\n> Nick\n> \n>>\n>> Signed-off-by: Frederic Barrat \n>> Fixes: f24be42aab37 (\"cxl: Add psl9 specific code\")\n>> ---\n>> Changelog:\n>> v3: don't decrement active cpus count with hash, as we don't know how to flush\n>> v2: Replace flush_tlb_mm() by the new flush_all_mm() to flush the TLBs\n>> and PWCs (thanks to Ben)\n>","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xpTdl54sWz9sBW\n\tfor ;\n\tFri, 8 Sep 2017 17:36:11 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xpTdl3ZFRzDrZF\n\tfor ;\n\tFri, 8 Sep 2017 17:36:11 +1000 (AEST)","from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com\n\t[148.163.156.1])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3xpTc85S6ZzDrWf\n\tfor ;\n\tFri, 8 Sep 2017 17:34:47 +1000 (AEST)","from pps.filterd (m0098396.ppops.net [127.0.0.1])\n\tby mx0a-001b2d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id\n\tv887XjXu113704\n\tfor ; Fri, 8 Sep 2017 03:34:45 -0400","from e06smtp11.uk.ibm.com (e06smtp11.uk.ibm.com [195.75.94.107])\n\tby mx0a-001b2d01.pphosted.com with ESMTP id 2cueahysm0-1\n\t(version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)\n\tfor ; Fri, 08 Sep 2017 03:34:45 -0400","from localhost\n\tby e06smtp11.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use\n\tOnly! Violators will be prosecuted\n\tfor from ;\n\tFri, 8 Sep 2017 08:34:43 +0100","from b06cxnps4076.portsmouth.uk.ibm.com (9.149.109.198)\n\tby e06smtp11.uk.ibm.com (192.168.101.141) with IBM ESMTP SMTP\n\tGateway: Authorized Use Only! Violators will be prosecuted; \n\tFri, 8 Sep 2017 08:34:41 +0100","from d06av22.portsmouth.uk.ibm.com (d06av22.portsmouth.uk.ibm.com\n\t[9.149.105.58])\n\tby b06cxnps4076.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with\n\tESMTP id v887YeTJ14155936; Fri, 8 Sep 2017 07:34:40 GMT","from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id D28AD4C040;\n\tFri, 8 Sep 2017 08:31:20 +0100 (BST)","from d06av22.portsmouth.uk.ibm.com (unknown [127.0.0.1])\n\tby IMSVA (Postfix) with ESMTP id EAE374C046;\n\tFri, 8 Sep 2017 08:31:19 +0100 (BST)","from [9.164.161.76] (unknown [9.164.161.76])\n\tby d06av22.portsmouth.uk.ibm.com (Postfix) with ESMTP;\n\tFri, 8 Sep 2017 08:31:19 +0100 (BST)"],"Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=linux.vnet.ibm.com\n\t(client-ip=148.163.156.1; helo=mx0a-001b2d01.pphosted.com;\n\tenvelope-from=fbarrat@linux.vnet.ibm.com; receiver=)","Subject":"Re: [PATCH v3 2/2] cxl: Enable global TLBIs for cxl contexts","To":"Nicholas Piggin ","References":"<20170903181513.29635-1-fbarrat@linux.vnet.ibm.com>\n\t<20170903181513.29635-2-fbarrat@linux.vnet.ibm.com>\n\t<20170908165624.22dca915@roar.ozlabs.ibm.com>","From":"Frederic Barrat ","Date":"Fri, 8 Sep 2017 09:34:39 +0200","User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101\n\tThunderbird/52.2.1","MIME-Version":"1.0","In-Reply-To":"<20170908165624.22dca915@roar.ozlabs.ibm.com>","Content-Type":"text/plain; charset=utf-8; format=flowed","Content-Language":"en-US","Content-Transfer-Encoding":"8bit","X-TM-AS-GCONF":"00","x-cbid":"17090807-0040-0000-0000-000003F8770E","X-IBM-AV-DETECTION":"SAVI=unused REMOTE=unused XFE=unused","x-cbparentid":"17090807-0041-0000-0000-000020997C22","Message-Id":"","X-Proofpoint-Virus-Version":"vendor=fsecure engine=2.50.10432:, ,\n\tdefinitions=2017-09-08_05:, , signatures=0","X-Proofpoint-Spam-Details":"rule=outbound_notspam policy=outbound score=0\n\tspamscore=0 suspectscore=0\n\tmalwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam\n\tadjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000\n\tdefinitions=main-1709080115","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.23","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"alistair@popple.id.au, clombard@linux.vnet.ibm.com,\n\tvaibhav@linux.vnet.ibm.com, andrew.donnellan@au1.ibm.com,\n\tlinuxppc-dev@lists.ozlabs.org","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1765236,"web_url":"http://patchwork.ozlabs.org/comment/1765236/","msgid":"<20170908205402.09840f45@roar.ozlabs.ibm.com>","date":"2017-09-08T10:54:02","subject":"Re: [PATCH v3 2/2] cxl: Enable global TLBIs for cxl contexts","submitter":{"id":69518,"url":"http://patchwork.ozlabs.org/api/people/69518/","name":"Nicholas Piggin","email":"npiggin@gmail.com"},"content":"On Fri, 8 Sep 2017 09:34:39 +0200\nFrederic Barrat wrote:\n\n> Le 08/09/2017 à 08:56, Nicholas Piggin a écrit :\n> > On Sun, 3 Sep 2017 20:15:13 +0200\n> > Frederic Barrat wrote:\n> > \n> >> The PSL and nMMU need to see all TLB invalidations for the memory\n> >> contexts used on the adapter. For the hash memory model, it is done by\n> >> making all TLBIs global as soon as the cxl driver is in use. For\n> >> radix, we need something similar, but we can refine and only convert\n> >> to global the invalidations for contexts actually used by the device.\n> >>\n> >> The new mm_context_add_copro() API increments the 'active_cpus' count\n> >> for the contexts attached to the cxl adapter. As soon as there's more\n> >> than 1 active cpu, the TLBIs for the context become global. Active cpu\n> >> count must be decremented when detaching to restore locality if\n> >> possible and to avoid overflowing the counter.\n> >>\n> >> The hash memory model support is somewhat limited, as we can't\n> >> decrement the active cpus count when mm_context_remove_copro() is\n> >> called, because we can't flush the TLB for a mm on hash. So TLBIs\n> >> remain global on hash. \n> > \n> > Sorry I didn't look at this earlier and just wading in here a bit, but\n> > what do you think of using mmu notifiers for invalidating nMMU and\n> > coprocessor caches, rather than put the details into the host MMU\n> > management? npu-dma.c already looks to have almost everything covered\n> > with its notifiers (in that it wouldn't have to rely on tlbie coming\n> > from host MMU code). \n> \n> Does npu-dma.c really do mmio nMMU invalidations?\n\nNo, but it does do a flush_tlb_mm there to do a tlbie (probably\nbuggy in some cases and does tlbiel without this patch of yours).\nBut the point is when you control the flushing you don't have to\nmess with making the core flush code give you tlbies.\n\nJust add a flush_nmmu_mm or something that does what you need.\n\nIf you can make a more targeted nMMU invalidate, then that's\neven better.\n\nOne downside at first I thought is that the core code might already\ndo a broadcast tlbie, then the mmu notifier does not easily know\nabout that so it will do a second one which will be suboptimal.\n\nPossibly we could add some flag or state so the nmmu flush can\navoid the second one.\n\nBut now that I look again, the NPU code has this comment:\n\n /*\n * Unfortunately the nest mmu does not support flushing specific\n * addresses so we have to flush the whole mm.\n */\n\nWhich seems to indicate that you can't rely on core code to give\nyou full flushes because for range flushing it is possible that the\ncore code will do it with address flushes. Or am I missing something?\n\nSo it seems you really do need to always issue a full PID tlbie from\na notifier.\n\n> My understanding was \n> that those atsd_launch operations are really targeted at the device \n> behind the NPU, i.e. the nvidia card.\n> At some point, it was not possible to do mmio invalidations on the nMMU. \n> At least on dd1. I'm checking with the nMMU team the status on dd2.\n> \n> Alistair: is your code really doing a nMMU invalidation? Considering \n> you're trying to also reuse the mm_context_add_copro() from this patch, \n> I think I know the answer.\n> \n> There are also other components relying on broadcasted invalidations \n> from hardware: the PSL (for capi FPGA) and the XSL on the Mellanox CX5 \n> card, when in capi mode. They rely on hardware TLBIs, snooped and \n> forwarded to them by the CAPP.\n> For the PSL, we do have a mmio interface to do targeted invalidations, \n> but it was removed from the capi architecture (and left as a debug \n> feature for our PSL implementation), because the nMMU would be out of \n> sync with the PSL (due to the lack of interface to sync the nMMU, as \n> mentioned above).\n> For the XSL on the Mellanox CX5, it's even more complicated. AFAIK, they \n> do have a way to trigger invalidations through software, though the \n> interface is private and Mellanox would have to be involved. They've \n> also stated the performance is much worse through software invalidation.\n\nOkay, point is I think the nMMU and agent drivers will be in a better\nposition to handle all that. I don't see that flushing from your notifier\nmeans that you can't issue a tlbie to do it.\n\n> \n> Another consideration is performance. Which is best? Short of having \n> real numbers, it's probably hard to know for sure.\n\nLet's come to that if we agree on a way to go. I *think* we can make it\nat least no worse than we have today, using tlbie and possibly some small\nchanges to generic code callers.\n\nThanks,\nNick","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xpZ4S01k8z9s7G\n\tfor ;\n\tFri, 8 Sep 2017 20:56:08 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xpZ4R5FbzzDrbh\n\tfor ;\n\tFri, 8 Sep 2017 20:56:07 +1000 (AEST)","from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com\n\t[IPv6:2607:f8b0:400e:c05::22e])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3xpZ2Z3KmYzDrb2\n\tfor ;\n\tFri, 8 Sep 2017 20:54:30 +1000 (AEST)","by mail-pg0-x22e.google.com with SMTP id d8so4301995pgt.4\n\tfor ;\n\tFri, 08 Sep 2017 03:54:30 -0700 (PDT)","from roar.ozlabs.ibm.com (203-219-56-202.tpgi.com.au.\n\t[203.219.56.202]) by smtp.gmail.com with ESMTPSA id\n\tw9sm3033756pfg.129.2017.09.08.03.54.23\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tFri, 08 Sep 2017 03:54:26 -0700 (PDT)"],"Authentication-Results":["ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"H2KQaZ/P\"; dkim-atps=neutral","lists.ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"H2KQaZ/P\"; dkim-atps=neutral","ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=gmail.com\n\t(client-ip=2607:f8b0:400e:c05::22e; helo=mail-pg0-x22e.google.com;\n\tenvelope-from=npiggin@gmail.com; receiver=)","lists.ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"H2KQaZ/P\"; dkim-atps=neutral"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=date:from:to:cc:subject:message-id:in-reply-to:references\n\t:organization:mime-version:content-transfer-encoding;\n\tbh=m5yGTea/CzYJeKeGdhOcWdnKrCfrN2cPm3jOghGLe98=;\n\tb=H2KQaZ/Pm9xi7A1INnGMFIlbDBsr8qbVC3eEBzywbw7xYH7prKsVmvAHAxD8fXicNz\n\t0jmOIzdWmaQYjbWEh1gayb06lgdB+kp6f+KZlO4dZRebWWJEnTYDD/9M+WFwZkI+6qO9\n\tEt5IW4nwqR8artwozxRxObv0w9Eni5d+2sjOKiAZNkTnHj4G1wmTJTNdVZgbrfVBg2T9\n\tG1s6prUDSoQVPGZ4w9E1FqB/iPXwgvWQUc45iSsIJWnf3OHV2MJnnD7Ux0CTn1NlJk8y\n\tQwP3Vjxr9H/UXNkQH2X+8ajpgR50nUuTLlAThqGVX4kS+Rj69DsNn+56w3c1hAgAyFNl\n\tE9mg==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to\n\t:references:organization:mime-version:content-transfer-encoding;\n\tbh=m5yGTea/CzYJeKeGdhOcWdnKrCfrN2cPm3jOghGLe98=;\n\tb=tm6RZffPt786L9GajXgwQ//ol5+XAMauo9By9Pia2dbdOvUDyQB0Sy1LAXarXSRkpV\n\te97aWJolStEGdtKGgl26rsfusY6jluxUNdbe83ig/5Rn3y+SOvLMvN4YrIrceic/7o6b\n\tyKBKsBSbzyifq6Jofp0LW2qfiXh7P2GYLokCxIrSf4tkydFMWbDnNwdQ7eSvQT4LHOHs\n\tjnu8De5WN2yZ/R4AEiBL8p8lDNKsPd7niVpNPWTmvbI6DLBYqK7E1wN1ng+83Tip0UZN\n\tDe/pzbQ9+GXjJd8Ur44iHCDrXoLGAqrhqXETjCpWX9aicvTez8uUVOtCVEevGjJtSt0N\n\t3jog==","X-Gm-Message-State":"AHPjjUi0teh6fShJhlaeVngm4/oDDewcdAbbEW9c8wZxf8YFjwTfbVFv\n\tRpkmqs4XW0kocw==","X-Google-Smtp-Source":"ADKCNb6EGEWfYoaXVlEsUnI9My+Ok728jewL7QrHtT+amFIcJ70e+42gxmWivV+LDqy3ABAu88zirg==","X-Received":"by 10.98.144.89 with SMTP id a86mr2690022pfe.64.1504868068213;\n\tFri, 08 Sep 2017 03:54:28 -0700 (PDT)","Date":"Fri, 8 Sep 2017 20:54:02 +1000","From":"Nicholas Piggin ","To":"Frederic Barrat ","Subject":"Re: [PATCH v3 2/2] cxl: Enable global TLBIs for cxl contexts","Message-ID":"<20170908205402.09840f45@roar.ozlabs.ibm.com>","In-Reply-To":"","References":"<20170903181513.29635-1-fbarrat@linux.vnet.ibm.com>\n\t<20170903181513.29635-2-fbarrat@linux.vnet.ibm.com>\n\t<20170908165624.22dca915@roar.ozlabs.ibm.com>\n\t","Organization":"IBM","X-Mailer":"Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu)","MIME-Version":"1.0","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"8bit","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.23","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"alistair@popple.id.au, clombard@linux.vnet.ibm.com,\n\tvaibhav@linux.vnet.ibm.com, andrew.donnellan@au1.ibm.com,\n\tlinuxppc-dev@lists.ozlabs.org","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1765255,"web_url":"http://patchwork.ozlabs.org/comment/1765255/","msgid":"<20170908211849.59d1f74e@roar.ozlabs.ibm.com>","date":"2017-09-08T11:18:49","subject":"Re: [PATCH v3 2/2] cxl: Enable global TLBIs for cxl contexts","submitter":{"id":69518,"url":"http://patchwork.ozlabs.org/api/people/69518/","name":"Nicholas Piggin","email":"npiggin@gmail.com"},"content":"On Fri, 8 Sep 2017 20:54:02 +1000\nNicholas Piggin wrote:\n\n> On Fri, 8 Sep 2017 09:34:39 +0200\n> Frederic Barrat wrote:\n> \n> > Le 08/09/2017 à 08:56, Nicholas Piggin a écrit : \n> > > On Sun, 3 Sep 2017 20:15:13 +0200\n> > > Frederic Barrat wrote:\n> > > \n> > >> The PSL and nMMU need to see all TLB invalidations for the memory\n> > >> contexts used on the adapter. For the hash memory model, it is done by\n> > >> making all TLBIs global as soon as the cxl driver is in use. For\n> > >> radix, we need something similar, but we can refine and only convert\n> > >> to global the invalidations for contexts actually used by the device.\n> > >>\n> > >> The new mm_context_add_copro() API increments the 'active_cpus' count\n> > >> for the contexts attached to the cxl adapter. As soon as there's more\n> > >> than 1 active cpu, the TLBIs for the context become global. Active cpu\n> > >> count must be decremented when detaching to restore locality if\n> > >> possible and to avoid overflowing the counter.\n> > >>\n> > >> The hash memory model support is somewhat limited, as we can't\n> > >> decrement the active cpus count when mm_context_remove_copro() is\n> > >> called, because we can't flush the TLB for a mm on hash. So TLBIs\n> > >> remain global on hash. \n> > > \n> > > Sorry I didn't look at this earlier and just wading in here a bit, but\n> > > what do you think of using mmu notifiers for invalidating nMMU and\n> > > coprocessor caches, rather than put the details into the host MMU\n> > > management? npu-dma.c already looks to have almost everything covered\n> > > with its notifiers (in that it wouldn't have to rely on tlbie coming\n> > > from host MMU code). \n> > \n> > Does npu-dma.c really do mmio nMMU invalidations? \n> \n> No, but it does do a flush_tlb_mm there to do a tlbie (probably\n> buggy in some cases and does tlbiel without this patch of yours).\n> But the point is when you control the flushing you don't have to\n> mess with making the core flush code give you tlbies.\n> \n> Just add a flush_nmmu_mm or something that does what you need.\n> \n> If you can make a more targeted nMMU invalidate, then that's\n> even better.\n> \n> One downside at first I thought is that the core code might already\n> do a broadcast tlbie, then the mmu notifier does not easily know\n> about that so it will do a second one which will be suboptimal.\n> \n> Possibly we could add some flag or state so the nmmu flush can\n> avoid the second one.\n> \n> But now that I look again, the NPU code has this comment:\n> \n> /*\n> * Unfortunately the nest mmu does not support flushing specific\n> * addresses so we have to flush the whole mm.\n> */\n> \n> Which seems to indicate that you can't rely on core code to give\n> you full flushes because for range flushing it is possible that the\n> core code will do it with address flushes. Or am I missing something?\n> \n> So it seems you really do need to always issue a full PID tlbie from\n> a notifier.\n\nOh I see, actually it's fixed in newer firmware and there's a patch\nout for it.\n\nOkay, so the nMMU can take address tlbie, in that case it's not a\ncorrectness issue (except for old firmware that still has the bug).","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xpZcz1KhWz9sBW\n\tfor ;\n\tFri, 8 Sep 2017 21:20:51 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xpZcz06VYzDrXG\n\tfor ;\n\tFri, 8 Sep 2017 21:20:51 +1000 (AEST)","from mail-pg0-x229.google.com (mail-pg0-x229.google.com\n\t[IPv6:2607:f8b0:400e:c05::229])\n\t(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128\n\tbits)) (No client certificate requested)\n\tby lists.ozlabs.org (Postfix) with ESMTPS id 3xpZb71v8mzDrb9\n\tfor ;\n\tFri, 8 Sep 2017 21:19:14 +1000 (AEST)","by mail-pg0-x229.google.com with SMTP id m9so4403395pgd.3\n\tfor ;\n\tFri, 08 Sep 2017 04:19:14 -0700 (PDT)","from roar.ozlabs.ibm.com (203-219-56-202.tpgi.com.au.\n\t[203.219.56.202]) by smtp.gmail.com with ESMTPSA id\n\tq15sm2669952pgc.64.2017.09.08.04.19.07\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tFri, 08 Sep 2017 04:19:11 -0700 (PDT)"],"Authentication-Results":["ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"TJoNeC0J\"; dkim-atps=neutral","lists.ozlabs.org;\n\tdkim=fail reason=\"signature verification failed\" (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"TJoNeC0J\"; dkim-atps=neutral","ozlabs.org;\n\tspf=pass (mailfrom) smtp.mailfrom=gmail.com\n\t(client-ip=2607:f8b0:400e:c05::229; helo=mail-pg0-x229.google.com;\n\tenvelope-from=npiggin@gmail.com; receiver=)","lists.ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"TJoNeC0J\"; dkim-atps=neutral"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;\n\th=date:from:to:cc:subject:message-id:in-reply-to:references\n\t:organization:mime-version:content-transfer-encoding;\n\tbh=IdIpW6nQ1t36CpQuaYpBGJvyELIQWMAzJ/Plg439kWk=;\n\tb=TJoNeC0JveER49dFYUK2FYN2YblOytQaXp0sb80qcvu1qYd3IPlkuMY7I1APpMmKmM\n\t+svF8EqKqPm1TTuHSnvFHOM8RZTdBcqUAy0QCJeUYkqyDMZcn1xDWx1i7dkn1wycNEoQ\n\tOFTO89ctGGV11IDghWOB29s3HxsMLZ/kGBvIsoSzwIbJXYXFdjwY9YrNfqqzj0WppFua\n\t76G0SYTrs6ehWVZgfqFRxAWLM4yNCdhVXRpPVnd/lo8nVLH5mCv8aFwhxDMqGfz++JM0\n\t88XqPoQRwMA8Eq9fXlwQHuzbFkA8yPCu6ursTvuR70HfV/33tEMGhSlfX2/Dj4Es7t/K\n\tCVJw==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to\n\t:references:organization:mime-version:content-transfer-encoding;\n\tbh=IdIpW6nQ1t36CpQuaYpBGJvyELIQWMAzJ/Plg439kWk=;\n\tb=bih4rxYlMBv73JKuNxLk9gTd9984dejosLXG1FBZfgjrtpg45TGsZkyQDWnArZEYP4\n\tkgJP4EZjh3sXnjL070GSc+iWJk+z6dqF7nJReZcJxoTLg10H2qHrhGkK8Qu9UsBqh83I\n\t/BBZFaNdO9pd4szMtIgf6oTmwWzRt6XLu5qd2CeT9q2qd78y5KN6JoKXzLGho2S6UPAK\n\t7H5ncQXcF4ept44FGR4xAaszlwIDunLnoeRY5hGLDJO1gEIS5H1sa/vOAiPx4UJ5i9wJ\n\tqcev5YHZWnqO7AGRxQFCavuQ30PGpyamjahH5LfVIsZzr7biiH10Z65CU0PgDyioJ7sO\n\tCqZA==","X-Gm-Message-State":"AHPjjUiiQV4U5pOdSDNQrnK5DkBTDE3cNG5XduIUSpVm4jVOCWs4Ng/8\n\tJATGIwnSzk+SDw==","X-Google-Smtp-Source":"ADKCNb7ud66nNCDSdGxvIitAxEHjTmtk06wGZBgex0Evb17ZDMXuhmT3wJZ5cK9Qh1sKlnJQ5AhHww==","X-Received":"by 10.84.129.193 with SMTP id b59mr3179828plb.200.1504869552398; \n\tFri, 08 Sep 2017 04:19:12 -0700 (PDT)","Date":"Fri, 8 Sep 2017 21:18:49 +1000","From":"Nicholas Piggin ","To":"Frederic Barrat ","Subject":"Re: [PATCH v3 2/2] cxl: Enable global TLBIs for cxl contexts","Message-ID":"<20170908211849.59d1f74e@roar.ozlabs.ibm.com>","In-Reply-To":"<20170908205402.09840f45@roar.ozlabs.ibm.com>","References":"<20170903181513.29635-1-fbarrat@linux.vnet.ibm.com>\n\t<20170903181513.29635-2-fbarrat@linux.vnet.ibm.com>\n\t<20170908165624.22dca915@roar.ozlabs.ibm.com>\n\t\n\t<20170908205402.09840f45@roar.ozlabs.ibm.com>","Organization":"IBM","X-Mailer":"Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu)","MIME-Version":"1.0","Content-Type":"text/plain; charset=UTF-8","Content-Transfer-Encoding":"8bit","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.23","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"alistair@popple.id.au, clombard@linux.vnet.ibm.com,\n\tvaibhav@linux.vnet.ibm.com, andrew.donnellan@au1.ibm.com,\n\tlinuxppc-dev@lists.ozlabs.org","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1767534,"web_url":"http://patchwork.ozlabs.org/comment/1767534/","msgid":"<1722769.VMcgIllh4T@new-mexico>","date":"2017-09-13T03:53:22","subject":"Re: [PATCH v3 2/2] cxl: Enable global TLBIs for cxl contexts","submitter":{"id":24781,"url":"http://patchwork.ozlabs.org/api/people/24781/","name":"Alistair Popple","email":"alistair@popple.id.au"},"content":"On Fri, 8 Sep 2017 04:56:24 PM Nicholas Piggin wrote:\n> On Sun, 3 Sep 2017 20:15:13 +0200\n> Frederic Barrat wrote:\n> \n> > The PSL and nMMU need to see all TLB invalidations for the memory\n> > contexts used on the adapter. For the hash memory model, it is done by\n> > making all TLBIs global as soon as the cxl driver is in use. For\n> > radix, we need something similar, but we can refine and only convert\n> > to global the invalidations for contexts actually used by the device.\n> > \n> > The new mm_context_add_copro() API increments the 'active_cpus' count\n> > for the contexts attached to the cxl adapter. As soon as there's more\n> > than 1 active cpu, the TLBIs for the context become global. Active cpu\n> > count must be decremented when detaching to restore locality if\n> > possible and to avoid overflowing the counter.\n> > \n> > The hash memory model support is somewhat limited, as we can't\n> > decrement the active cpus count when mm_context_remove_copro() is\n> > called, because we can't flush the TLB for a mm on hash. So TLBIs\n> > remain global on hash.\n> \n> Sorry I didn't look at this earlier and just wading in here a bit, but\n> what do you think of using mmu notifiers for invalidating nMMU and\n> coprocessor caches, rather than put the details into the host MMU\n> management? npu-dma.c already looks to have almost everything covered\n> with its notifiers (in that it wouldn't have to rely on tlbie coming\n> from host MMU code).\n\nSorry, just finding time to catch up on this. From subsequent emails it looks\nlike you may have figured this out. The TLB flush in npu-dma.c is a workaround\nfor a HW issue rather than there to explicitly manage the NMMU caches. The\nintent for NPU was always to have the NMMU snoop normal core tlbies rather than\ndo it via notifiers. A subsequent patch series\n(https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=1681) removes\nthis flush now that the HW issue has been worked around via a FW fix.\n\nI agree this is something we could look into optimising in the medium term, but\nfor the moment it would be good if we could get this series merged.\n\n- Alistair","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xsSTh2wYvz9sPt\n\tfor ;\n\tWed, 13 Sep 2017 13:54:32 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xsSTh1wkLzDrVq\n\tfor ;\n\tWed, 13 Sep 2017 13:54:32 +1000 (AEST)","from ipmailnode02.adl6.internode.on.net\n\t(ipmailnode02.adl6.internode.on.net [150.101.137.148])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xsSSQ2LF1zDrJ3\n\tfor ;\n\tWed, 13 Sep 2017 13:53:25 +1000 (AEST)","from static-82-10.transact.net.au (HELO new-mexico.localnet)\n\t([122.99.82.10]) by ipmail02.adl6.internode.on.net with ESMTP;\n\t13 Sep 2017 13:23:24 +0930"],"Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=popple.id.au\n\t(client-ip=150.101.137.148; helo=ipmailnode02.adl6.internode.on.net; \n\tenvelope-from=alistair@popple.id.au; receiver=)","X-IronPort-Anti-Spam-Filtered":"true","X-IronPort-Anti-Spam-Result":"A2DPBAAcqrhZ/wpSY3pcHQEFAQsBhD5uJ4VXiTaRJZg6LYUbAoUHFAECAQEBAQEBAWsohRkBBTo2CRALGAkVEA8BRxmKMBGuTIs5AQEBAQEFAQEBAR8FgyuFNYMogyeBKXOFKAWgdIdbjWmSAJZoNiGBDRwWGAkIGBlKhRcdgXkuNgGHRIJBAQEB","From":"Alistair Popple ","To":"linuxppc-dev@lists.ozlabs.org","Subject":"Re: [PATCH v3 2/2] cxl: Enable global TLBIs for cxl contexts","Date":"Wed, 13 Sep 2017 13:53:22 +1000","Message-ID":"<1722769.VMcgIllh4T@new-mexico>","User-Agent":"KMail/4.14.1 (Linux/4.9.0-0.bpo.3-amd64; KDE/4.14.2; x86_64; ; )","In-Reply-To":"<20170908165624.22dca915@roar.ozlabs.ibm.com>","References":"<20170903181513.29635-1-fbarrat@linux.vnet.ibm.com>\n\t<20170903181513.29635-2-fbarrat@linux.vnet.ibm.com>\n\t<20170908165624.22dca915@roar.ozlabs.ibm.com>","MIME-Version":"1.0","Content-Transfer-Encoding":"7Bit","Content-Type":"text/plain; charset=\"us-ascii\"","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.24","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"andrew.donnellan@au1.ibm.com, vaibhav@linux.vnet.ibm.com,\n\tclombard@linux.vnet.ibm.com,\n\tFrederic Barrat , \n\tNicholas Piggin ","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}},{"id":1767538,"web_url":"http://patchwork.ozlabs.org/comment/1767538/","msgid":"<1977478.pEtL0MQTns@new-mexico>","date":"2017-09-13T03:58:11","subject":"Re: [PATCH v3 2/2] cxl: Enable global TLBIs for cxl contexts","submitter":{"id":24781,"url":"http://patchwork.ozlabs.org/api/people/24781/","name":"Alistair Popple","email":"alistair@popple.id.au"},"content":"I have tested the non-cxl specific parts\n(mm_context_add_copro/mm_context_remove_copro) with this series -\nhttps://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=1681 - and it\nworks well for npu.\n\nTested-by: Alistair Popple \n\nOn Sun, 3 Sep 2017 08:15:13 PM Frederic Barrat wrote:\n> The PSL and nMMU need to see all TLB invalidations for the memory\n> contexts used on the adapter. For the hash memory model, it is done by\n> making all TLBIs global as soon as the cxl driver is in use. For\n> radix, we need something similar, but we can refine and only convert\n> to global the invalidations for contexts actually used by the device.\n> \n> The new mm_context_add_copro() API increments the 'active_cpus' count\n> for the contexts attached to the cxl adapter. As soon as there's more\n> than 1 active cpu, the TLBIs for the context become global. Active cpu\n> count must be decremented when detaching to restore locality if\n> possible and to avoid overflowing the counter.\n> \n> The hash memory model support is somewhat limited, as we can't\n> decrement the active cpus count when mm_context_remove_copro() is\n> called, because we can't flush the TLB for a mm on hash. So TLBIs\n> remain global on hash.\n> \n> Signed-off-by: Frederic Barrat \n> Fixes: f24be42aab37 (\"cxl: Add psl9 specific code\")\n> ---\n> Changelog:\n> v3: don't decrement active cpus count with hash, as we don't know how to flush\n> v2: Replace flush_tlb_mm() by the new flush_all_mm() to flush the TLBs\n> and PWCs (thanks to Ben)\n> \n> arch/powerpc/include/asm/mmu_context.h | 46 ++++++++++++++++++++++++++++++++++\n> arch/powerpc/mm/mmu_context.c | 9 -------\n> drivers/misc/cxl/api.c | 22 +++++++++++++---\n> drivers/misc/cxl/context.c | 3 +++\n> drivers/misc/cxl/file.c | 19 ++++++++++++--\n> 5 files changed, 85 insertions(+), 14 deletions(-)\n> \n> diff --git a/arch/powerpc/include/asm/mmu_context.h b/arch/powerpc/include/asm/mmu_context.h\n> index 309592589e30..a0d7145d6cd2 100644\n> --- a/arch/powerpc/include/asm/mmu_context.h\n> +++ b/arch/powerpc/include/asm/mmu_context.h\n> @@ -77,6 +77,52 @@ extern void switch_cop(struct mm_struct *next);\n> extern int use_cop(unsigned long acop, struct mm_struct *mm);\n> extern void drop_cop(unsigned long acop, struct mm_struct *mm);\n> \n> +#ifdef CONFIG_PPC_BOOK3S_64\n> +static inline void inc_mm_active_cpus(struct mm_struct *mm)\n> +{\n> +\tatomic_inc(&mm->context.active_cpus);\n> +}\n> +\n> +static inline void dec_mm_active_cpus(struct mm_struct *mm)\n> +{\n> +\tatomic_dec(&mm->context.active_cpus);\n> +}\n> +\n> +static inline void mm_context_add_copro(struct mm_struct *mm)\n> +{\n> +\t/*\n> +\t * On hash, should only be called once over the lifetime of\n> +\t * the context, as we can't decrement the active cpus count\n> +\t * and flush properly for the time being.\n> +\t */\n> +\tinc_mm_active_cpus(mm);\n> +}\n> +\n> +static inline void mm_context_remove_copro(struct mm_struct *mm)\n> +{\n> +\t/*\n> +\t * Need to broadcast a global flush of the full mm before\n> +\t * decrementing active_cpus count, as the next TLBI may be\n> +\t * local and the nMMU and/or PSL need to be cleaned up.\n> +\t * Should be rare enough so that it's acceptable.\n> +\t *\n> +\t * Skip on hash, as we don't know how to do the proper flush\n> +\t * for the time being. Invalidations will remain global if\n> +\t * used on hash.\n> +\t */\n> +\tif (radix_enabled()) {\n> +\t\tflush_all_mm(mm);\n> +\t\tdec_mm_active_cpus(mm);\n> +\t}\n> +}\n> +#else\n> +static inline void inc_mm_active_cpus(struct mm_struct *mm) { }\n> +static inline void dec_mm_active_cpus(struct mm_struct *mm) { }\n> +static inline void mm_context_add_copro(struct mm_struct *mm) { }\n> +static inline void mm_context_remove_copro(struct mm_struct *mm) { }\n> +#endif\n> +\n> +\n> extern void switch_mm_irqs_off(struct mm_struct *prev, struct mm_struct *next,\n> \t\t\t struct task_struct *tsk);\n> \n> diff --git a/arch/powerpc/mm/mmu_context.c b/arch/powerpc/mm/mmu_context.c\n> index 0f613bc63c50..d60a62bf4fc7 100644\n> --- a/arch/powerpc/mm/mmu_context.c\n> +++ b/arch/powerpc/mm/mmu_context.c\n> @@ -34,15 +34,6 @@ static inline void switch_mm_pgdir(struct task_struct *tsk,\n> \t\t\t\t struct mm_struct *mm) { }\n> #endif\n> \n> -#ifdef CONFIG_PPC_BOOK3S_64\n> -static inline void inc_mm_active_cpus(struct mm_struct *mm)\n> -{\n> -\tatomic_inc(&mm->context.active_cpus);\n> -}\n> -#else\n> -static inline void inc_mm_active_cpus(struct mm_struct *mm) { }\n> -#endif\n> -\n> void switch_mm_irqs_off(struct mm_struct *prev, struct mm_struct *next,\n> \t\t\tstruct task_struct *tsk)\n> {\n> diff --git a/drivers/misc/cxl/api.c b/drivers/misc/cxl/api.c\n> index a0c44d16bf30..1137a2cc1d3e 100644\n> --- a/drivers/misc/cxl/api.c\n> +++ b/drivers/misc/cxl/api.c\n> @@ -15,6 +15,7 @@\n> #include \n> #include \n> #include \n> +#include \n> \n> #include \"cxl.h\"\n> \n> @@ -331,9 +332,12 @@ int cxl_start_context(struct cxl_context *ctx, u64 wed,\n> \t\t/* ensure this mm_struct can't be freed */\n> \t\tcxl_context_mm_count_get(ctx);\n> \n> -\t\t/* decrement the use count */\n> -\t\tif (ctx->mm)\n> +\t\tif (ctx->mm) {\n> +\t\t\t/* decrement the use count from above */\n> \t\t\tmmput(ctx->mm);\n> +\t\t\t/* make TLBIs for this context global */\n> +\t\t\tmm_context_add_copro(ctx->mm);\n> +\t\t}\n> \t}\n> \n> \t/*\n> @@ -342,13 +346,25 @@ int cxl_start_context(struct cxl_context *ctx, u64 wed,\n> \t */\n> \tcxl_ctx_get();\n> \n> +\t/*\n> +\t * Barrier is needed to make sure all TLBIs are global before\n> +\t * we attach and the context starts being used by the adapter.\n> +\t *\n> +\t * Needed after mm_context_add_copro() for radix and\n> +\t * cxl_ctx_get() for hash/p8\n> +\t */\n> +\tsmp_mb();\n> +\n> \tif ((rc = cxl_ops->attach_process(ctx, kernel, wed, 0))) {\n> \t\tput_pid(ctx->pid);\n> \t\tctx->pid = NULL;\n> \t\tcxl_adapter_context_put(ctx->afu->adapter);\n> \t\tcxl_ctx_put();\n> -\t\tif (task)\n> +\t\tif (task) {\n> \t\t\tcxl_context_mm_count_put(ctx);\n> +\t\t\tif (ctx->mm)\n> +\t\t\t\tmm_context_remove_copro(ctx->mm);\n> +\t\t}\n> \t\tgoto out;\n> \t}\n> \n> diff --git a/drivers/misc/cxl/context.c b/drivers/misc/cxl/context.c\n> index 8c32040b9c09..12a41b2753f0 100644\n> --- a/drivers/misc/cxl/context.c\n> +++ b/drivers/misc/cxl/context.c\n> @@ -18,6 +18,7 @@\n> #include \n> #include \n> #include \n> +#include \n> #include \n> #include \n> #include \n> @@ -267,6 +268,8 @@ int __detach_context(struct cxl_context *ctx)\n> \n> \t/* Decrease the mm count on the context */\n> \tcxl_context_mm_count_put(ctx);\n> +\tif (ctx->mm)\n> +\t\tmm_context_remove_copro(ctx->mm);\n> \tctx->mm = NULL;\n> \n> \treturn 0;\n> diff --git a/drivers/misc/cxl/file.c b/drivers/misc/cxl/file.c\n> index 4bfad9f6dc9f..84b801b5d0e5 100644\n> --- a/drivers/misc/cxl/file.c\n> +++ b/drivers/misc/cxl/file.c\n> @@ -19,6 +19,7 @@\n> #include \n> #include \n> #include \n> +#include \n> #include \n> #include \n> #include \n> @@ -220,9 +221,12 @@ static long afu_ioctl_start_work(struct cxl_context *ctx,\n> \t/* ensure this mm_struct can't be freed */\n> \tcxl_context_mm_count_get(ctx);\n> \n> -\t/* decrement the use count */\n> -\tif (ctx->mm)\n> +\tif (ctx->mm) {\n> +\t\t/* decrement the use count from above */\n> \t\tmmput(ctx->mm);\n> +\t\t/* make TLBIs for this context global */\n> +\t\tmm_context_add_copro(ctx->mm);\n> +\t}\n> \n> \t/*\n> \t * Increment driver use count. Enables global TLBIs for hash\n> @@ -230,6 +234,15 @@ static long afu_ioctl_start_work(struct cxl_context *ctx,\n> \t */\n> \tcxl_ctx_get();\n> \n> +\t/*\n> +\t * Barrier is needed to make sure all TLBIs are global before\n> +\t * we attach and the context starts being used by the adapter.\n> +\t *\n> +\t * Needed after mm_context_add_copro() for radix and\n> +\t * cxl_ctx_get() for hash/p8\n> +\t */\n> +\tsmp_mb();\n> +\n> \ttrace_cxl_attach(ctx, work.work_element_descriptor, work.num_interrupts, amr);\n> \n> \tif ((rc = cxl_ops->attach_process(ctx, false, work.work_element_descriptor,\n> @@ -240,6 +253,8 @@ static long afu_ioctl_start_work(struct cxl_context *ctx,\n> \t\tctx->pid = NULL;\n> \t\tcxl_ctx_put();\n> \t\tcxl_context_mm_count_put(ctx);\n> +\t\tif (ctx->mm)\n> +\t\t\tmm_context_remove_copro(ctx->mm);\n> \t\tgoto out;\n> \t}\n> \n>","headers":{"Return-Path":"","X-Original-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Delivered-To":["patchwork-incoming@ozlabs.org","linuxppc-dev@lists.ozlabs.org"],"Received":["from lists.ozlabs.org (lists.ozlabs.org [103.22.144.68])\n\t(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))\n\t(No client certificate requested)\n\tby ozlabs.org (Postfix) with ESMTPS id 3xsSb63hQTz9sNw\n\tfor ;\n\tWed, 13 Sep 2017 13:59:14 +1000 (AEST)","from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xsSb62hj4zDrWG\n\tfor ;\n\tWed, 13 Sep 2017 13:59:14 +1000 (AEST)","from ipmailnode02.adl6.internode.on.net\n\t(ipmailnode02.adl6.internode.on.net [150.101.137.148])\n\tby lists.ozlabs.org (Postfix) with ESMTP id 3xsSYw6wwBzDrJ5\n\tfor ;\n\tWed, 13 Sep 2017 13:58:12 +1000 (AEST)","from static-82-10.transact.net.au (HELO new-mexico.localnet)\n\t([122.99.82.10]) by ipmail02.adl6.internode.on.net with ESMTP;\n\t13 Sep 2017 13:28:11 +0930"],"Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=popple.id.au\n\t(client-ip=150.101.137.148; helo=ipmailnode02.adl6.internode.on.net; \n\tenvelope-from=alistair@popple.id.au; receiver=)","X-IronPort-Anti-Spam-Filtered":"true","X-IronPort-Anti-Spam-Result":"A2DPBABKq7hZ/wpSY3pcHQEFAQsBhD5uJ4VXiTaRJZg6LYUbAoUHFAECAQEBAQEBAWsohRkBBScTPxALGAkVEA8BRxmKMBGuGTqLOQEBAQEGAQEBAR8FgyuFNYMogyeBKYYbBaB0h1uNaZIAlmg2IYENHBYYCQgYGUqFFwEcgXkuNgGHRIJBAQEB","From":"Alistair Popple ","To":"linuxppc-dev@lists.ozlabs.org","Subject":"Re: [PATCH v3 2/2] cxl: Enable global TLBIs for cxl contexts","Date":"Wed, 13 Sep 2017 13:58:11 +1000","Message-ID":"<1977478.pEtL0MQTns@new-mexico>","User-Agent":"KMail/4.14.1 (Linux/4.9.0-0.bpo.3-amd64; KDE/4.14.2; x86_64; ; )","In-Reply-To":"<20170903181513.29635-2-fbarrat@linux.vnet.ibm.com>","References":"<20170903181513.29635-1-fbarrat@linux.vnet.ibm.com>\n\t<20170903181513.29635-2-fbarrat@linux.vnet.ibm.com>","MIME-Version":"1.0","Content-Transfer-Encoding":"7Bit","Content-Type":"text/plain; charset=\"us-ascii\"","X-BeenThere":"linuxppc-dev@lists.ozlabs.org","X-Mailman-Version":"2.1.24","Precedence":"list","List-Id":"Linux on PowerPC Developers Mail List\n\t","List-Unsubscribe":",\n\t","List-Archive":"","List-Post":"","List-Help":"","List-Subscribe":",\n\t","Cc":"clombard@linux.vnet.ibm.com, vaibhav@linux.vnet.ibm.com,\n\tFrederic Barrat ,\n\tandrew.donnellan@au1.ibm.com","Errors-To":"linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org","Sender":"\"Linuxppc-dev\"\n\t"}}]