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 27892C10F04 for ; Fri, 1 Dec 2023 18:26:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 80E6C8D0073; Fri, 1 Dec 2023 13:26:40 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7BE118D0001; Fri, 1 Dec 2023 13:26:40 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 686D78D0073; Fri, 1 Dec 2023 13:26:40 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 57F838D0001 for ; Fri, 1 Dec 2023 13:26:40 -0500 (EST) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 29EAB1A02BC for ; Fri, 1 Dec 2023 18:26:40 +0000 (UTC) X-FDA: 81519080160.29.E6F7BDE Received: from mail-lf1-f49.google.com (mail-lf1-f49.google.com [209.85.167.49]) by imf20.hostedemail.com (Postfix) with ESMTP id 0862F1C0021 for ; Fri, 1 Dec 2023 18:26:36 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=BRojOqYw; spf=pass (imf20.hostedemail.com: domain of fancer.lancer@gmail.com designates 209.85.167.49 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=1701455197; a=rsa-sha256; cv=none; b=DzHmXK7ZwoBPHs3dJru1+XirD8xTebv1LxkfQXymlfikArchC9FPzUv0HB9YyJHJeCDQ40 He1yWVEPBtPOUdTB3Z+j5XhySqbL6cZqRWRzgcp+mHqyT6iIsohMV13V9SwniEWfpL+LBW NmILi1x68sSJrt6sfd0zRSEN8UIqE7M= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=BRojOqYw; spf=pass (imf20.hostedemail.com: domain of fancer.lancer@gmail.com designates 209.85.167.49 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=1701455197; 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=1ep11bMRk1v3QCOoLwm0Yn6OjGUPrQYX7GTrJRrOZYQ=; b=8hS2To9yVkK5QD/3RYW5t45og2XqV2k3DsgMjam6qIIvxsBtqnjzO/+S32NACIVzsCIHBA s8HmC4rtLVpDeD6CEUN7Bae6pr8I8i4c/23GMc3+teA9mMVbVBmgFcYgrJ15knkbRoVYux mnKRETmP6YkEYaKElKM7ugD5l0nVIuU= Received: by mail-lf1-f49.google.com with SMTP id 2adb3069b0e04-50bc22c836bso3534007e87.0 for ; Fri, 01 Dec 2023 10:26:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1701455195; x=1702059995; 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=1ep11bMRk1v3QCOoLwm0Yn6OjGUPrQYX7GTrJRrOZYQ=; b=BRojOqYwMnFetXg0D53Nke+8aniXnuEkbXWWSYcPtyvK9zDWeAzLEXA4oybzNhyE/u ikb4BgE76n4uqXKxywPIGvFx3SUqbvx4AFdGLLNTMCNgK3Hzzlt39xy16m6h6wiRxEPh jpwfgFqggzcpFaTyXPHmAJY6e/arSlraZ7PmlacadSG/6QfJMo77GldbcIo5Xp2OV4vr QMP2wWryBiaXnSeCEmXkvMsUxIvUaJU9ZwJ8Nvy+FsBVNxYCMQIj8ruiCti/oUv9qhB/ jCfKEKc14XOIVmbIfgqD/R/YDHO2Pf7/eXR9VD8rtZSOeKpmxEygaiWzVkoMnSruO8r6 yKDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1701455195; x=1702059995; 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=1ep11bMRk1v3QCOoLwm0Yn6OjGUPrQYX7GTrJRrOZYQ=; b=Em/ep0vDjRcXyCUwoETTQxWTx2+y1Dzl9gkNExw+VJFkZDDX1V73ls5d2TC96BMU08 JX+iuUIWiOIFX36/+ax2gcES7k5n5kVlqCrrY228nJLGqNsSYGyVKVadDJECfI6CIVeF UrpDGrAu+me+XcAasZ3Lr/tqkFeV3dZbQSBbiGphSVIneGOB+/59QdRKU0cbMEpqqhjy K0w0OxoJAHxNcmAzEWSkCtsS1YnbHHXovXuelTjrPpKGzFpTeapqYFaavlMhwANRpCwN RQgelsgbPOAx688TgtEXddP/XGAgktTzIj8RBxAeCPTO5MHdSHF4Wuzo7MxYsAhj0/A7 ZTaw== X-Gm-Message-State: AOJu0YwlaR0nEw40nnoW8EblJbR5dzBFsl3qtXKnPPiGXI70WcPSePCW U5A/hZsuVelNAHyK4hlLmU4= X-Google-Smtp-Source: AGHT+IEd8uxBR2dNyumkQ7246sFbygQLGPDJa56MB2qhN12tmB7F/mg3R6x+3/DOyzDRt6p5svmQMw== X-Received: by 2002:a05:6512:32b3:b0:50b:d764:6ea9 with SMTP id q19-20020a05651232b300b0050bd7646ea9mr964105lfe.89.1701455194684; Fri, 01 Dec 2023 10:26:34 -0800 (PST) Received: from mobilestation ([178.176.56.174]) by smtp.gmail.com with ESMTPSA id l15-20020ac2554f000000b0050bc6317952sm484042lfk.274.2023.12.01.10.26.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Dec 2023 10:26:34 -0800 (PST) Date: Fri, 1 Dec 2023 21:26:31 +0300 From: Serge Semin To: Jiaxun Yang Cc: Thomas Bogendoerfer , 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: <7lla5haj4r4thqqhqvkzvcu2g5oaquubgp6zyemn4up3acoeev@saxalnh6vudt> References: <3iksuovvsln3cw3xpmjd7f7xixfvwaneu4ok56fnookvyolpco@wrxxew3thgnq> <3pgnihbrp5orh4tmj45fipbfoxdwzjh6uefitdpcea2vgkarcm@d56gv3areswl> <2148a67f-bd4f-432e-aa0d-c914a4bd5e0d@app.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 0862F1C0021 X-Stat-Signature: p7nfsn1zg89fn3uompao1rpmu36t1wrh X-Rspam-User: X-HE-Tag: 1701455196-817044 X-HE-Meta: U2FsdGVkX19ZROl/Q0ewvkVTNPlW1e8ZWHx4doBeqTIEojbmTN/pGv6F/Kj1cGEDJE69wzCaMGV9ea4I95e1E2HWMb0/L5WG1L+DsWW62iDHRaq8jtO6EAA9lfsiEjHWt6kYIS1ILO1Ttx6TdLrTYw55Q1wKUZLg2mhYaXsPTtJo0ugrySFyPnXe0HIq7v83vdosgEuJCb4r+Dtv81GtCIN7QjpF638Rb4eCCyaAg6Ek9lvzICuczkCqLgqw1zaPecv536D1WJkLB/tmNzlTkBn1j7aXUKPHnQAplaT8VT/jNjoes6/9oKBr7obd+VspAgDX2cFaINLc3iFUBS2/YASa+vq28FefVS5G6fjlEph2mCRBp2nKdkaUTwU0hZ4N9w6+uUutYcyXJ8/AgJrcihkLareJxAixPxSCzUfzR7/VGy418EQc9CCOEJsNyxsZ/yCh07WOLkN7ViT6JM2M1PO0cHDtXzyXSxkm8WwhNDO2aHsU7kMRAU2bZA1GBmCoYvHCrjtVyquBzcZ7EDpetzli08k/9H3GL53WENut/ddjquluFFuxObVqrg+5VT/9ipSIqFk5Nt/SG4Jn4LV3KYWP8KYSQ/EdCISJQ499dfNq0L0nLp4wsYWosQIEPr8D9Y335gugZDuENTHaLWUuIPw9j6Soa43wbt7I+Z7cR03jfC/XdUvEejGlKbEeNwFW1arYH5lHMAIzUr+LHuUxuyprXyfc8l4T1Pbe7pgF39xRltahvKdeuxxOlHBRLE1ZCaIo9xRuGOUjRLD+79lKG4nbLeXsK/Ced6f9ltNLSciTMJEBeC9WTcaJm9mOX5y3ttuTSt/eyfurtfXJzaBapOqtk+r6eNRqjPqPZgHbQQIsCe+4ALjll+E6Bfh3YEh9dEODhdPo5Gr5BuzQIcto4H8n/tokadmq6mHWEm//Hs1s9YD8DfofaGau7K00ZTyd8GKHKRHbmHCRab7cfjt bk0G/sCr Whn5cK8AHaJ6U0HIDdUUMp1P1CxrgwM4t7aybu4xN6dZvQPDYoOopwPtql4rMzrzJoug3YwnJbMQYCFi9algQYj31ql8faaAJjics9bbdMMJLE4NbKTZj8/2aH7nVJMSsP5ZmXxTZ7skoqwMdfe4UJQZcOSmdCYR8eKLI46hO+zmLWVmrA8BbpoCeOhyZ7nWZTkmdM7RZAvteHgk40e4m5/6RrEcl7RcX8dB7G4nv53FvyO8t3OQXBzhlKKrKjBW4K1IeBEcZ15YrgOcTJnMa48F4sr4qY560vpWFun9VFL54y+BKaGUijKs0XQw1/s6Fkf7uyjUEipAJefOLvvlfQ4n/O/JJN1PN0VguhJqB4kl63DbZBayx/msl9yJrLsZKGb1yqEPlJhwGue5xrhV7AkAepn0MwM/kredRbqt4/js1/cOZ3kqDBIgZ2NaG+jf34U0AcCYG/5Np3EIqBvqJLtv0aT41e3ePJ5o2g+ikbwhGzKFJASRlXOHiPTqB5QR7DGFH4YXG5DeWhXO9Yvv0A1MkQf3xKTfIeKw1xkt81+joU6Pi24FEqkzKd26Uqp+oufTEqm/pcx4KtsroR3qDUT4Y3W0LJwNRxMWWjWaqx5CMYIQRj5ZEd/2SCqUOBdm3Q6wY2WWe0slM1f3A4I1kDY/4lcqDFhoedD4XJCDVfj+MiWGNGkXiQEYofoaPJFqB328GK6egipcJYxo= 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 Fri, Dec 01, 2023 at 03:10:13PM +0000, Jiaxun Yang wrote: > > > 在2023年12月1日十二月 下午2:54，Serge Semin写道： > > On Fri, Dec 01, 2023 at 12:13:22AM +0000, Jiaxun Yang wrote: > >> > >> > >> 在2023年11月30日十一月 下午7:16，Serge Semin写道： > >> > On Tue, Nov 28, 2023 at 03:46:37PM +0000, Jiaxun Yang wrote: > >> [...] > >> > > >> >> I'd say the safest option is to use CKSEG0 or TO_CAC here, > >> > > >> > I would have agreed with you if MIPS didn't have that special > >> > _page_cachable_default variable which is undefined for some platforms > >> > and which might be re-defined during the boot-up process, and if > >> > MIPS64 didn't have ioremap_prot() always mapping to the uncached > >> > region. But IMO updating ioremap_prot() currently seems more risky > >> > than just converting dmi_early_remap() to the uncached version > >> > especially seeing it won't change anything. MIPS64 always have IO > >> > remapped to the uncached region. MIPS32 won't be able to have cached > >> > mapping until VM is available, and paging and slabs are initialized. > >> > So on the early MIPS32 bootup stages ioremap_cache() wouldn't have > >> > worked anyway. > >> > > > >> I really didn't get that, using CKSEG0 on 32bit system and TO_CAC > >> on 64bit system won't hurt. > >> > >> Something like: > >> #ifdef CONFIG_64BIT > >> #define dmi_remap(x, l) (void *)TO_CAC(x) > >> #else > >> #define dmi_remap(x, l) (void *)CKSEG0(x) > >> #endif > >> > >> Can help us avoid all the hassle. Since it always ensures we are > >> using same CCA to access DMI tables. We can always trust Config.K0 > >> left by firmware in this case. > > > > Please note my only concern is about dmi_early_remap(), not > > dmi_remap(). The later one can be safely left backended by the > > ioremap_cache() method because at the stage it's utilized MIPS32 > > version of ioremap_prot() will be able to create any mapping it's > > requested to. The dmi_early_remap() function is called very early with > > no paging or VM or even cache stuff initialized. So currently AFAICS > > it just doesn't work on _all_ _MIPS32_ platform, because > > ioremap_prot() relies on VM and slab being available to have any > > cacheable mapping, which aren't at the moment of the dmi_setup() > > function invocation. Seeing the ioremap_cache() is just a stub on > > MIPS64 which always performs the uncached mapping, it will be > > completely safe to just convert dmi_early_remap() to ioremap() with > > no risk to beak anything. dmi_early_remap() semantics won't be > > actually changed, it will work as before on MIPS64 and will be fixed > > on MIPS32. This (AFAICS) is a completely safe fix of the problem with > > just a few affected platforms around. > > > > The only platform enabled DMI in upstream kernel is Loongson64, which > I'm perfectly sure that the mapping for DMI tables *should* be Cached. Then it looks like it must have been broken in the first place. > It is an accident that ioremap_cache is misused here, so I'm proposing > to replace it with CKSEG0/TO_CAC. Also as per MIPS UHI spec, all the > data passed from bootloader to firmware should lay in KSEG0, I failed to find the MIPS UHI spec. The only link google freely provide is http://prplfoundation.org/wiki/MIPS_documentation but it's broken. Could you please share the doc somehow? Anyway AFAICS from the MIPS arch code it only concerns the dtb pointer passed to the kernel. Does it really mandate all the data being in KSEG0? > please > let me know if your platform is an exception here. No, it's not. U-boot is executed in kseg0 anyway. > > Using ioremap_cache at dmi_early_remap does not sound safe to me as well. > What if DMI code tried to remap something beyond KSEG range at this place? Right. I've found out that for the safety sake the generic version of the ioremap_prot() has been recently updated not to do any mapping if the slab hasn't been initialized: Link: https://lore.kernel.org/lkml/20230515090848.833045-7-bhe@redhat.com/ I'll add a similar fix to the MIPS-version of the ioremap_prop() method to make sure no early cached remapping is attempted. > > The safest option here is just bypassing ioremap framework, which does > not give you any advantage but only burden. > > I'll propose a patch later. Ok. I see. I'll resubmit my series today as is then. Should you need to have the problem fixed differently, please either re-base your patch on top of it, or add your explicit comment that you'll have a better fix so Thomas could be able to consider to postpone this patch mergein until your fix is ready. -Serge(y) > -- > - Jiaxun