From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B9F18399A57 for ; Thu, 15 Jan 2026 15:10:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=192.198.163.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768489858; cv=none; b=KJleyNjCYj4I/QrY4HgRX/O7ixqUBLl9Ae6ai7Qzn1ZuPjwyKqtl8tIhbLt4tiauSZPK7YNmp2fS3rxl6OxMWNiVKoy3Br64drMB8NV7rqDPKO74FDsYe2OsnR/korfMzXsDS2yI+N+CGUdLy5A0TFqHqXKjLsni7XC6i44Ka/U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768489858; c=relaxed/simple; bh=zJtKOUTDeVup7QvvLjg/CY50ojhXg1JVcSwyHLTVV5U=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Qc+QMuMgXmSJdek7U4pq/Gx9V/uhH6JVBj4vrB2punBOymxmin0LgzMbiVYNahSrERF5liekgtGUN+wObx9UqfqUIK+NO4und0BJDNCm/Y1CJDGgYcX9XSi32CfozfmSpY6gXKJkLAXjIskGfFvy0lDyooWXCprSh1MXi5EaEWc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=O/Xzl9PU; arc=none smtp.client-ip=192.198.163.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="O/Xzl9PU" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1768489843; x=1800025843; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=zJtKOUTDeVup7QvvLjg/CY50ojhXg1JVcSwyHLTVV5U=; b=O/Xzl9PUt8WtsO0Z6Mh4L5KKHeYPAWbdp3Um6I3+eT5Q0GQhcdgHz+Gw B4XOI30tiEsR0ZWSItQqvFivr37BQj8TBI+2A40HoKAO9zgarV/2vkUMi c4lquHHtgi4/A8KtPOJbexPvyi+/2uSCmHpxTsw6EyO5CduOD2n9OFCej E8XRyGoOjrriSpVOa8Pb8MQoFT8hJxzxgKq4iHuuuRpjh151mbhUC9lyc Db8DIR4r7v/lYRs1A00/3gTaHZDksuvFlAGuRwv3ixtp7f3MGkj7gyEIu H9kiA0t/9PU7Rc9WHIqvlE9t7KDQcGY3q8YhdlkVBUwM6cwGFbYTk2hBL g==; X-CSE-ConnectionGUID: n0s6dWtKRkmXlbN8owdJug== X-CSE-MsgGUID: TcCenhNUTD+hck5rwM2L2w== X-IronPort-AV: E=McAfee;i="6800,10657,11672"; a="80439982" X-IronPort-AV: E=Sophos;i="6.21,228,1763452800"; d="scan'208";a="80439982" Received: from orviesa007.jf.intel.com ([10.64.159.147]) by fmvoesa105.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Jan 2026 07:10:39 -0800 X-CSE-ConnectionGUID: QlyxHSHiTzCEbE1DbfKHgA== X-CSE-MsgGUID: Hevrt8lZSOytYcWKGKE26Q== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.21,228,1763452800"; d="scan'208";a="205005261" Received: from egrumbac-mobl6.ger.corp.intel.com (HELO localhost) ([10.245.245.53]) by orviesa007-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Jan 2026 07:10:28 -0800 Date: Thu, 15 Jan 2026 17:10:24 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Christian =?iso-8859-1?Q?K=F6nig?= Cc: Thomas Zimmermann , Zack Rusin , dri-devel@lists.freedesktop.org, Alex Deucher , amd-gfx@lists.freedesktop.org, Ard Biesheuvel , Ce Sun , Chia-I Wu , Danilo Krummrich , Dave Airlie , Deepak Rawat , Dmitry Osipenko , Gerd Hoffmann , Gurchetan Singh , Hans de Goede , Hawking Zhang , Helge Deller , intel-gfx@lists.freedesktop.org, intel-xe@lists.freedesktop.org, Jani Nikula , Javier Martinez Canillas , Jocelyn Falempe , Joonas Lahtinen , Lijo Lazar , linux-efi@vger.kernel.org, linux-fbdev@vger.kernel.org, linux-hyperv@vger.kernel.org, linux-kernel@vger.kernel.org, Lucas De Marchi , Lyude Paul , Maarten Lankhorst , "Mario Limonciello (AMD)" , Mario Limonciello , Maxime Ripard , nouveau@lists.freedesktop.org, Rodrigo Vivi , Simona Vetter , spice-devel@lists.freedesktop.org, Thomas =?iso-8859-1?Q?Hellstr=F6m?= , Timur =?iso-8859-1?Q?Krist=F3f?= , Tvrtko Ursulin , virtualization@lists.linux.dev, Vitaly Prosyak Subject: Re: [PATCH 00/12] Recover sysfb after DRM probe failure Message-ID: References: <20251229215906.3688205-1-zack.rusin@broadcom.com> <97993761-5884-4ada-b345-9fb64819e02a@suse.de> <9058636d-cc18-4c8f-92cf-782fd8f771af@amd.com> Precedence: bulk X-Mailing-List: virtualization@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <9058636d-cc18-4c8f-92cf-782fd8f771af@amd.com> X-Patchwork-Hint: comment Organization: Intel Finland Oy - BIC 0357606-4 - c/o Alberga Business Park, 6 krs Bertel Jungin Aukio 5, 02600 Espoo, Finland On Thu, Jan 15, 2026 at 03:39:00PM +0100, Christian König wrote: > Sorry to being late, but I only now realized what you are doing here. > > On 1/15/26 12:02, Thomas Zimmermann wrote: > > Hi, > > > > apologies for the delay. I wanted to reply and then forgot about it. > > > > Am 10.01.26 um 05:52 schrieb Zack Rusin: > >> On Fri, Jan 9, 2026 at 5:34 AM Thomas Zimmermann wrote: > >>> Hi > >>> > >>> Am 29.12.25 um 22:58 schrieb Zack Rusin: > >>>> Almost a rite of passage for every DRM developer and most Linux users > >>>> is upgrading your DRM driver/updating boot flags/changing some config > >>>> and having DRM driver fail at probe resulting in a blank screen. > >>>> > >>>> Currently there's no way to recover from DRM driver probe failure. PCI > >>>> DRM driver explicitly throw out the existing sysfb to get exclusive > >>>> access to PCI resources so if the probe fails the system is left without > >>>> a functioning display driver. > >>>> > >>>> Add code to sysfb to recever system framebuffer when DRM driver's probe > >>>> fails. This means that a DRM driver that fails to load reloads the system > >>>> framebuffer driver. > >>>> > >>>> This works best with simpledrm. Without it Xorg won't recover because > >>>> it still tries to load the vendor specific driver which ends up usually > >>>> not working at all. With simpledrm the system recovers really nicely > >>>> ending up with a working console and not a blank screen. > >>>> > >>>> There's a caveat in that some hardware might require some special magic > >>>> register write to recover EFI display. I'd appreciate it a lot if > >>>> maintainers could introduce a temporary failure in their drivers > >>>> probe to validate that the sysfb recovers and they get a working console. > >>>> The easiest way to double check it is by adding: > >>>>    /* XXX: Temporary failure to test sysfb restore - REMOVE BEFORE COMMIT */ > >>>>    dev_info(&pdev->dev, "Testing sysfb restore: forcing probe failure\n"); > >>>>    ret = -EINVAL; > >>>>    goto out_error; > >>>> or such right after the devm_aperture_remove_conflicting_pci_devices . > >>> Recovering the display like that is guess work and will at best work > >>> with simple discrete devices where the framebuffer is always located in > >>> a confined graphics aperture. > >>> > >>> But the problem you're trying to solve is a real one. > >>> > >>> What we'd want to do instead is to take the initial hardware state into > >>> account when we do the initial mode-setting operation. > >>> > >>> The first step is to move each driver's remove_conflicting_devices call > >>> to the latest possible location in the probe function. We usually do it > >>> first, because that's easy. But on most hardware, it could happen much > >>> later. > >> Well, some drivers (vbox, vmwgfx, bochs and currus-qemu) do it because > >> they request pci regions which is going to fail otherwise. Because > >> grabbining the pci resources is in general the very first thing that > >> those drivers need to do to setup anything, we > >> remove_conflicting_devices first or at least very early. > > > > To my knowledge, requesting resources is more about correctness than a hard requirement to use an I/O or memory range. Has this changed? > > Nope that is not correct. > > At least for AMD GPUs remove_conflicting_devices() really early is necessary because otherwise some operations just result in a spontaneous system reboot. > > For example resizing the PCIe BAR giving access to VRAM or disabling VGA emulation (which AFAIK is used for EFI as well) is only possible when the VGA or EFI framebuffer driver is kicked out first. > > And disabling VGA emulation is among the absolutely first steps you do to take over the scanout config. It's similar for Intel. For us VGA emulation won't be used for EFI boot, but we still can't have the previous driver poking around in memory while the real driver is initializing. The entire memory layout may get completely shuffled so there's no telling where such memory accesses would land. And I suppose reBAR is a concern for us as well. -- Ville Syrjälä Intel