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 2C9422080CF for ; Fri, 10 Jan 2025 20:51:32 +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=1736542293; cv=none; b=uj0yE3aBX5c/dqacJOfmlTd2zLhBk3HyMubmZ1+ETQRB0efiMeJG30ay5ypI2HNEWOu/rnJKfLiEX8x/XLBpvT8I4Gkkk2HmUPfeQ/r/IiszU9+QBJ//QkROwTxIOoRKre1to+kWgK4IyIRpkt4xKPaKokt4V1k0k6/+/kLyowU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736542293; c=relaxed/simple; bh=RMOS3YhhKQV6OaXb9qgvpdMvkOKnb/EdkDIFb/FfTYg=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=qFLCMAdFG6qUTa5cSXQVi48usVM1KcI9V4b61dkHxd0Lw30AFBPqqvP+sfw2dOFeW0UchlrzmWyMOYhkPQbPs26DyjGWx1UhKvFVZL+cpCNbc1ykS+pwPsjeYSxerc0ZzFx6JAPrAg47BQuEQjuZdWVd31jPhMIbpRexL3rBW4E= 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=A9OZi4x7; 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="A9OZi4x7" Received: from romank-3650.corp.microsoft.com (unknown [131.107.160.188]) by linux.microsoft.com (Postfix) with ESMTPSA id 9DF6F203D5F1; Fri, 10 Jan 2025 12:51:31 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 9DF6F203D5F1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1736542291; bh=2k1yAgpsr9pxI9IojWRlNwt/DPVvdDghwONr6dNfrgk=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=A9OZi4x7+nBffG34L0GWdTkW+04crRjLjwXSfd/uenNjq4X9Yvmxakl0i6Z76XiXQ +lItI6gDke8Zq0UPYZOEpehbjnGNt6Bf2mdhxL4dhSzxx1uRUfvUM6K3SvA8dtXUkG 7UbuDmmRhWTdFIObbA9QB/6PPRuSZyVBgGBxo30E= From: Roman Kisel To: hpa@zytor.com Cc: akpm@linux-foundation.org, apais@microsoft.com, benhill@microsoft.com, bhe@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, kai.huang@intel.com, kirill.shutemov@linux.intel.com, linux-kernel@vger.kernel.org, mingo@redhat.com, pbonzini@redhat.com, romank@linux.microsoft.com, ssengar@microsoft.com, sunilmut@microsoft.com, tglx@linutronix.de, vdso@hexbites.dev, x86@kernel.org Subject: Re: [PATCH] x86/reboot: Don't corrupt memory on non-BIOS systems Date: Fri, 10 Jan 2025 12:51:30 -0800 Message-Id: <20250110205130.49354-1-romank@linux.microsoft.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <35864797-77DF-434C-A912-F4B5FA03E863@zytor.com> References: <35864797-77DF-434C-A912-F4B5FA03E863@zytor.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Thu, 09 Jan 2025 19:23:31 -0800, H. Peter Anvin wrote: [...] >Which system have you seen where this "corrupts" memory? These are X86_64 systems that boot off of confguration in DeviceTree, and neither ACPI, BIOS, nor UEFI are present. The processors start running in the long mode right off the bat, and the physical memory below 4GiB is non-RAM or reserved. The systems are virtual machines. All that makes `*((unsigned short *)__va(0x472)) = mode;` constitue a stray write and effectively corrupt contents at the address of 0x472 for these virtual systems. On the physical systems I have had access to, 0x0..0x1000 seems to be reported as reserved in E820 or UEFI memory map, and that's what the CPU might need in the 16-bit mode for the brief times it might be used. Perhaps, `native_machine_emergency_restart` being tailored to the quirks of the physical hardware cannot absorb some condition around `*((unsigned short *)__va(0x472)) = mode;` to make sure it is fine to write at that address? In the light of that, the callback `machine_ops.emergency_restart` looks as a safer option.