From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 28F63C61DF4 for ; Fri, 24 Nov 2023 18:52:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8B4F48D00A2; Fri, 24 Nov 2023 13:52:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 864F28D0096; Fri, 24 Nov 2023 13:52:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 72C2A8D00A2; Fri, 24 Nov 2023 13:52:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 6546B8D0096 for ; Fri, 24 Nov 2023 13:52:49 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 175571A0C8D for ; Fri, 24 Nov 2023 18:52:49 +0000 (UTC) X-FDA: 81493744458.28.FD7088B Received: from mail-lj1-f169.google.com (mail-lj1-f169.google.com [209.85.208.169]) by imf04.hostedemail.com (Postfix) with ESMTP id EB1324001A for ; Fri, 24 Nov 2023 18:52:45 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=RdWap5V9; spf=pass (imf04.hostedemail.com: domain of fancer.lancer@gmail.com designates 209.85.208.169 as permitted sender) smtp.mailfrom=fancer.lancer@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1700851966; a=rsa-sha256; cv=none; b=AyIV07vmaetyJowDJFVsadrlmAN27ydOZXqvfFpMSC5C7fes1Zw+6KUkJKyDEl0sUgxe3g PUEvg4NFAdJpEheZd3cQwHyXq5cF8Z7Pmne2caocN24Vx6r7QoFE3H/eA7XhZBMU+mTKC2 doevfXXwz8JViGV3ZrK5oqtD3IoAtKQ= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=RdWap5V9; spf=pass (imf04.hostedemail.com: domain of fancer.lancer@gmail.com designates 209.85.208.169 as permitted sender) smtp.mailfrom=fancer.lancer@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1700851966; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=qDe7TowA3pJtD1uz4Cwe7404XRpp6gaX2/cNA2FANqc=; b=BvkdYOI0B1e+esTEOt2uovP6dwOPW/dN/IVcl1DZZO9KljyeDavnuTmuUdK7z4Odedolf4 yQl0Rr4RsErrgD3L0VRSt1SVUXZh1C9XxpGT87QY40RALC2KHfd+igq1EzLvcvMJbH0iq5 9VM9sjTxNt3xzGgYQKja64S9JAOEN3c= Received: by mail-lj1-f169.google.com with SMTP id 38308e7fff4ca-2c876f1e44dso27787521fa.0 for ; Fri, 24 Nov 2023 10:52:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700851964; x=1701456764; darn=kvack.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=qDe7TowA3pJtD1uz4Cwe7404XRpp6gaX2/cNA2FANqc=; b=RdWap5V9NywBjf61ysOy54bcqiqMxkcHUQ+9bsYZ8mlydonJO0Xdu3YZEAYvrH0EIv CtiHB+gx7zhRnlpQF0my032X8Az06qxxfaBjrO2LukWje9HOmDsd+KTww0bDrmgZMcyk 1gNfiYx70wN2QUqLuPqgA2qeTXwqXnNF8Qo/2DUjABiRuadt9Vdz8sW3ip0YtEbYFIJN ysIS6w6/sj7RaTjLRugLJG4xt50se5f3gyvh8UatmaIpITshDjSf9KEmPvixRe9xsOsz CE6uR84KIl/ARabhOEcGTdvqTFIY/TKgxoxsIkTgABp95U2yhdwHdf0T184OEXnlenwD RzAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700851964; x=1701456764; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=qDe7TowA3pJtD1uz4Cwe7404XRpp6gaX2/cNA2FANqc=; b=ZZFNdltsZ+C4jnlFYULPoqumubQZTq+lVsLzZjVt5bOEmLt4JT9M0xsZekVXMs0t/A fnldvNi6769vloJDAE2Ap4PZorHbcVmkAt8JY69vJUvH7roF5pUSPwjp/dxkNyxvrDOG JLd/gWms33NtNbt6yARBq57YamDpryag8RR9Na84U+dzGNtQ4SSoo5uLY+VBG63cv480 dHOYo6Sged5JGpsoxa0dVUD/ky+Z4KaRBI7COPtGp8KRP6anilP2AitgC+aduSKSj3TT xKN4shu3ZiORZIrSEUK8I3Qf46igZhJUksWJ28btVZ93Kd9QJt89t1UxjkjVue/rmlaR wa/Q== X-Gm-Message-State: AOJu0YyrM8g6HExqDJ6SX1ijNKxVNVUJHTOlNpoZ4SX1oMG2afIu+5K3 cs03EY7X88zvBsSIjoa19H8= X-Google-Smtp-Source: AGHT+IGNg0R9xRLui1G628JhZhsnFL5EYLQEFEhNy7iHbcv6BTEAWMuZjGGNIgaIcnw8R56mCGC5pA== X-Received: by 2002:a2e:b2d1:0:b0:2bc:d5f1:b9cf with SMTP id 17-20020a2eb2d1000000b002bcd5f1b9cfmr3058491ljz.27.1700851963901; Fri, 24 Nov 2023 10:52:43 -0800 (PST) Received: from mobilestation ([178.176.56.174]) by smtp.gmail.com with ESMTPSA id f6-20020a2eb5a6000000b002b47a15a2eesm585074ljn.45.2023.11.24.10.52.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Nov 2023 10:52:43 -0800 (PST) Date: Fri, 24 Nov 2023 21:52:40 +0300 From: Serge Semin To: Jiaxun Yang , Thomas Bogendoerfer Cc: Arnd Bergmann , Andrew Morton , Mike Rapoport , Matthew Wilcox , Tiezhu Yang , Huacai Chen , Yinglu Yang , Alexey Malahov , Aleksandar Rikalo , Aleksandar Rikalo , Dragan Mladjenovic , Chao-ying Fu , Marc Zyngier , "linux-mips@vger.kernel.org" , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/7] mips: dmi: Fix early remap on MIPS32 Message-ID: <3iksuovvsln3cw3xpmjd7f7xixfvwaneu4ok56fnookvyolpco@wrxxew3thgnq> References: <20231122182419.30633-1-fancer.lancer@gmail.com> <20231122182419.30633-2-fancer.lancer@gmail.com> <8ca730b9-fa8c-46ea-bdc5-158da0f29c3a@app.fastmail.com> <245d3985-9085-4be0-8c74-d95d06334584@app.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <245d3985-9085-4be0-8c74-d95d06334584@app.fastmail.com> X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: EB1324001A X-Stat-Signature: rp57d4htcfmqreo46zqsdnzwdy99w95p X-Rspam-User: X-HE-Tag: 1700851965-80847 X-HE-Meta: U2FsdGVkX1/lvskjCKklcmgJiONhtK3pGpOLeSmQk7ZPVSKe/kqfDyxytWTvVV37vHEGw5aS7QGGOqfLx/re20EksP6RfefrmhbjZgMjqJbEtRlzwkPcLySG6D9BfNCkSsxdEfkZLEr2v8MtEXv+5Zo+a0xzfJTrWdB9iMMLMsnwxfMZmIZqItukQkW7hKb+27/8Rabmz/vi3xaN7wG0YME1eveYfiVjLoJu0aFgauB7aJNfZV7DxXBC9tHkcGXAfaSrhTrV3NYCc9e8tMZKahW3bZl8Vemf8zOQ2isUCnCdsOE0PTfjmjAPNJh/DKWlutpndxtmIpfOGFJN9PZuR9Hmhdiyrg5ILXOPxxC1LTutiM0oyrCLGs22NBmBs2XrEB8Yut6iC8KvnIUiIEazcodILpaoHfHuiZx+Wtv3z37M84/zyyj0DNLanxrBDuVC199Fkvlvy2HBn1BBhy1DTWGaf/gFyjZMx8Sqm36nxf7fRDvYEbYzm+FQgJr1YDn1a0lXv0J7XGtdQkaRHBFSNPk3W3LrcxORWO665H2y87wSc5j9AaGr0y0tTPJILRBCAyIb+ASxEPdGX8is+MsvxZsgCwvRGyj0vN42sT4Sa5jwq7pFXUiEyq/BWfuwcq6z/VkzvuMRyJkcEZ1PjLbDIChD/amDCbEKe9tDeXNvwejhCdhKLsc34D+Z0B0fTl28s+pcoZ+46NIYsG4Ggou1fA6r7DnW9tvTRa/n3D8yl+icGzRm61qGFrp8wN08JFm/oV22xAp21d+vU+/tRWZeiSJ5oOLwgEpTU/PgIwrrJSuvRwZYzS/NnTyzi821ojUbYhx7o+8xMyJZNsmEkm2zJZkeTOuOpOYu0XYv4yEi22Q/hbKUha8WOnHswCWgt8IROC+pZ9MsMKc8ZWjTzQlAiBtZsFWSE+NuRbipcie+TKRdUFuU4eRRpafifRXe7JcIL+TfYe1sLRtD5gaibwJ zvy4jpi3 i84iJRJsCjRzfKwmkk14eX/NdI0NiscW6jYcZCoTExe7T/vYFpvPaTr1dZ4BRl2ee2DAPvsPXHib5GR85noqb3zd6Dijb8MJB4Mc3u/ATFVNf98/Jva5Isl5XxMz+DKd4cXz7FXW5RSOmSshHZZTCubT+Q1dEdK2lEHkCMsQeAhhdLF+zitYlFpGNEWg5lAryRdhPnB01qfP/0TpMJuKYrBe4bAp6pPibWbAFblW+3rrYTbj85RyqaF6GZvEQx02Ch6F38eSXGZt9fvvu25EDaFsvyjSqJIBjranhgZleDbB5xGD6R7udTORjuuWxByqYBmkbwHYPiYU37Nto99z61TZqezjL5tHNgPXSTkEMuapQi9Pn47AITQwDmomHv8OEKMOKFIfUxAyMX3ka1nFkiUbioqD1gTB00uS9Kqgg9vzIPhedPcb3gGNL2DhQsAiaUq+cjFd8RMXUY8VhVfLg6Ew0Au0mtB98qzZqlVg37BeTZp4qIE4GpdXXB/uerI4bv7ycRpFiDI5rhUuvKdkBI1reyIsNjg23RaBLzN20AWyRHEGBLu17jGRPOQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Nov 23, 2023 at 05:33:31PM +0000, Jiaxun Yang wrote: > > > 在2023年11月23日十一月 下午4:07，Thomas Bogendoerfer写道： > > On Thu, Nov 23, 2023 at 03:07:09PM +0000, Jiaxun Yang wrote: > >> > [...] > > > > the problem with all 32bit unmapped segments is their limitations in > > size. But there is always room to try to use unmapped and fall back > > to mapped, if it doesn't work. But I doubt anybody is going to > > implement that. > > Yep, I guess fallback should be implemented for ioremap_cache as well. > > > > >> >> AFAIK for Loongson DMI is located at cached memory so using ioremap_uc > >> >> blindly will cause inconsistency. > >> > > >> > why ? > >> > >> Firmware sometimes does not flush those tables from cache back to memory. > >> For Loongson systems (as well as most MTI systems) cache is enabled by > >> firmware. > > > > kernel flushes all caches on startup, so there shouldn't be a problem. > > Actually dmi_setup() is called before cpu_cache_init(). To preliminary sum the discussion, indeed there can be issues on the platforms which have DMI initialized on the cached region. Here are several solutions and additional difficulties I think may be caused by implementing them: 1. Use unmapped cached region utilization in the MIPS32 ioremap_prot() method. This solution a bit clumsy than it looks on the first glance. ioremap_prot() can be used for various types of the cachability mapping. Currently it's a default-cacheable CA preserved in the _page_cachable_default variable and Write-combined CA saved in boot_cpu_data.writecombine. Based on that we would have needed to use the unmapped cached region utilized for the IO-remaps called with the "_page_cachable_default" mapping flags passed only. The rest of the IO range mappings, including the write-combined ones, would have been handled by VM means. This would have made the ioremap_prot() a bit less maintainable, but still won't be that hard to implement (unless I miss something): --- a/arch/mips/mm/ioremap.c +++ b/arch/mips/mm/ioremap.c /* - * Map uncached objects in the low 512mb of address space using KSEG1, - * otherwise map using page tables. + * Map uncached/default-cached objects in the low 512mb of address + * space using KSEG1/KSEG0, otherwise map using page tables. */ - if (IS_LOW512(phys_addr) && IS_LOW512(last_addr) && - flags == _CACHE_UNCACHED) - return (void __iomem *) CKSEG1ADDR(phys_addr); + if (IS_LOW512(phys_addr) && IS_LOW512(last_addr)) { + if (flags == _CACHE_UNCACHED) + return (void __iomem *) CKSEG1ADDR(phys_addr); + else if (flags == _page_cachable_default) + return (void __iomem *) CKSEG0ADDR(phys_addr); + } Currently I can't figure out what obvious problems it may cause. But It seems suspicious that the cacheable IO-mapping hasn't been implemented by the unmapped cacheable region in the first place. In anyway this solution looks more dangerous than solution 2. because it affects all the MIPS32 platforms at once. 2. Convert dmi_remap_early() to ioremap_uc() (actually just ioremap() as noted by Arnd). As Jiaxun correctly noted this may cause problems on the platforms which don't flush caches before jumping out to the kernel. Thomas said that kernel flushes the caches early on boot, but Jiaxun noted that it's still done after early DMI setup. So the issue with solution 2 is that the setup_arch() method calls dmi_setup() before it flushes the caches by means of the cpu_cache_init() method. I guess it can be fixed just by moving the dmi_setup() method invocation to be after the cpu_cache_init() is called. This solution looks much less invasive than solution 1. So what do you think? What solution do you prefer? Perhaps alternative? -Serge(y) > > Thanks > > > > Thomas. > > > > -- > > Crap can work. Given enough thrust pigs will fly, but it's not necessarily a > > good idea. [ RFC1925, 2.3 ] > > -- > - Jiaxun