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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 126CAC61D99 for ; Wed, 22 Nov 2023 23:36:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=vNFtsXohpt8iQCr30p4ky2br7YF+/JcCQzBZLrtpV64=; b=n4mmuV7DT/xSd1 JA8d7gTrCgt/hCh/lLBDhiIwTRjWHPacBrVGvPEnbDj7oDApsH7t4DS/Cb4zAU8h1yoK48MMwCbCa 29/J0UqLzw1LY0uaa/Cub9SfuCIWqP+poIkIIYH9eYwKAIWe36PLsGROFCgfPbOphk/8UeuO2RDUL Xbpr6MxzoRgaZTRICiYBnw1qEAvMYeQRp9Cww9Ub1WZLerQQu05kAFPp1JxvzEq5o+3fPGo8v1wrS u3eMHsG5gV5LZe2iyfrYHcO6jqRTwrh36lB0SWerz5t5eeZJig0r3yuCavy38D6CYms8xKIarxHeJ vg02U9v0oI4dT0Uw4XuA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1r5wlN-003KM5-10; Wed, 22 Nov 2023 23:36:09 +0000 Received: from out-187.mta0.migadu.com ([91.218.175.187]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1r5wlJ-003KL0-36 for linux-arm-kernel@lists.infradead.org; Wed, 22 Nov 2023 23:36:07 +0000 Date: Wed, 22 Nov 2023 23:35:57 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1700696162; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=PXyWegmwCnXnOPFvQ6LT5Yd+ik2iCdUmtXvgYfqocuM=; b=e4pm5gE3C8oJZdXhVRFH6B7ru6llu+TZOT2vj+rXc1A8XJ/IzaHkbbHIXWc/cKv42uWKbQ Lv+4Edhcgo35m59DoNtbxqh6HwTcWq7482blb85/acmgy7R7sBHRgCqBB8AY+KQ44fZcpn xOvVYVFoyPrW/OtqEgeifOUQ/uFxH7A= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Oliver Upton To: Sebastian Ene Cc: will@kernel.org, James Morse , Suzuki K Poulose , Zenghui Yu , catalin.marinas@arm.com, mark.rutland@arm.com, akpm@linux-foundation.org, maz@kernel.org, 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 Subject: Re: [PATCH v3 10/10] arm64: ptdump: Add support for guest stage-2 pagetables dumping Message-ID: References: <20231115171639.2852644-2-sebastianene@google.com> <20231115171639.2852644-12-sebastianene@google.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20231115171639.2852644-12-sebastianene@google.com> X-Migadu-Flow: FLOW_OUT X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20231122_153606_412377_D1E6B5A1 X-CRM114-Status: GOOD ( 12.93 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Nov 15, 2023 at 05:16:40PM +0000, Sebastian Ene wrote: > +struct ptdump_registered_guest { > + struct list_head reg_list; > + struct ptdump_info info; > + struct kvm_pgtable_snapshot snapshot; > + rwlock_t *lock; > +}; Why can't we just store a pointer directly to struct kvm in ::private? Also, shouldn't you take a reference on struct kvm when the file is opened to protect against VM teardown? > +static LIST_HEAD(ptdump_guest_list); > +static DEFINE_MUTEX(ptdump_list_lock); What is the list for? > static phys_addr_t ptdump_host_pa(void *addr) > { > return __pa(addr); > @@ -757,6 +768,63 @@ static void stage2_ptdump_walk(struct seq_file *s, struct ptdump_info *info) > kvm_pgtable_walk(pgtable, start_ipa, end_ipa, &walker); > } > > +static void guest_stage2_ptdump_walk(struct seq_file *s, > + struct ptdump_info *info) > +{ > + struct ptdump_info_file_priv *f_priv = > + container_of(info, struct ptdump_info_file_priv, info); > + struct ptdump_registered_guest *guest = info->priv; > + > + f_priv->file_priv = &guest->snapshot; > + > + read_lock(guest->lock); > + stage2_ptdump_walk(s, info); > + read_unlock(guest->lock); Taking the mmu lock for read allows other table walkers to add new mappings and adjust the granularity of existing ones. Should this instead take the mmu lock for write? > +} > + > +int ptdump_register_guest_stage2(struct kvm *kvm) > +{ > + struct ptdump_registered_guest *guest; > + struct kvm_s2_mmu *mmu = &kvm->arch.mmu; > + struct kvm_pgtable *pgt = mmu->pgt; > + > + guest = kzalloc(sizeof(struct ptdump_registered_guest), GFP_KERNEL); You want GFP_KERNEL_ACCOUNT here. -- Thanks, Oliver _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel