Received: by 2002:a25:8b91:0:0:0:0:0 with SMTP id j17csp523359ybl; Wed, 11 Dec 2019 03:27:06 -0800 (PST) X-Google-Smtp-Source: APXvYqwQ9IZbG5M+KsnYKYGM+fLYT94VNl8JdEsfTHtnoOJrfQtJucucXtatP61WbOgV5/pqScgw X-Received: by 2002:a05:6808:14:: with SMTP id u20mr2274825oic.118.1576063626855; Wed, 11 Dec 2019 03:27:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1576063626; cv=none; d=google.com; s=arc-20160816; b=Q3U+WnqQGEUKQWMZJHLI3tzbWBK4ovA/QjdSmB8DjmjX9vFJe04I0gRsV2CSEsXite hq1SBgY+Mw2mRyZic3U+C7tKSJVt0y8kxvaXo2Y3SInYvTVC+oLusNFC8LvJa//16R2P qRYvCGRfHqO7Ha5DfhdMbyl41GojFqLYdMqrwinRzfDvZfarufBxe1SgRikmWW3v2gPb +wR81beyvdtiSQhixvVG9xSKD/GUlp5Nt7xe3XCDAGZPciQIXig6r/KrX3iL6Z8YFFM5 74cbm264iNb9UjLHKvgHFaJycvFIBJbO2HPx7GSx4atA2RfFnD1pcd3SLvnAqQo2qa5+ hOIA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=AXTqM53euYhJDX4R+qhI2h5dF93uoBPLPxhADwzStNg=; b=CrMPYLCXhWshzWgERteMZdTE7ic/BaiZb4xzwPcthmrzGzawWyI2uLGX21Q8l4Y5PY ZatQFpksA3lN1E9gP0IeKcsnDol9PIFj6JstnWhgAlcerFtPSY6+6+j7MCgl4uIoutYv 3M3TzFjqky2DRYfqzglH6MWNa5WNegZbVLJmkzj0xgXHv/BkpFMNoSk/v+eiavCSoo+i hqJz3Of/NMigGpwkIap6mv665qcqOjKCGjrOgrIRD9AGfhQYe2QIBCZ811L5vyDzdbFs M9Cc6uPNJJJlZ29xyivMzQbffHi0dXBzX0Jh1djLKNTlJHFtrMnXuEFGH1J1bQ2egk72 Fr2A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=prencWNA; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t23si994862oij.23.2019.12.11.03.26.54; Wed, 11 Dec 2019 03:27: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; dkim=pass header.i=@linaro.org header.s=google header.b=prencWNA; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728696AbfLKL0W (ORCPT + 99 others); Wed, 11 Dec 2019 06:26:22 -0500 Received: from mail-wr1-f68.google.com ([209.85.221.68]:39285 "EHLO mail-wr1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727469AbfLKL0V (ORCPT ); Wed, 11 Dec 2019 06:26:21 -0500 Received: by mail-wr1-f68.google.com with SMTP id y11so23597685wrt.6 for ; Wed, 11 Dec 2019 03:26:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AXTqM53euYhJDX4R+qhI2h5dF93uoBPLPxhADwzStNg=; b=prencWNALFk8vubbf2cYL0WZTuAMMC+KXeVtDHyFqN9T5OlfXSoh6sLZo8yDoaXqNZ mV9vHouVCvcLe+/ZkY4pcf5eKh17/KYeMxha/GktmjTlnJ8GYa8ef23wsdznsYmgvJBG umXDJOLaQd+e9AZhStaVCmeh+7eeuOY/psJRlTrasb8zL9wJjzg4uErg6duuBDQ62m9b XGZ2dGPrer6mwuPu2iaFySv1J4Qfx6xb8XN3zrYPufnihcLQr5a0jz2Ooe9Q6bXjWlsu Q+1vX4TE1l1PkAoy/XvuNiGjJT2wWPE20Sqg/556R+s1t051Mx40urpFHg7C47RkCVnC B4Wg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AXTqM53euYhJDX4R+qhI2h5dF93uoBPLPxhADwzStNg=; b=E5n4C7/1QQwq246OnLY0QgNQu/wj5RGzmIrNjTMQfIYrEimUSQYCjOqkM7cdVegOLl c0vrnEDky6QhgiZ16uP8DkDnbFqwN0qjZFmLjMGvNK1BZwLXerxLmVOHeBz6ja1Nijbd hjfPnuir6xvNoNO8Et8cQCkH4VPQCSlgPXpak+QuyeYVgaTJePXSr3Myo/LbEZVupTxN 9ZAx8rvfplTreJBBc3exbwlowdwKfcZSlBqMuq86LETODxGzYw3TITleSnnvbcUELvDj sN+cEm0mt+E0Jktmv5M3vlOmYBQqiR6BvwwZfy9TDEBuTQMzg+E+Vm0UlixjnjXVyOJv gQ/Q== X-Gm-Message-State: APjAAAXVWCk6VAdPW/K179RKbKcSKFg50Fasnt4tcx+SnsWBEgqNbXu/ AJi00/G/fjHRm4Q91iLgJvFK7glmM4ApOhCT0TC3BA== X-Received: by 2002:a5d:46c1:: with SMTP id g1mr3181360wrs.200.1576063579504; Wed, 11 Dec 2019 03:26:19 -0800 (PST) MIME-Version: 1.0 References: <20191206165542.31469-1-ardb@kernel.org> <20191206165542.31469-7-ardb@kernel.org> <20191209191242.GA3075464@rani.riverdale.lan> <20191210200546.GA55356@rani.riverdale.lan> In-Reply-To: <20191210200546.GA55356@rani.riverdale.lan> From: Ard Biesheuvel Date: Wed, 11 Dec 2019 11:26:17 +0000 Message-ID: Subject: Re: [PATCH 6/6] efi/earlycon: Remap entire framebuffer after page initialization To: Arvind Sankar Cc: Ard Biesheuvel , linux-efi , Ingo Molnar , Thomas Gleixner , Linux Kernel Mailing List , Andy Shevchenko , Bhupesh Sharma , Masayoshi Mizuma Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 10 Dec 2019 at 21:05, Arvind Sankar wrote: > > On Mon, Dec 09, 2019 at 07:24:13PM +0000, Ard Biesheuvel wrote: > > On Mon, 9 Dec 2019 at 20:12, Arvind Sankar wrote: > > > > > > On Fri, Dec 06, 2019 at 04:55:42PM +0000, Ard Biesheuvel wrote: > > > > From: Andy Shevchenko > > > > > > > > When commit 69c1f396f25b > > > > > > > > "efi/x86: Convert x86 EFI earlyprintk into generic earlycon implementation" > > > > > > > > moved the x86 specific EFI earlyprintk implementation to a shared location, > > > > it also tweaked the behaviour. In particular, it dropped a trick with full > > > > framebuffer remapping after page initialization, leading to two regressions: > > > > 1) very slow scrolling after page initialization, > > > > 2) kernel hang when the 'keep_bootcon' command line argument is passed. > > > > > > > > Putting the tweak back fixes #2 and mitigates #1, i.e., it limits the slow > > > > behavior to the early boot stages, presumably due to eliminating heavy > > > > map()/unmap() operations per each pixel line on the screen. > > > > > > > > > > Could the efi earlycon have an interaction with PCI resource allocation, > > > similar to what commit dcf8f5ce3165 ("drivers/fbdev/efifb: Allow BAR to > > > be moved instead of claiming it") fixed for efifb? > > > > Yes. If the BAR gets moved, things will break. This is mostly an issue > > for the keep_bootcon case, but that is documented as being a debug > > feature specifically for addressing console initialization related > > issues. Earlycon itself is also a debug feature, so if you hit the BAR > > reallocation issue, you're simply out of luck. Note that this happens > > rarely in practice, only on non-x86 systems where the firmware and the > > kernel have very different policies regarding BAR allocation, and on > > DT based systems, you can force the OS to honour the existing > > allocation by using linux,pci-probe-only > > Thanks. Another q -- I tried out the earlycon=efifb, and it seems like > it gets disabled (without keep_bootcon) as soon as dummycon takes over, > which is well before the real console. > > DUMMY_CONSOLE is defined as > depends on VGA_CONSOLE!=y || SGI_NEWPORT_CONSOLE!=y > default y > > so it seems like it will pretty much always be enabled, as it doesn't > seem likely that VGA_CONSOLE=y and SGI_NEWPORT_CONSOLE=y would ever be > true simultaneously. > > Am I missing something or is this the way it's supposed to work? So > keep_bootcon seems almost necessary with the EFI boot console? Would a > patch to not disable boot console when dummycon is initialized, but wait > for a real console, be useful? > Well spotted! I have traced this down to [0] which combined various arch specific definitions into one, and obviously chose the wrong boolean operator for combining the conditions. Patches welcome. [0] https://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git/commit/drivers/video/console/Kconfig?id=31d2a7d36d6989c714b792ec00358ada24c039e7