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 CE8FDC433EF for ; Wed, 13 Apr 2022 14:42:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236222AbiDMOpB (ORCPT ); Wed, 13 Apr 2022 10:45:01 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34588 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236226AbiDMOpA (ORCPT ); Wed, 13 Apr 2022 10:45:00 -0400 Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 775F362C8F for ; Wed, 13 Apr 2022 07:42:35 -0700 (PDT) Received: by mail-pf1-x431.google.com with SMTP id n22so1857330pfa.0 for ; Wed, 13 Apr 2022 07:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=/JYEDIWYyCmXfCvpDqWCkJLdtO8UQhf0VFm9gLSvtws=; b=pceu2zUDQVxybZHIpx8ZRmoZzDQIwrGKZgmWOMMzB7VAntXi50Pl0f8pqyxIEWPI+5 pL8meqwPaGS963019NumUkybXx5CAsYMfc9veKm5KQ+oJV7CHLpP0E2YE2ceNlg24Awv Xiemy6d/d+QzFJP4AyTUBvn9E10N6yw7xHZAlMF5b+RdO7301qDFVWFwUPYHcOEZEQst hdyDSfjQBEYHj3aM7s6VfQjTsXUs7pBHuWqIWAdpu45F1CvjpGaMW4cUXBfpwME0fQNW ATa+Av8J7FZi20cBDzMQDd2QAB2m/kLbg2cdN+dvirzLbuU7eYsx1Ld8zBtlLaLNLR02 zZ9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=/JYEDIWYyCmXfCvpDqWCkJLdtO8UQhf0VFm9gLSvtws=; b=6Camu+zz4REdjYnOdRkgUW2LRBq2H/6SswzTkzn9T7BhwiumYNPUghElSTKaf4WNeG skx9xS7QAAF97rkpsglCbRBz1jDxE+RgEkMkIiY7MknjBMmKag9OpWx/U+p4DKhxMwEg vki8yz9qneXmWoAwkYamG7jc6EnJRtLITOG8sBj3l0FeQTXIhgC/t5d+y9/6i35DmsYy Uzr7rA8bTqdux3vkHOLN1qStVK+kbBdo1sGT8VJZy6FDlzlofqkvP1/48zs+cjrzb4AG +z5QeyV/nGz7ykG2C6O/7Jpd80N4WDyaL1aENd/GrUqC3x7llNDJPMc0f7w4PetUJy2f 1vNA== X-Gm-Message-State: AOAM5329OsUJ4cGuXeGQYm5cQNediy7ihRWXSw8vwhBw5e0MuT1PIwPO NcVjmW0tKtD5cOltL/xaDkjSww== X-Google-Smtp-Source: ABdhPJyND0vLloxs8A3tKDdJhHhujGT9+mvw3w0rxORb0WCXA5Nj8ZZclC8so/j+m0ds/Ow5E6mDWg== X-Received: by 2002:a63:1024:0:b0:39d:1172:b8e0 with SMTP id f36-20020a631024000000b0039d1172b8e0mr20123646pgl.423.1649860954468; Wed, 13 Apr 2022 07:42:34 -0700 (PDT) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id i15-20020a17090a058f00b001cd50a6ec5csm2934080pji.16.2022.04.13.07.42.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Apr 2022 07:42:33 -0700 (PDT) Date: Wed, 13 Apr 2022 14:42:30 +0000 From: Sean Christopherson To: Paolo Bonzini Cc: Lai Jiangshan , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Lai Jiangshan , Jonathan Corbet , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , linux-doc@vger.kernel.org Subject: Re: [RFC PATCH V3 2/4] KVM: X86: Introduce role.glevel for level expanded pagetable Message-ID: References: <20220330132152.4568-1-jiangshanlai@gmail.com> <20220330132152.4568-3-jiangshanlai@gmail.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-doc@vger.kernel.org On Wed, Apr 13, 2022, Paolo Bonzini wrote: > On 4/12/22 23:31, Sean Christopherson wrote: > > > + unsigned glevel:4; > > We don't need 4 bits for this. Crossing our fingers that we never had to shadow > > a 2-level guest with a 6-level host, we can do: > > > > unsigned passthrough_delta:2; > > > > Where the field is ignored if direct=1, '0' for non-passthrough, and 1-3 to handle > > shadow_root_level - guest_root_level. Basically the same idea as Paolo's smushing > > of direct+passthrough into mapping_level, just dressed up differently. > > Basically, your passthrough_delta is level - glevel in Jiangshan's patches. > You'll need 3 bits anyway when we remove direct later (that would be > passthrough_delta == level). Are we planning on removing direct? > Regarding the naming: > > * If we keep Jiangshan's logic, I don't like the glevel name very much, any > of mapping_level, target_level or direct_level would be clearer? I don't love any of these names, especially glevel, because the field doesn't strictly track the guest/mapping/target/direct level. That could obviously be remedied by making it valid at all times, but then the role would truly need 3 bits (on top of direct) to track 5-level guest paging. > * If we go with yours, I would call the field "passthrough_levels". Hmm, it's not a raw level though.