From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C1549C41535 for ; Tue, 19 Dec 2023 21:30:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 615EF8D0006; Tue, 19 Dec 2023 16:30:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 5C5E08D0001; Tue, 19 Dec 2023 16:30:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 43FD18D0006; Tue, 19 Dec 2023 16:30:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 31ACD8D0001 for ; Tue, 19 Dec 2023 16:30:17 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 06835A02D5 for ; Tue, 19 Dec 2023 21:30:17 +0000 (UTC) X-FDA: 81584861274.20.2315176 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2048.outbound.protection.outlook.com [40.107.243.48]) by imf21.hostedemail.com (Postfix) with ESMTP id 1917C1C001E for ; Tue, 19 Dec 2023 21:30:13 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=amd.com header.s=selector1 header.b=eIwhhi53; spf=pass (imf21.hostedemail.com: domain of Michael.Roth@amd.com designates 40.107.243.48 as permitted sender) smtp.mailfrom=Michael.Roth@amd.com; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=quarantine) header.from=amd.com ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1703021414; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=njFvsXpZeG4CEd1iTX4RH5PXIlbdu6OVa/YxjLvGJ8E=; b=b/FYTHnhdGk0OTPTkJcaQv26OUwQWXEOiE3GN0owo09iLdpRWOEmS0Wt56b38aZrcp1GZD vDhirWrIehUB+Q11wT+LtcE4hQanKAzXSytvzeMFtHfkDAaeXEgWL6KzOcNwhT+JIFrAgc Fo9iuagCNt2HMERUlSeBQIwJUddlUmM= ARC-Authentication-Results: i=2; imf21.hostedemail.com; dkim=pass header.d=amd.com header.s=selector1 header.b=eIwhhi53; spf=pass (imf21.hostedemail.com: domain of Michael.Roth@amd.com designates 40.107.243.48 as permitted sender) smtp.mailfrom=Michael.Roth@amd.com; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=quarantine) header.from=amd.com ARC-Seal: i=2; s=arc-20220608; d=hostedemail.com; t=1703021414; a=rsa-sha256; cv=pass; b=lBTIna8YUE/yTUcCDzmms5GfYjEg+ut3vxJFF3mQFP+e4ZvFC4HnJxt9jMU6VPHswNB0mB butZw9BR/5HclkF7rEE9aYXVvh3bzOu+3/o1eE8A6aXvUtHJDzB0zXmhNwa7U97eDiVX1g IThGF71eoF/zj8XgSKFin2x2BGQZpCI= ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FiCi4XkMWT+5Er6oE1zXuL2drNMkmXuPW/XCPfDn3YY0bEugpLr+ufJVq4biczTGI7fzHS4NykjqvYT1WaGG1DLZIYkOQsMC5Asr1ZEz1zOjKWKhtHmdSv0ZY6/xYB5fzhGCnKyULlGxTzU+b1O9P3iC09hLJ6qaXzuVqNKW6n/JEHqslLKdHzUZXzfC5iqrLUwb87pcE34Xq++kSpQ3DpWPebbZvIIHjO++wgJhiK8YFX4MCzVqJbGh+Z/o07DyQI4Oay5fbZdKwj3PRDjVvrEyO92mZqsuu77IIIdbr/8ClkPBB6Vn4veYXPt1kRL2ndWNWNsb+ktp4D0tcKIhyA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=njFvsXpZeG4CEd1iTX4RH5PXIlbdu6OVa/YxjLvGJ8E=; b=I77ObClNyDWOUL9iWVmZN3lB37NnGfQIw/CGS5lOrL+XLMEXK4WKDcfMZyTu1CTHv2LC7Ug0nikBaUWoLSBplM0xnzBuepNYem3ZbyRfoHpp+ZTm53MU79uNO9CQCCF2Jva6G8bBQBFofaKeMFICaPq68ZRHIsNKFzJHo0kbSisYhxnqr/h/SGDzbT/CHv3hb3VUIjsvXBKqgVNdQZmp7Y+QWn2zQPBxoTYaKMecOlr7oRg6nHSBJIiWmi3dgdii0skw3Jh5DlSi90/n4vJac64kZ2YxWQtcmZAQvIGer3+7PCmvRcF92V6yt2casIzN4XGJ0QMg2LBTRJcxftVMEA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=alien8.de smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=njFvsXpZeG4CEd1iTX4RH5PXIlbdu6OVa/YxjLvGJ8E=; b=eIwhhi53xxA8QRrkIgEcmndumqpAYa9Xr3R1jb2c/J+7AWZqSKaG4q7FhahOjb8dWNc4kP0D40suhY+V6E+4/qg+UQObACK9TuT8IMol0CoUFJaFZzAyx46uC3KwyavOndjjBawPJGwdyh7LqkjYY0ttXA4fbQtpkcnnt5a4uJU= Received: from SA1PR04CA0023.namprd04.prod.outlook.com (2603:10b6:806:2ce::27) by SN7PR12MB8148.namprd12.prod.outlook.com (2603:10b6:806:351::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7091.38; Tue, 19 Dec 2023 21:30:10 +0000 Received: from SA2PEPF00001509.namprd04.prod.outlook.com (2603:10b6:806:2ce:cafe::b9) by SA1PR04CA0023.outlook.office365.com (2603:10b6:806:2ce::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.7113.18 via Frontend Transport; Tue, 19 Dec 2023 21:30:10 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Received: from SATLEXMB04.amd.com (165.204.84.17) by SA2PEPF00001509.mail.protection.outlook.com (10.167.242.41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.7113.14 via Frontend Transport; Tue, 19 Dec 2023 21:30:09 +0000 Received: from localhost (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.34; Tue, 19 Dec 2023 15:30:07 -0600 Date: Tue, 19 Dec 2023 00:08:08 -0600 From: Michael Roth To: Borislav Petkov CC: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , Brijesh Singh Subject: Re: [PATCH v10 08/50] x86/fault: Add helper for dumping RMP entries Message-ID: <20231219060808.fngnt4lsvvqlnduu@amd.com> References: <20231016132819.1002933-1-michael.roth@amd.com> <20231016132819.1002933-9-michael.roth@amd.com> <20231115160852.GDZVTtFHB0+HpVZnpG@fat_crate.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20231115160852.GDZVTtFHB0+HpVZnpG@fat_crate.local> X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: SA2PEPF00001509:EE_|SN7PR12MB8148:EE_ X-MS-Office365-Filtering-Correlation-Id: ab501e39-a1af-41b4-f78b-08dc00d9ad41 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: PT5xUKAjrU53mb1PZNQ/dFCNAPUc3cInuZUDhdg8kijQop/D0dGGsU2t6ZUuvU8WI1teA+7SEgbzJBvXj+7VBvOmkhRF4Q/iwAdy3+G3mF3v+KXnA71aphXh+ZfISeDIUMeDvAkPnTa0LShQDiSqVxbTe3NCtkflxUeT/c+iGGSXg1BiboNZaRdqSP199tdbhmcDndcoj599bsNdlnQDNzDCg0LaTaz7YXFVpUx+67QX0VCSFRaM7iR3s/bsyXTpf+bm09D0HBBbn5tbGmqfKTgYj4FVdp/zap8KghYM0lyaxjl4zSNYigYEXq0UK/qF2IAy+8eiYgPkD1/ZP+t+0rlk952i1itRAEy5oHePPw9Gc9xeVQZmzLe4A1NDJqcju/HCM5/cnc6g6zmOjQd9fp+Tw10GHjRbym71r3m0F7KyJzfxBzhKiqHvvsFVgWNPCIr6j53zaPRRjnGoxOtzOyqwamcQ+7tZk49eiA5zthJt75DFTuVtgFhEjw8DeCxHFD98FOhC2ZT3QXLZ4cWsa/vEvgDFLvw+I4L+eCmAEZHEaasmXuP5V7nw5ksp7uW1ErUlFGvkHZI97pvogv45NbGnYUHAReL3D/ZM+w5PuVsQtb2yt5/KJUbRr/hRkEeLHaTMMtsDaYBM6LJYXfskHV+iTcBh6/F9X/f7XwYYLATOaM2igf/jBn7P8PM++9NxmKrovokRHhaKHLlHns95FhrazPd2MTx8Tn2LaD9X8QGj0CWuO7HTgEQBn6I8TOlTpfJmans2sns9xBmR0zAUnQ== X-Forefront-Antispam-Report: CIP:165.204.84.17;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:SATLEXMB04.amd.com;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230031)(4636009)(376002)(39860400002)(396003)(136003)(346002)(230922051799003)(64100799003)(186009)(1800799012)(451199024)(82310400011)(36840700001)(40470700004)(46966006)(36860700001)(356005)(40480700001)(47076005)(40460700003)(336012)(1076003)(426003)(83380400001)(16526019)(26005)(2616005)(36756003)(86362001)(82740400003)(81166007)(44832011)(478600001)(316002)(966005)(54906003)(6916009)(70206006)(70586007)(7416002)(4326008)(8676002)(8936002)(7406005)(5660300002)(2906002)(41300700001)(36900700001);DIR:OUT;SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Dec 2023 21:30:09.3827 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ab501e39-a1af-41b4-f78b-08dc00d9ad41 X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.17];Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: SA2PEPF00001509.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR12MB8148 X-Rspamd-Queue-Id: 1917C1C001E X-Rspam-User: X-Stat-Signature: kn7s5ani78hki99ywg9mctiqif4ipeb1 X-Rspamd-Server: rspam01 X-HE-Tag: 1703021413-341732 X-HE-Meta: U2FsdGVkX1/jCUHF4IkZXfNcTzRjjJJ4NT//GOFNocnx6Z02UpZ+5auiZe7b7QmbgKQTrT3JjS+S3/k1mna/O1FxFgTVP+6eopu6w0+/lZ+UHQpVG8J6ARdkp5jVSS2qlqS7iB95F1BsgE66NM3SXN2zUs0PNVBYcj4Q/inWG2OJncf7PEUL7t2h5UChUvqgmJFTYHsxZYWcgRb7WjfSQfHFMivDna2eItpG51tf+61clkAb6vi1FH0xWZ8oExHyOFzai8I8foiMuHgX9rkN3ek+douJJnGjTsHCvTRCnOoLg9dQt82+wVtEo/dbyRuZx6kYZixZjg+0VFMIR2/wLFF1KLjSmbX8yfCv0R78NZRd/yv57W9qIsKXHE/WsDeqMyJzY0NEsTBUY7gzIiO6T9rHAvdneYL+pGGjf9QtxsrtJo8AY6g2G5zuCGURxZpEArX304N/7K0beUYpNuyW7qzNBqVg/mQaVWl247g704mXAz9IQfmo69GaWL3pgAVmNSjV5fMw1KmC8OmY9G+6KaeeWAoTy/B3ORLk5QwOoANp6TMIzjYIOjnjh+hoB3ZdxyCGmxJyalMNRuIrFGdYVl1aPxjZjVe+nGyaT6Z14h3neieC5bHINrmb4DtkG861fGJQWfONxYuN7St2PpIb6gSa31+yzdvnC4UXmMvcdjwpJrWwgIvqE6tqhTnV5BpYS31cHN0eY/0zcrFMU9jUJVNp7kG3X7Dcga72Z1l7/0a6yMPG0SqGlfrO/oaUKj+xBhkfUs4MvxorBl9Tal8PZbKSaRnl3QVCiM20w5wE24NAuZZ632s+Ppa2F/UiTAp+d0U0OsYJL6tu4jn8foKepirMlIz7f0t9GQXnrVM5OgDXav0o9N4d338zu9tICXYt5Ls5d3y9gf+OIJ2RpJbM2RUCm4G428ehIxJ3lJw2w8EYE5/IrsEEyHTIxdCZs6d2ia1CMv30tQngskoKZrd T/vk6rdw afjMfELrCH19SsJQ1q3iej6DKMXmooxDWSo187CZYc4Z7dfswh8NvYceGue9QnNwfiZbg3zjTbAilgv5hKgaXogAoOaYyXNCbGca1xQn0CCLaRnrCfxm8FFMqO1bskFZ1XjYv/BJIs5HRbIVCPFAkV7Co/W/Sv0WofsGcxZBB1qh20S/StWubhlREtUIdpnYCfxkVbv6JknOoplr4e6XwOG2ngoxuek8W7mBKc0929eY57gsvQq1gpGSlb0Dv3o93PhlKVorKdbWeCxcYyppxszT1SVrMS8ixC/1YrRrqezjUTUdkApUJlKzLS2wrBoVYDgepo4d9eEuXddAPrt4WTERbuAzWwVd1GyFTh1C3pUufbV/vXRn/x+bF4cIDFnXqEzeJ0gZEtNyHXCCKMK8FLJ/hGYIyfq1eh8fbuCz7a85deYI= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Wed, Nov 15, 2023 at 05:08:52PM +0100, Borislav Petkov wrote: > On Mon, Oct 16, 2023 at 08:27:37AM -0500, Michael Roth wrote: > > +/* > > + * Dump the raw RMP entry for a particular PFN. These bits are documented in the > > + * PPR for a particular CPU model and provide useful information about how a > > + * particular PFN is being utilized by the kernel/firmware at the time certain > > + * unexpected events occur, such as RMP faults. > > + */ > > +static void sev_dump_rmpentry(u64 dumped_pfn) > > Just "dump_rmentry" > > s/dumped_pfn/pfn/g > > > + struct rmpentry e; > > + u64 pfn, pfn_end; > > + int level, ret; > > + u64 *e_data; > > + > > + ret = __snp_lookup_rmpentry(dumped_pfn, &e, &level); > > + if (ret) { > > + pr_info("Failed to read RMP entry for PFN 0x%llx, error %d\n", > > + dumped_pfn, ret); > > + return; > > + } > > + > > + e_data = (u64 *)&e; > > + if (e.assigned) { > > + pr_info("RMP entry for PFN 0x%llx: [high=0x%016llx low=0x%016llx]\n", > > + dumped_pfn, e_data[1], e_data[0]); > > + return; > > + } > > + > > + /* > > + * If the RMP entry for a particular PFN is not in an assigned state, > > + * then it is sometimes useful to get an idea of whether or not any RMP > > + * entries for other PFNs within the same 2MB region are assigned, since > > + * those too can affect the ability to access a particular PFN in > > + * certain situations, such as when the PFN is being accessed via a 2MB > > + * mapping in the host page table. > > + */ > > + pfn = ALIGN(dumped_pfn, PTRS_PER_PMD); > > + pfn_end = pfn + PTRS_PER_PMD; > > + > > + while (pfn < pfn_end) { > > + ret = __snp_lookup_rmpentry(pfn, &e, &level); > > + if (ret) { > > + pr_info_ratelimited("Failed to read RMP entry for PFN 0x%llx\n", pfn); > > Why ratelmited? Dave had some concerns about potentially printing out ~512 messages for a particular PFN dump, and this seemed like a potential case where that might still occur if there was some issue with RMP table access. But I still wanted to print some indicator if we did hit that case, since it might be related to whatever caused the dump to get triggered. > > No need to print anything if you fail to read it - simply dump the range > [pfn, pfn_end], _data[0], e_data[1] exactly *once* before the loop and > inside the loop dump only the ones you can lookup... Similar to above, the loop used to print every populated entry in the 2M range if the dumped PFN wasn't itself in an assigned state, but Dave had some concerns about flooding. So now the loop only prints 1 populated entry to provide some indication that there are entries present that could explain things like RMP faults for the PFN that caused the dump. That makes it a bit awkward to print a header statement, since you end up with something like: PFN is not assigned, so dumping the first populated RMP entry found with the 2MB range (if any) PFN_x is populated, contents [high=... low=...] Or if nothing found: PFN is not assigned, so dumping the first populated RMP entry found with the 2MB range (if any) Whereas the current logic just prints 1 self-contained statement which fully explains each of the above cases and doesn't require the user to infer there was nothing present in the range based on the lack of statement. It's a little clearer, a little less verbose, and a little easier to grep for either situation without needed to get context from surrounding statements. > > > + pfn++; > > + continue; > > + } > > + > > + if (e_data[0] || e_data[1]) { > > + pr_info("No assigned RMP entry for PFN 0x%llx, but the 2MB region contains populated RMP entries, e.g.: PFN 0x%llx: [high=0x%016llx low=0x%016llx]\n", > > + dumped_pfn, pfn, e_data[1], e_data[0]); > > + return; > > + } > > + pfn++; > > + } > > + > > + pr_info("No populated RMP entries in the 2MB region containing PFN 0x%llx\n", > > + dumped_pfn); > > ... and then you don't need this one either. > > > +} > > + > > +void sev_dump_hva_rmpentry(unsigned long hva) > > +{ > > + unsigned int level; > > + pgd_t *pgd; > > + pte_t *pte; > > + > > + pgd = __va(read_cr3_pa()); > > + pgd += pgd_index(hva); > > + pte = lookup_address_in_pgd(pgd, hva, &level); > > If this is using the current CR3, why aren't you simply using > lookup_address() here without the need to read pgd? > > > + > > + if (pte) { > > if (!pte) > > Doh. Yikes. Thanks for the catch. > > > + pr_info("Can't dump RMP entry for HVA %lx: no PTE/PFN found\n", hva); > > + return; > > + } > > + > > + sev_dump_rmpentry(pte_pfn(*pte)); > > +} > > +EXPORT_SYMBOL_GPL(sev_dump_hva_rmpentry); > > Who's going to use this, kvm? This is mainly used by the host #PF handler via show_fault_oops(). It can happen both for kernel or userspace accesses if there's a bug, so that's why the read_cr3_pa() is needed, since these may be userspace HVAs. Though I just realized the patch that uses this (next one in the series) claims to only be for kernel #PFs, so that might cause some confusion. I'll get that commit message fixed up. Thanks, Mike > > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette >