Message ID | 20231115171639.2852644-2-sebastianene@google.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b909:0:b0:403:3b70:6f57 with SMTP id t9csp2687171vqg; Wed, 15 Nov 2023 09:17:33 -0800 (PST) X-Google-Smtp-Source: AGHT+IEJZCdKmBDMmyGuk/KiNEfS6aPH6vI7HMOEbCV1UQPBVH3dvRWV4b9ae5NMNcEfPiWNuQzu X-Received: by 2002:a92:c24f:0:b0:358:ffc:e7ab with SMTP id k15-20020a92c24f000000b003580ffce7abmr19338192ilo.19.1700068653079; Wed, 15 Nov 2023 09:17:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1700068653; cv=none; d=google.com; s=arc-20160816; b=HZmq8CbqGcyiSVWUH9jaJ3bAss3N7FFSWc5godwUzfOYsC0y2pbED6kYm71RrHXV4l /rSAojz3Q3fVrRRWDM0XaRvdpwFe0tJn+B4JkKjRC0W4ZDV0sRo51DYyS+wcIr5MrxP1 9ov+waavrRuDBwe9F2NUnIMqdluTi6tg1/MWnnlUv9xBe4etVeh2YSOLVagdpTs9qqq8 W/Hyyb3qC1FclEL8Q5PkDayxMZMsA0HbG0mjqVOL2QgcDbaXjk+ueu20jUJuknjpkJw7 UMoWzTPCeDt6+nzs8rTqZFvUQdmi3HcAGUvONucGParbFHr2UK3YNuSGm9J1pigDLGc2 DwCQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:from:subject:message-id:mime-version:date :dkim-signature; bh=jvaWmO0FnVQSvQa+hPtEgtYlB7ewMwZZNTNrDNriGoM=; fh=4RXM1FFjr/2FDx2f50K7N78eRirWaG15JMQkQwGVT00=; b=Z4wSfG4OYwKA3UUgtDpX3rzV8Fajw2BIHruX6SLXZW9ok3DoTIMKmYZu0/zR4i3+Yh E2WLAOOEKonOAL0nTiZlumz0GPfL/DP5vFVJgf47KmZMDgWb7xBvM5hrui05tt8KnpgW XfqbL4lTbjtW7os688HRZArE1p3Q3TBGKJZdjxydkfrXOf31SEC6PGmgxTF5oryuuFAL fFBmjqS5kG1CePbWRxXLHLVoycELBXWbUwLyOCQ3Evbe+5LGIV1IAv/IFhIPQs/NPcH7 tZrxU0Xy3zSiSLk+ehhtz1uA0U9rHfh46mDCaEsK0pAT15bV0VLEKosFqBT84iNEJDUW fQrQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=Id+NKevk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from fry.vger.email (fry.vger.email. [23.128.96.38]) by mx.google.com with ESMTPS id x190-20020a6386c7000000b005b7dd1e13e7si9834807pgd.556.2023.11.15.09.17.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Nov 2023 09:17:33 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) client-ip=23.128.96.38; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20230601 header.b=Id+NKevk; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.38 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id 2717F81113B9; Wed, 15 Nov 2023 09:17:21 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230336AbjKORQ7 (ORCPT <rfc822;lhua1029@gmail.com> + 29 others); Wed, 15 Nov 2023 12:16:59 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47366 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229570AbjKORQ6 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 15 Nov 2023 12:16:58 -0500 Received: from mail-yb1-xb4a.google.com (mail-yb1-xb4a.google.com [IPv6:2607:f8b0:4864:20::b4a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 11DA318E for <linux-kernel@vger.kernel.org>; Wed, 15 Nov 2023 09:16:54 -0800 (PST) Received: by mail-yb1-xb4a.google.com with SMTP id 3f1490d57ef6-da0ccfc4fc8so8898668276.2 for <linux-kernel@vger.kernel.org>; Wed, 15 Nov 2023 09:16:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1700068613; x=1700673413; darn=vger.kernel.org; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=jvaWmO0FnVQSvQa+hPtEgtYlB7ewMwZZNTNrDNriGoM=; b=Id+NKevkOHduDfuz18MeJCn/gclNpmmDIniqFm9SVVYGzj8Gpg7h2enFmk3VUAzXTI 94W/sfGNaMciXnjxPAcdqgHIk8pjj2DA6jqsgILU3bhRvQVWBULiTzGEkoXqun70DeXB 6tqFUs9+wFlaUoaB881Kgs3iZkAJTBecK6WCyFP8pgaDgRtAoeVt9vw2aMGzzuKA2Ony BfJkzTC5Kzh9+T2I6MYXXG2vUVNV4UHaoEjp+c/mJbMdF24XV9T8Nw9FQlIxuMGEP25R 9RXGCUUOyXqaMqwK7XzDJT/cR2LkO+Nd1GeE7xP0I64caiPPUi2688CYIyl8Uw0FCNtE 8KPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700068613; x=1700673413; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=jvaWmO0FnVQSvQa+hPtEgtYlB7ewMwZZNTNrDNriGoM=; b=asnR6TNTJnZ1NDsXtATyzkN8Vht1nKGI3FoFFPODQ11aAV8dFWZrhZyYPcuum3aUEj UHgW6Y8WBL1kqCGMmHd1Fy76WHF+0FMPwdZ3t8R50DqPd5X+lgKDr9p9qAP6eI6UVGC2 wERuQ3AdKKXcXSX8Mq0wnNWworowAbbsefpep7+Lu7XWSv2cvDzb4AGkj+CbBVnqIncR UTAZqCsJKN25Nwic7HTU30Ae6q6greyTh/YACAwDXDQiGqjyhSK9tGtuoK3UD28rc/8k g7T7NfucRSmUVKI8qwF7VhtlkTS3tx5emPon22MaDdqrf2SdYGrcC7AHE6k/4wmjXRVR dsbQ== X-Gm-Message-State: AOJu0YyW/I8I5RzqP9vW0sHD33MWodxLn/nRisawSZe+Tg2iOhjt2SMc F3fo8TjZG3navJzcvwL6I5MYNJUbGeOitKqUb5Q= X-Received: from sebkvm.c.googlers.com ([fda3:e722:ac3:cc00:28:9cb1:c0a8:cd5]) (user=sebastianene job=sendgmr) by 2002:a25:24c7:0:b0:daf:660e:9bdb with SMTP id k190-20020a2524c7000000b00daf660e9bdbmr176609ybk.6.1700068613223; Wed, 15 Nov 2023 09:16:53 -0800 (PST) Date: Wed, 15 Nov 2023 17:16:30 +0000 Mime-Version: 1.0 X-Mailer: git-send-email 2.43.0.rc0.421.g78406f8d94-goog Message-ID: <20231115171639.2852644-2-sebastianene@google.com> Subject: [PATCH v3 00/10] arm64: ptdump: View the second stage page-tables From: Sebastian Ene <sebastianene@google.com> To: will@kernel.org, Oliver Upton <oliver.upton@linux.dev>, James Morse <james.morse@arm.com>, Suzuki K Poulose <suzuki.poulose@arm.com>, Zenghui Yu <yuzenghui@huawei.com>, catalin.marinas@arm.com, mark.rutland@arm.com, akpm@linux-foundation.org, maz@kernel.org Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kernel-team@android.com, vdonnefort@google.com, qperret@google.com, smostafa@google.com, Sebastian Ene <sebastianene@google.com> Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-8.4 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE, USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Wed, 15 Nov 2023 09:17:21 -0800 (PST) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1782651187831902400 X-GMAIL-MSGID: 1782651187831902400 |
Series |
arm64: ptdump: View the second stage page-tables
|
|
Message
Sebastian Ene
Nov. 15, 2023, 5:16 p.m. UTC
Hi, This can be used as a debugging tool for dumping the second stage page-tables. When CONFIG_PTDUMP_STAGE2_DEBUGFS is enabled, ptdump registers '/sys/debug/kvm/<guest_id>/stage2_page_tables' entry with debugfs upon guest creation. This allows userspace tools (eg. cat) to dump the stage-2 pagetables by reading the registered file. Reading the debugfs file shows stage-2 memory ranges in following format: <IPA range> <size> <descriptor type> <access permissions> <mem_attributes> Under pKVM configuration(kvm-arm.mode=protected) ptdump registers an entry for the host stage-2 pagetables in the following path: /sys/debug/kvm/host_stage2_page_tables/ The tool interprets the pKVM ownership annotation stored in the invalid entries and dumps to the console the ownership information. To be able to access the host stage-2 page-tables from the kernel, a new hypervisor call was introduced which allows us to snapshot the page-tables in a host provided buffer. The hypervisor call is hidden behind CONFIG_NVHE_EL2_DEBUG as this should be used under debugging environment. Link to the second version: https://lore.kernel.org/all/20231019144032.2943044-1-sebastianene@google.com/#r Link to the first version: https://lore.kernel.org/all/20230927112517.2631674-1-sebastianene@google.com/ Changelog: v2 -> v3: * register the stage-2 debugfs entry for the host under /sys/debug/kvm/host_stage2_page_tables and in /sys/debug/kvm/<guest_id>/stage2_page_tables for guests. * don't use a static array for parsing the attributes description, generate it dynamically based on the number of pagetable levels * remove the lock that was guarding the seq_file private inode data, and keep the data private to the open file session. * minor fixes & renaming of CONFIG_NVHE_EL2_PTDUMP_DEBUGFS to CONFIG_PTDUMP_STAGE2_DEBUGFS v1 -> v2: * use the stage-2 pagetable walker for dumping descriptors instead of the one provided by ptdump. * support for guests pagetables dumping under VHE/nVHE non-protected Thanks, Sebastian Ene (10): KVM: arm64: Add snap shooting the host stage-2 pagetables arm64: ptdump: Use the mask from the state structure arm64: ptdump: Add the walker function to the ptdump info structure KVM: arm64: Move pagetable definitions to common header arm64: ptdump: Add hooks on debugfs file operations arm64: ptdump: Register a debugfs entry for the host stage-2 tables arm64: ptdump: Parse the host stage-2 page-tables from the snapshot arm64: ptdump: Interpret memory attributes based on runtime configuration arm64: ptdump: Interpret pKVM ownership annotations arm64: ptdump: Add support for guest stage-2 pagetables dumping arch/arm64/include/asm/kvm_asm.h | 1 + arch/arm64/include/asm/kvm_pgtable.h | 85 +++ arch/arm64/include/asm/ptdump.h | 27 + arch/arm64/kvm/Kconfig | 13 + arch/arm64/kvm/arm.c | 2 + arch/arm64/kvm/debug.c | 6 + arch/arm64/kvm/hyp/include/nvhe/mem_protect.h | 8 +- arch/arm64/kvm/hyp/nvhe/hyp-main.c | 20 + arch/arm64/kvm/hyp/nvhe/mem_protect.c | 102 ++++ arch/arm64/kvm/hyp/pgtable.c | 98 ++-- arch/arm64/kvm/mmu.c | 2 + arch/arm64/mm/ptdump.c | 483 +++++++++++++++++- arch/arm64/mm/ptdump_debugfs.c | 64 ++- 13 files changed, 852 insertions(+), 59 deletions(-)
Comments
Hi Seb, On Wed, Nov 15, 2023 at 05:16:30PM +0000, Sebastian Ene wrote: > Hi, > > This can be used as a debugging tool for dumping the second stage > page-tables. > > When CONFIG_PTDUMP_STAGE2_DEBUGFS is enabled, ptdump registers > '/sys/debug/kvm/<guest_id>/stage2_page_tables' entry with debugfs > upon guest creation. This allows userspace tools (eg. cat) to dump the > stage-2 pagetables by reading the registered file. > > Reading the debugfs file shows stage-2 memory ranges in following format: > <IPA range> <size> <descriptor type> <access permissions> <mem_attributes> > > Under pKVM configuration(kvm-arm.mode=protected) ptdump registers an entry > for the host stage-2 pagetables in the following path: > /sys/debug/kvm/host_stage2_page_tables/ > > The tool interprets the pKVM ownership annotation stored in the invalid > entries and dumps to the console the ownership information. To be able > to access the host stage-2 page-tables from the kernel, a new hypervisor > call was introduced which allows us to snapshot the page-tables in a host > provided buffer. The hypervisor call is hidden behind CONFIG_NVHE_EL2_DEBUG > as this should be used under debugging environment. While I think the value of the feature you're proposing is great, I'm not a fan of the current shape of this series. Reusing note_page() for the stage-2 dump is somewhat convenient, but the series pulls a **massive** amount of KVM details outside of KVM: - Open-coding the whole snapshotting interface with EL2 outside of KVM. This is a complete non-starter for me; the kernel<->EL2 interface needs to be owned by the EL1 portions of KVM. - Building page-table walkers using the KVM pgtable library outside of KVM. - Copying (rather than directly calling) the logic responsible for things like FWB and PGD concatenation. - Hoisting the definition of _software bits_ outside of KVM. I'm less concerned about hardware bits since they have an unambiguous meaning. I think exporting the necessary stuff from ptdump into KVM will lead to a much cleaner implementation.
On Wed, Nov 22, 2023 at 11:18:45PM +0000, Oliver Upton wrote: Hi Oliver, > Hi Seb, > > On Wed, Nov 15, 2023 at 05:16:30PM +0000, Sebastian Ene wrote: > > Hi, > > > > This can be used as a debugging tool for dumping the second stage > > page-tables. > > > > When CONFIG_PTDUMP_STAGE2_DEBUGFS is enabled, ptdump registers > > '/sys/debug/kvm/<guest_id>/stage2_page_tables' entry with debugfs > > upon guest creation. This allows userspace tools (eg. cat) to dump the > > stage-2 pagetables by reading the registered file. > > > > Reading the debugfs file shows stage-2 memory ranges in following format: > > <IPA range> <size> <descriptor type> <access permissions> <mem_attributes> > > > > Under pKVM configuration(kvm-arm.mode=protected) ptdump registers an entry > > for the host stage-2 pagetables in the following path: > > /sys/debug/kvm/host_stage2_page_tables/ > > > > The tool interprets the pKVM ownership annotation stored in the invalid > > entries and dumps to the console the ownership information. To be able > > to access the host stage-2 page-tables from the kernel, a new hypervisor > > call was introduced which allows us to snapshot the page-tables in a host > > provided buffer. The hypervisor call is hidden behind CONFIG_NVHE_EL2_DEBUG > > as this should be used under debugging environment. > > While I think the value of the feature you're proposing is great, I'm > not a fan of the current shape of this series. > > Reusing note_page() for the stage-2 dump is somewhat convenient, but the > series pulls a **massive** amount of KVM details outside of KVM: > > - Open-coding the whole snapshotting interface with EL2 outside of KVM. > This is a complete non-starter for me; the kernel<->EL2 interface > needs to be owned by the EL1 portions of KVM. > > - Building page-table walkers using the KVM pgtable library outside of > KVM. > > - Copying (rather than directly calling) the logic responsible for > things like FWB and PGD concatenation. > > - Hoisting the definition of _software bits_ outside of KVM. I'm less > concerned about hardware bits since they have an unambiguous meaning. > > I think exporting the necessary stuff from ptdump into KVM will lead to > a much cleaner implementation. > Right, I had to import a lot of definitions from KVM, especially for the prot_bits array and for the IPA size retrieval. I think it would be less intrusive the other way around, to pull some ptdump hooks into kvm. > -- > Thanks, > Oliver Thanks, Seb