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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0EE40C25B4E for ; Tue, 24 Jan 2023 15:54:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233915AbjAXPyz (ORCPT ); Tue, 24 Jan 2023 10:54:55 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:32982 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233425AbjAXPyx (ORCPT ); Tue, 24 Jan 2023 10:54:53 -0500 Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 274FB49406 for ; Tue, 24 Jan 2023 07:54:53 -0800 (PST) Received: by mail-pj1-x102d.google.com with SMTP id u1-20020a17090a450100b0022936a63a21so18989528pjg.4 for ; Tue, 24 Jan 2023 07:54:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=tTB7QQhaFSlJZCgaajKbzp9eWeGSwdO4XEz/GYqEPW8=; b=WLrzs2UbKnxvmlEXQmhbTDf/QauwbyqmKmZHAz2K8tZCKPQ9o3EQGeimUUsavMAWkx BpehPBLyWtPsQg9sAQUeSxs81wkP4Puvj6RhemDLofbk5gO5J44dUGm0Aw9yLAnyXN26 Yousn6hgnAHb0Csm8CynGQBc96HZvQqjSi+hJCn0GMxNJiPS7alV93LHIOWv916+f3o/ ZpesoNLvsQiqCicY00FkXJ3KfNyA+dVGmhr22vEfUgbqb059OAyNtAdEMEw3zaQE5QVl 0RXelImEnStBITFtg8EGEvdCAdIskk2a5N8OsKDzE0qlVPzAbMFSVyu0fGVq0uEzc6Vr baLg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=tTB7QQhaFSlJZCgaajKbzp9eWeGSwdO4XEz/GYqEPW8=; b=7arTFY9/B9zkSUbTJpGJEBRRpGAnN0PYP9kLklUP9/6grd9Piqno6b2frUgjlBU2My xdjdAMhaTyTiuzllDX37Rk19NSMmr9924GtFJ2QNKT/NHUeE+BR/q5+L18XMuDdEr6Zb 3g2ODm9wYZinYmszvWO61C5ntQ3Gt3IqJ8guiRSKclv2JWlxXZVx2IX7SaRQ1r8ePbCv YcUYnrauycGBOjApPJBbkdgkuGc7juRLwjnbBFEnZ4PgQB+hoFSha21+UZVNJ3Tr4L8b YtfjvtiO4/HCF0mlruGgc6X9aBBALv1XMEox+M9Q3jCtNjfem7wZyvBPAWIMWFPzZRT/ Bd5A== X-Gm-Message-State: AO0yUKV+2htdbdE9blj24N1H/jDd3J1V+qXhgpCd0fTOMOzWFrmvJgy2 qcrnqHI/chXaVw3/4coZbrtsiw== X-Google-Smtp-Source: AK7set82EVT6qAWOMs7UHodk557+mxhNz3qM85ri7lrGhnXrY20LJRqZ9w9mYPYVIvADZLnUH7oe+A== X-Received: by 2002:a17:903:2644:b0:189:b910:c6d2 with SMTP id je4-20020a170903264400b00189b910c6d2mr169346plb.1.1674575692495; Tue, 24 Jan 2023 07:54:52 -0800 (PST) Received: from google.com (220.181.82.34.bc.googleusercontent.com. [34.82.181.220]) by smtp.gmail.com with ESMTPSA id ja5-20020a170902efc500b001930b189b32sm1816858plb.189.2023.01.24.07.54.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Jan 2023 07:54:51 -0800 (PST) Date: Tue, 24 Jan 2023 07:54:48 -0800 From: Ricardo Koller To: David Matlack Cc: Ben Gardon , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Paolo Bonzini , Peter Xu , Sean Christopherson , Vipin Sharma Subject: Re: [PATCH 2/2] selftests: KVM: Add page splitting test Message-ID: References: <20230119212510.3938454-1-bgardon@google.com> <20230119212510.3938454-3-bgardon@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 23, 2023 at 10:41:18AM -0800, David Matlack wrote: > On Fri, Jan 20, 2023 at 12:04:04PM -0800, Ben Gardon wrote: > > On Fri, Jan 20, 2023 at 6:34 AM Ricardo Koller wrote: > > > > > ... > > > > > > > + > > > > > > > + run_test(&p); > > > > > > > > > > > > Use for_each_guest_mode() to run against all supported guest modes. > > > > > > > > > > I'm not sure that would actually improve coverage. None of the page > > > > > splitting behavior depends on the mode AFAICT. > > > > > > > > You need to use for_each_guest_mode() for the ARM case. The issue is > > > > that whatever mode (guest page size and VA size) you pick might not be > > > > supported by the host. So, you first to explore what's available (via > > > > for_each_guest_mode()). > > > > > > Actually, that's fixed by using the default mode, which picks the > > > first available > > > mode. I would prefer to use for_each_guest_mode() though, who knows and > > > something fails with some specific guest page size for some reason. > > > > Okay, will do. I wasn't sure if we did eager page splitting on ARM, so > > Ricardo is in the process of upstreaming eager page splitting for ARM: > > https://lore.kernel.org/kvm/20230113035000.480021-1-ricarkol@google.com/ > > > I was only planning on making this test for x86_64 initially, hence it > > being in that directory. If ARM rolls with the same behavior, then > > I'll add the for_each_mode bit and move the test up a directory. > > In addition to for_each_guest_mode(), KVM/ARM will need to expose page > size stats so the test can verify the splitting (yet another reason to > have a common MMU). > > Ricardo, if you're interested in adding page size stats to KVM/ARM ahead > of the Common MMU, e.g. to test eager page splitting, let me know. Sure, I can do that. Sounds pretty useful too. > I > want to make sure we align on the userspace-visible stat names to avoid > churn down the road. Specifically, do we want to expose neutral names > like pages_{pte,pmd,pud} or expand the KVM/x86 list to include all of > ARM's possible pages sizes like pages_{4k,16k,64k,...} (or both)? I would prefer the latter, mainly to match the x86 names: + stats->pages_4k = vm_get_stat(vm, "pages_4k"); + stats->pages_2m = vm_get_stat(vm, "pages_2m"); + stats->pages_1g = vm_get_stat(vm, "pages_1g"); (from this patch) but pages_{pte,pmd,pud} would certainly make this test simpler as it would handle all guest page sizes: + stats->pages_pte = vm_get_stat(vm, "pages_pte");