From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from linux.microsoft.com (linux.microsoft.com [13.77.154.182]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6F1D4206F33 for ; Fri, 10 Jan 2025 21:05:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=13.77.154.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736543157; cv=none; b=ddIz6awkJG3W5fizUuR56ONGSelwxaAZOcxHJIQVe5IAiQHfku5+DpF8JiYi19ELAoAXbG2XH1ENlKE/752dIUjJVv4TWAOY3kycHCJVaBR1CkZf9tDBHptto2gcPiEI3riEQtbr61zW3ZmWNpGgCl5HbFZ2oEs5BPMKqSJfnJk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736543157; c=relaxed/simple; bh=Atdu6IyykYyBvJ6F5q4Hv2Jut3ckNhAdV78gwVYeQ0Y=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=CmkbKVx8PPzS/Gu2GAhgtFdsl4nCoVgCcI4NCWZEsZAPKTocUlkG1SHb+FnR2ut+EU2lJ62T9lRhaNhbwlkXJIk3cRGArd+LKKdpNQP27XIoGABKPaaPQp2ORX5GLqWdqmLBoSJZIMcOX92RMDTXEPa3Aezj9u698zmQT5xM+30= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com; spf=pass smtp.mailfrom=linux.microsoft.com; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b=f23qsjBi; arc=none smtp.client-ip=13.77.154.182 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.microsoft.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.microsoft.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.microsoft.com header.i=@linux.microsoft.com header.b="f23qsjBi" Received: from [10.137.184.60] (unknown [131.107.160.188]) by linux.microsoft.com (Postfix) with ESMTPSA id E951E203D5F2; Fri, 10 Jan 2025 13:05:55 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com E951E203D5F2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1736543156; bh=EZgD3UN6PDSYB3zZtOtDhAXmz30JK6Wj4NvtcXvOV+g=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=f23qsjBiHF11nMUGqvRsho4bmZdCwqQARkNEmuPpldgL9MDFVF8ZxS+33/iZs0clg GTj6S/SL4avVBElAS1cru4V58/OSoDQJoyjayeTXe5e8iKFNyUrv3q80rVCAnMJEBR iReg3qybmtFpQExi4fuoTQ3hxut2MkWc9NSzMXfk= Message-ID: Date: Fri, 10 Jan 2025 13:05:55 -0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] x86/reboot: Don't corrupt memory on non-BIOS systems To: "H. Peter Anvin" , akpm@linux-foundation.org, bhe@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, kai.huang@intel.com, kirill.shutemov@linux.intel.com, mingo@redhat.com, pbonzini@redhat.com, tglx@linutronix.de, x86@kernel.org, linux-kernel@vger.kernel.org Cc: apais@microsoft.com, benhill@microsoft.com, ssengar@microsoft.com, sunilmut@microsoft.com, vdso@hexbites.dev References: <20250109204352.1720337-1-romank@linux.microsoft.com> <9766201A-7C6B-4E80-A6A9-3593780F68F0@zytor.com> Content-Language: en-US From: Roman Kisel In-Reply-To: <9766201A-7C6B-4E80-A6A9-3593780F68F0@zytor.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 1/9/2025 7:25 PM, H. Peter Anvin wrote: > On January 9, 2025 12:43:52 PM PST, Roman Kisel wrote: [...] > > I should say: this patch is unambiguously *wrong*. It conflates the invocation mechanism with the desired post state, and they are not coupled. Calling the BIOS reboot entry point is not the normal way to reboot even on BIOS systems. Thank you very much for taking time to review and for the chance to learn from you! Would you like me to propose another patch where the line of *((unsigned short *)__va(0x472)) = mode; receives a comment for posterity why that it is okay to write at that address? Perhaps, /* * The common practice for the firmware is to report 0x0..0x1000 * as reserved in the RAM map. The value written to the address of * 0x472 may be used by the firmware to perform the cold or the warm * boot. */ might be a good addition to the code. I've looked at the UEFI+ACPI spec and couldn't find any mentions of that magical address, and the code writes at that address even in the UEFI case. If you have time to recommend normative documents where that might be explained, I'd greatly appreciate that! -- Thank you, Roman