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 00F21C4332F for ; Tue, 8 Mar 2022 17:49:19 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349272AbiCHRuP (ORCPT ); Tue, 8 Mar 2022 12:50:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43446 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349265AbiCHRuL (ORCPT ); Tue, 8 Mar 2022 12:50:11 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 8C8A048382 for ; Tue, 8 Mar 2022 09:49:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1646761753; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=6HssJmk+YZ6p3KAw12cX/6WW9ODnrbHQBJq5VfOnmOk=; b=M8vks5CaLxsmoMD+k71UgzlI24fiCifZEH1NGgSBw5v+KJpWmW9mD7juor+/Stb2UbpNDZ XPlzaESAy2GSKpojmNbKp5gCQnLNmUKf6W4Wc3Moxj3+jl2gU4awVWQJp/ecCGZUq9LBud ujk4dMoo2MRcnmFACOONz5ypItcNSNQ= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-644-LK35cJrUMMOv6P4bLhuliQ-1; Tue, 08 Mar 2022 12:49:12 -0500 X-MC-Unique: LK35cJrUMMOv6P4bLhuliQ-1 Received: by mail-wm1-f70.google.com with SMTP id n62-20020a1ca441000000b0038124c99ebcso6720803wme.9 for ; Tue, 08 Mar 2022 09:49:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=6HssJmk+YZ6p3KAw12cX/6WW9ODnrbHQBJq5VfOnmOk=; b=A7aZCq/wI284OtgdKgWIMgEvUDjGGoYwRzqqNtmgDWEYG/60Zcnwpcru0ccdbBI96X wrCkwu/W12uvnqTlWx5F4hTNvT1M/EKuolJyitV3b7RBPn7ZKspQoOOYU8sDH4OnjBqm 3ay6Fz9oUUiXk4jaBeQvNkk50yvDf1EFdjAAUM+2a2P8YNhdFseM5vYFKx13B3YsyXLf KzXyNtLtQ7Z6zyObv+2r3vT/X4TOOwJyGzdl3uwS5zatIkNNlqrYlG8WzYIR/RDv3ryy qHWHuw2XJXpKPvmBF+NGqsilYbu6tGO/GPebShAHsu0V86FJTO1HJMhhS/GQLj8Reld3 /f0A== X-Gm-Message-State: AOAM531GDdcHTS/Hi98eMlus58yIYhdbS+aGqviJpWniW9UqXehdYc5A EHXDBMLuW0Ab+ol6pXMtBslHwWuxOG1cVdj3uJWDwzI5qWwcIeIfbjiubI6JHd9fMU4fiG1qWSN kH5UkQvn9UlP0WZPZo2FGHvBT X-Received: by 2002:a05:600c:a03:b0:37b:daff:6146 with SMTP id z3-20020a05600c0a0300b0037bdaff6146mr4600294wmp.85.1646761751159; Tue, 08 Mar 2022 09:49:11 -0800 (PST) X-Google-Smtp-Source: ABdhPJzHay2ww/NrI60fjbzAjpBoqpJxLxm9gMCWFGESxLqfRu91mGDesTPJrGXCQD+c8V7kulwgjg== X-Received: by 2002:a05:600c:a03:b0:37b:daff:6146 with SMTP id z3-20020a05600c0a0300b0037bdaff6146mr4600269wmp.85.1646761750937; Tue, 08 Mar 2022 09:49:10 -0800 (PST) Received: from ?IPV6:2001:b07:6468:f312:c8dd:75d4:99ab:290a? ([2001:b07:6468:f312:c8dd:75d4:99ab:290a]) by smtp.googlemail.com with ESMTPSA id b15-20020adfc74f000000b001e888b871a0sm14724489wrh.87.2022.03.08.09.49.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 08 Mar 2022 09:49:10 -0800 (PST) Message-ID: <19e00429-a7e6-f4fd-41be-71afdce6b056@redhat.com> Date: Tue, 8 Mar 2022 18:49:09 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH v2 08/25] KVM: x86/mmu: split cpu_mode from mmu_role Content-Language: en-US To: Sean Christopherson Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, dmatlack@google.com References: <20220221162243.683208-1-pbonzini@redhat.com> <20220221162243.683208-9-pbonzini@redhat.com> From: Paolo Bonzini In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/8/22 18:36, Sean Christopherson wrote: > The idea was to trigger fireworks due to a incoherent state (e.g. direct mmu_role with > non-direct hooks) if the nested_mmu was ever used as a "real" MMU (handling faults, > installing SPs/SPTEs, etc...). For a walk-only MMU, "direct" has no meaning and so > rather than arbitrarily leave it '0', I arbitrarily set it '1'. > > Maybe this? > > The nested MMU now has only the CPU mode; and in fact the new function > kvm_calc_cpu_mode is analogous to the previous kvm_calc_nested_mmu_role, > except that it has role.base.direct equal to CR0.PG. Having "direct" > track CR0.PG has the serendipitious side effect of being an even better > sentinel than arbitrarily setting direct to true for the nested MMU, as > KVM will run afoul of sanity checks for both direct and indirect MMUs if > KVM attempts to use the nested MMU as a "real" MMU, e.g. for page faults. Hmm, actually it is set to CR0.PG *negated*, so that future patches can get rid of role.ext.cr0_pg. But really anybody trying to use nested_mmu for real would get NULL pointer dereferences left and right in all likelihood. This will be even clearer by the end of the series, when the function pointers are initialized at vCPU creation time. >> >> + role.base.direct = !____is_cr0_pg(regs); >> + if (!role.base.direct) { > > Can we check ____is_cr0_pg() instead of "direct"? IMO that's more intuitive for > understanding why the bits below are left zero. I was scratching my head trying > to figure out whether or not this was safe/correct for direct MMUs... Yes, that's good. Paolo