From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 25BE633FE05 for ; Thu, 26 Mar 2026 15:01:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.160.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774537272; cv=none; b=Q4blPx3jNsn4rmSnoU6lYbHoPtH9AauB+7VlU4CKZpq3VO9duvW8yLa07iaKbKRPNmC2DQ7vxHD1iXv/NyHn/S3gqWdivB9uUfdrP133DT9+Psh8g5bsnR06cyOFQzlBLCViB3fWYdG6uf4JJSnro8EkVfFokZexDMzWzs6HJM4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774537272; c=relaxed/simple; bh=dGoCuuZmyMbf+619WEt0vZ/Z5SXQh6PbIpk3cG9v9z4=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References: Content-Type:MIME-Version; b=JsoQY4sZVmxXTKT+Rz+nmlXIh7gyIsfF880z98Y6hxtjmJKHh3a1n7gvA5loxXp1P/if5ZXchDb3vDLQQWRPNdrZ/9wpC9ARGPcGGJ8yhfezFNJTHPfs84W7JNp3UgOZm7knM6Q0QZUk6IcZ0C2CC4aTo+/IG0itJosvo/tYIag= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=ieee.org; spf=pass smtp.mailfrom=ieee.org; dkim=pass (1024-bit key) header.d=ieee.org header.i=@ieee.org header.b=YgUI6VEF; arc=none smtp.client-ip=209.85.160.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=ieee.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ieee.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ieee.org header.i=@ieee.org header.b="YgUI6VEF" Received: by mail-qt1-f172.google.com with SMTP id d75a77b69052e-506251815a3so9639181cf.0 for ; Thu, 26 Mar 2026 08:01:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ieee.org; s=google; t=1774537269; x=1775142069; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:to:from:subject:message-id:from:to:cc:subject:date :message-id:reply-to; bh=dGoCuuZmyMbf+619WEt0vZ/Z5SXQh6PbIpk3cG9v9z4=; b=YgUI6VEFP3ERYjDxYvo0rlx9gIU9eVtYSC1oSzzuGv/SU9VP8k2XaGL15TSPfXl/Hd ePZuhN0jnJX/Ao2tl9oR2EC21P4QML1pgGHMIeZnh1jvUKBzWZqoyl84t7xOXxzOYG+m /ewjSYoRKBffICooX3/DzJV+RRHJB8IuahF94= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774537269; x=1775142069; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=dGoCuuZmyMbf+619WEt0vZ/Z5SXQh6PbIpk3cG9v9z4=; b=hFdQU/6vAD5yujLKpQAEvnVVZD214iTAHbPR2eZUCQnJRkwhRuFd6g5fQa+tBAQAjf nFovrGzve7GonyywtrGD82E23kiNVl1tq2hE3vhoc4Iwn4yD8xIiifm0ciM/aae/w/d0 qCio9ZPNtTW1Zi5J2TfdMZR7JeKJy+bKmzUHqzbnzJgnSS0b7q4gnZvA5T4eMK713goS xBWk+VxQOy9p+RP0rpW2oeebbtdWs6KInaGrNUXl14cG1dp0XMYWkn6ocv+nPT6FaFK4 mzf1/G4BmsVhXwVNNhSc8ZtjvMRwUs9W7RhuaRFv+haHVP4z1STHhnC8z+cq0VSvnNii /qdQ== X-Gm-Message-State: AOJu0Yx9XLRft5TusxjMx2xcQF65GtTix2My2vCxJKfXYWRJgELajYCa s6WEcGQsAyOwtWsidBSZuTqRtWV+iPSe4gbyoyxxLsw6o+2TJnllCD0mn/pmk1fSwxvP6clvbg4 LKu1yxtFiXz938O/FOigB1K/1OZ33p3Voh1HSaVSM1tu2uz1xDidqUIAeyD73HkBcC8KcTGo5k5 J+XmP5CxhEm/PDcgdbjvzLp6OZz/LHeZOnyBXxBzw0z1bs X-Gm-Gg: ATEYQzw5yH/++4QdPw29HgpRyr+1BTpwRmqlhTwyIbbuVlimzyosg80rC2P4NjXn1IE bwktRJ3eHFp4GBcs3NWYGIYhzyXlsx7H+E8X1aMPN4l07Wx2XHM2WI9o7k3W6UhBPWKm5otZhwn pwD4IfrQv2aa+veLh9ewVse6RWNE7sOdvu6N8VKuoL+M6fVwLgVxqBJSM/UkzDv4Smyo9u4Z1Kp YGM8xQUBkrbk0tko/uTf/XWQ9xiHfYB/aZjjyQQ71yfqscX01g7v6zgY1geoCV/ET4NdvEZZJoi /9qIxqXFtKX/TdUPa5GrHhxjgH4xGQrZ+Vrw560jpjwdjG33rxcJ9aSdNi04vEjnlL2JtWH04Nd yU6s++GYwMCLwOdYfEzFzvcCdEf1zxwO3isrUK1n3pX8G9AG1DlfZtxBnQdQGD8WAFREUJvL+zN GYvGTV7rnAX1GJzo681MpX6Xk= X-Received: by 2002:ac8:7f0a:0:b0:50b:3895:c22f with SMTP id d75a77b69052e-50b80d1ae41mr112681891cf.26.1774537263584; Thu, 26 Mar 2026 08:01:03 -0700 (PDT) Received: from [192.168.153.215] ([73.29.38.247]) by smtp.gmail.com with ESMTPSA id d75a77b69052e-50b923a2bc9sm27185641cf.23.2026.03.26.08.01.02 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Mar 2026 08:01:03 -0700 (PDT) Message-ID: Subject: Re: Make ReBAR Great Again From: Cristian Cocos To: linux-hotplug@vger.kernel.org Date: Thu, 26 Mar 2026 11:01:02 -0400 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.60.0 (by Flathub.org) Precedence: bulk X-Mailing-List: linux-hotplug@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Is this the right forum to post this? The hotplug list looked to me to be the most appropriate venue, though please advise if you guys can think of a more appropriate recipient. The short story is that ReBAR does not work in hotplug scenarios: hotplugged eGPUs are forced onto a 256MB BAR regardless of the system's ReBAR capabilities, and this because during hotplug the Linux kernel does not consult the ReBAR capability. It's that simple. Seeing as eGPUs are becoming more popular, accommodating eGPU hotplug scenarios becomes stringent. On Sun, 2026-03-08 at 15:35 -0400, Cristian Cocos wrote: > The following is a suggestion for the Linux kernel devs. >=20 > Now that Thunderbolt eGPUs have become more common, it might be a > good > idea to make the Linux kernel ReBAR-over-Thunderbolt friendly. This, > I > contend, can be done by simply mimicking the system behavior at boot > time. >=20 > The current Thunderbolt eGPU *hotplug* sequence of events is this: > BAR > 2's hardware register powers up at 256 MB =E2=80=94 the default size > programmed > into the BAR's address decoder by Intel at the factory. The PCIe > Resizable BAR capability advertises support for up to 16 GB, but it's > passive =E2=80=94 software must explicitly exercise it. When a Thunderbol= t > eGPU > is hotplugged at runtime, the kernel's PCI subsystem enumerates the > new > device, reads the BAR at its 256 MB default, sizes the bridge windows > to match, and assigns addresses =E2=80=94 all before any driver loads. Th= e > ReBAR capability is never consulted(!) during this process. >=20 > A workaround is available for cold-plug scenarios only, and is > achieved=C2=A0by means of the **thunderbolt.host_reset=3D0** kernel > parameter: > this preserves the BIOS's PCIe tunnel and BAR assignments from POST > (where the BIOS *does* exercise ReBAR). This delivers the full 16 GB > BAR but, as just mentioned, only works for cold-plug(!) scenarios =E2=80= =94 > if > the eGPU is power-cycled at runtime, the new tunnel gets the 256 MB > default. >=20 > The proper fix would be for the kernel's PCI hotplug resource > assignment to=C2=A0*first*=C2=A0check for ReBAR capability during enumera= tion, > resize the BAR to the largest supported size that fits within > available > bridge headroom, and=C2=A0*then*=C2=A0commit bridge windows and assign > addresses. > This is essentially what the BIOS does during POST. It hasn't been > implemented yet because eGPU-over-Thunderbolt-with-ReBAR is (was?) a > niche use case. >=20 > Well, no more niche use case. eGPU-over-Thunderbolt is becoming > mainstream. >=20 >=20