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 833EFC05027 for ; Mon, 23 Jan 2023 18:41:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232385AbjAWSl0 (ORCPT ); Mon, 23 Jan 2023 13:41:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51832 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230109AbjAWSlZ (ORCPT ); Mon, 23 Jan 2023 13:41:25 -0500 Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 300622310A for ; Mon, 23 Jan 2023 10:41:23 -0800 (PST) Received: by mail-pj1-x102f.google.com with SMTP id z9-20020a17090a468900b00226b6e7aeeaso11840846pjf.1 for ; Mon, 23 Jan 2023 10:41:23 -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=bmlRiT9KV+phAJhVbeU2MK7l26rsSidNpPrjEHuIhmw=; b=htX2k/N3Q9Wdfoocx7NEDGxZpBehW/5iUVrl5uYUJh08puTE7YWTggNTfbdMnxB8JB FL92QmLqtlrtzNwy/W149aKppxG8JL91n7TwQVQdeok9bKI+qX3tPjGarm1QNwxEM9tH Qmsmkdn4PMu+hAnE9r6lWc27wqPsyXUWMo3rbIkWRFTOQViao8kI2ypjfISzGEcb+O1U gtmay3w2tB8EuzVEvx1yZAxa9ZIC0tteNpzup9T8YtSOJuSWxVmXerdA0bq7qX6u8kIB 2v/Pf+JaFHk7UZN7cd0gleQp2hydDJfowBGjSd2QGPBOpollcG2bNidf3R7HSQUIvpWF bAZg== 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=bmlRiT9KV+phAJhVbeU2MK7l26rsSidNpPrjEHuIhmw=; b=zqd4ruTIK2lt4X/aD2HoD94i2j2MbZCoKlbFRQN+TfMlFa+daEHaJAl+6CyuAuVhEE C72AE1rvbeM5PA9q5KiDVF2dBaIYeZbDLAXoe6mCbay4SlNEeo7Z7liGvQIZoPYtIi+5 NfkgBBsSuk6Z6Tm6n/uqEiVuMW+YoKrVBSk9RZL9qHkTJJEYLwqCNynEtvbUf0EcYCli Lfhs7inO3jsBtg0nVl6s7zc4zm+GEKu+udaDUsRKahIquX1xr1dXz70LN3DQVMSXUf28 RqHGzywDQ7Uy1dUFBICK6O3KxXq+SoFXCN+nl246qxhzktIE5HGhKXR5w5SluzxACYbj crTg== X-Gm-Message-State: AFqh2kpN3iCsXOnXT7yCrLXkj5U4Oalb5DxGbwuY1bPkYwYCKvgFXDzX /PlJLrziYXA1utccGvlMJEUfnQ== X-Google-Smtp-Source: AMrXdXsKHGfJWy80MXupDdl+PNc1DsrR21pZYoWODp7mUxRldE/jy2FgcvWo7ARk95ZkzK7Q6LNqPQ== X-Received: by 2002:a17:903:286:b0:192:751c:6e8d with SMTP id j6-20020a170903028600b00192751c6e8dmr25676883plr.58.1674499282518; Mon, 23 Jan 2023 10:41:22 -0800 (PST) Received: from google.com (223.103.125.34.bc.googleusercontent.com. [34.125.103.223]) by smtp.gmail.com with ESMTPSA id w4-20020a1709029a8400b001947738ec7fsm20482plp.158.2023.01.23.10.41.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 23 Jan 2023 10:41:22 -0800 (PST) Date: Mon, 23 Jan 2023 10:41:18 -0800 From: David Matlack To: Ben Gardon Cc: Ricardo Koller , 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: kvm@vger.kernel.org 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. 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)?