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 A7059C433FE for ; Wed, 5 Jan 2022 16:45:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S242003AbiAEQpr (ORCPT ); Wed, 5 Jan 2022 11:45:47 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45310 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235747AbiAEQpp (ORCPT ); Wed, 5 Jan 2022 11:45:45 -0500 Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 36FAFC061245 for ; Wed, 5 Jan 2022 08:45:45 -0800 (PST) Received: by mail-pj1-x1035.google.com with SMTP id a11-20020a17090a854b00b001b11aae38d6so6806742pjw.2 for ; Wed, 05 Jan 2022 08:45:45 -0800 (PST) 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=JzhaTzKc19y3Wpdk/3J2jH8xYo/xM6G6LVHFT+aj3mw=; b=aLR3XPzMRrTZJboycEOPjD3N3ADRjWxJrADrUM1vAgyD9yRB/cjUqNuxpD6D1zOAmh OTlxK6M59BBTMdKbHLb9g6+g7lOOh6VZ4/qDWuPwogwqXeIz//BWdDMmse71XKun02Lu G04xPe73oSZqxQ/sy9Lj5nEW4XoOHJ/pcEv6sVHzjo/DrPyZjd3XxDfC4rApX5sJJNuM 7NKta/ZTK/r2ZYTqrHgT17CPS9TWRex9/ZhxhmcmEHTpTUtPhnpmYSK9l7CEiPZWu2xz o+vWlB3XVpmKTtJuS6YG2Z7qNp9iowJUszGZWjwe44ltq3lZukQ4WbMgvfWWg0n7//yf aZsg== 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=JzhaTzKc19y3Wpdk/3J2jH8xYo/xM6G6LVHFT+aj3mw=; b=PdVJeLhRS71fDZ1NeRD9CzPbncMzeqAL0E2ufucbr4qXT3l4SDWiJ53YnUay4/kpvC TPneYculTjAOwaWMPmsMHFGGMlIZewCWzGBWBn1Fv8YRDDpN4JK5W06qARE0yZRsnr6B nGw0HoGFBgXRf+xP+TYI/dnWQ1iljoXoKYi4ZE+xJ1jCtSd4wmVSIFKN5LrKV4YV7Ove VztKUDiJbWURbl+uKntP/DX+gIPTJy6QgmwvTjpavVEpH3JMVkUKS3GxLZGs+ieD9ZX5 firhC4vsQfoccPVmW53R/92SCmyzppYliTJzc+ODE/s5CiZwuacUNZJ2JhSfeT0ejh0w fPKw== X-Gm-Message-State: AOAM531AxYdbc5plI0R4ZPS0uh1oM0APL5zqNRP4OF3XX08GCV3x2+s2 N/UcyEJq1XDo3AGevmq53cWIdw== X-Google-Smtp-Source: ABdhPJyUMGeECuuJZDVhCnWrGj1J1NoGFjgCRrQnkt+A+rXmyUORqD/IbRnzmnd1id6Y/amClQGp1Q== X-Received: by 2002:a17:903:11c9:b0:149:bef4:2d7d with SMTP id q9-20020a17090311c900b00149bef42d7dmr13255819plh.48.1641401144538; Wed, 05 Jan 2022 08:45:44 -0800 (PST) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id m14sm48537966pfk.3.2022.01.05.08.45.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Jan 2022 08:45:43 -0800 (PST) Date: Wed, 5 Jan 2022 16:45:40 +0000 From: Sean Christopherson To: Lai Jiangshan Cc: LKML , kvm@vger.kernel.org, Paolo Bonzini , Lai Jiangshan , Vitaly Kuznetsov , Wanpeng Li , Jim Mattson , Joerg Roedel , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , X86 ML , "H. Peter Anvin" Subject: Re: [RFC PATCH 5/6] KVM: X86: Alloc pae_root shadow page Message-ID: References: <20211210092508.7185-1-jiangshanlai@gmail.com> <20211210092508.7185-6-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-kernel@vger.kernel.org On Wed, Jan 05, 2022, Lai Jiangshan wrote: > On Wed, Jan 5, 2022 at 5:54 AM Sean Christopherson wrote: > > > > > > > default_pae_pdpte is needed because the cpu expect PAE pdptes are > > > present when VMenter. > > > > That's incorrect. Neither Intel nor AMD require PDPTEs to be present. Not present > > is perfectly ok, present with reserved bits is what's not allowed. > > > > Intel SDM: > > A VM entry that checks the validity of the PDPTEs uses the same checks that are > > used when CR3 is loaded with MOV to CR3 when PAE paging is in use[7]. If MOV to CR3 > > would cause a general-protection exception due to the PDPTEs that would be loaded > > (e.g., because a reserved bit is set), the VM entry fails. > > > > 7. This implies that (1) bits 11:9 in each PDPTE are ignored; and (2) if bit 0 > > (present) is clear in one of the PDPTEs, bits 63:1 of that PDPTE are ignored. > > But in practice, the VM entry fails if the present bit is not set in the > PDPTE for the linear address being accessed (when EPT enabled at least). The > host kvm complains and dumps the vmcs state. That doesn't make any sense. If EPT is enabled, KVM should never use a pae_root. The vmcs.GUEST_PDPTRn fields are in play, but those shouldn't derive from KVM's shadow page tables. And I doubt there is a VMX ucode bug at play, as KVM currently uses '0' in its shadow page tables for not-present PDPTEs. If you can post/provide the patches that lead to VM-Fail, I'd be happy to help debug.