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 83F66C433EF for ; Mon, 22 Nov 2021 18:47:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240405AbhKVSuP (ORCPT ); Mon, 22 Nov 2021 13:50:15 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48826 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240108AbhKVSuK (ORCPT ); Mon, 22 Nov 2021 13:50:10 -0500 Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8CABDC061714 for ; Mon, 22 Nov 2021 10:47:03 -0800 (PST) Received: by mail-pf1-x42a.google.com with SMTP id o4so16950695pfp.13 for ; Mon, 22 Nov 2021 10:47:03 -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=PNl9qmCVto3KUe1CsXAVRN/v/7RApWzP2E7VF0W9lc8=; b=rVBvrXjxLAb1n/5LtIOr1nVP8HuXbXe7TAcAsYR2OuZ+ADxNq5z8iCPGFd1r/7ePgZ 3MTur8u/7ePJ+HDVUss72WdlYPR2bXKoW7sPDwhq5H76TfmQ/TlxNFThnc+4FaBKSMgG BuhLBrXTI6DPG4HjeplQPNBoOa8bqspIvGeswwF7kMyXWmZOBBM8i+YweXXbY1I+X9RQ Y9gROaYeWbnkAZvslmsXcUm0tn5gPfmuiGOtJn/pjdIleRpwiRAk6MLQYLZRGhRT5/JM GrZFzdffyDr8u1pWw2Xf2kwwObj4YL1HiiGsxXQQwlgNooS6ehzLGScw6QygVBgUYalh ezTg== 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=PNl9qmCVto3KUe1CsXAVRN/v/7RApWzP2E7VF0W9lc8=; b=3KdHERsPhH18OmCmPkvzvk7jPtty4Ip47B8UfvQAEkWZ8GU4LyyCX4nR9ntzMRk/rq fYJ0qNItZyXkK9cOKiGl2DLQVG8pGE+QN2ZCTShikDmDWS+WEViLPrd6AU3L9eaGJoEQ zIS7RUS3aNXAig6BJCnYrWrP12QybRnq1qbTzYJSKxvTa+HyPkBTOo7M6TBabdR2+xfT l4R2z8FsDFIfp2hhaURAau+2WVIEbIb+fI2VC3fOnBhdqRin2o1O8Khl0au3fvTHJKf0 u/M17j1k/R35DCVYXQNV1+DS+ys6YnLUnODPdMqo5ePDCuRrHbwg344arafrMAFZgLkD sUdw== X-Gm-Message-State: AOAM5320cflCgUcezvMOkFVHwtjE4w6kEsWLKO1UYpZkI1JyLZ+lukp7 kPUbUV/P9tS7OlB+KT52H2kJOg== X-Google-Smtp-Source: ABdhPJyFEL+xAkz6QQ0tjJRGP5U11T9ZqMvExyunio/Erp2Cdyi/pMCfKbuWHOvUD3yEk3Iicj2hvA== X-Received: by 2002:a05:6a00:244d:b0:44d:c279:5155 with SMTP id d13-20020a056a00244d00b0044dc2795155mr45388090pfj.0.1637606822880; Mon, 22 Nov 2021 10:47:02 -0800 (PST) Received: from google.com (157.214.185.35.bc.googleusercontent.com. [35.185.214.157]) by smtp.gmail.com with ESMTPSA id c21sm9978151pfl.138.2021.11.22.10.47.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Nov 2021 10:47:02 -0800 (PST) Date: Mon, 22 Nov 2021 18:46:58 +0000 From: Sean Christopherson To: Ben Gardon Cc: Paolo Bonzini , linux-kernel@vger.kernel.org, kvm@vger.kernel.org, Peter Xu , Peter Shier , David Matlack , Mingwei Zhang , Yulei Zhang , Wanpeng Li , Xiao Guangrong , Kai Huang , Keqian Zhu , David Hildenbrand Subject: Re: [PATCH 11/15] KVM: x86/MMU: Refactor vmx_get_mt_mask Message-ID: References: <20211115234603.2908381-1-bgardon@google.com> <20211115234603.2908381-12-bgardon@google.com> <942d487e-ba6b-9c60-e200-3590524137b9@redhat.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, Nov 22, 2021, Ben Gardon wrote: > On Fri, Nov 19, 2021 at 1:03 AM Paolo Bonzini wrote: > > > > On 11/18/21 16:30, Sean Christopherson wrote: > > > If we really want to make this state per-vCPU, KVM would need to incorporate the > > > CR0.CD and MTRR settings in kvm_mmu_page_role. For MTRRs in particular, the worst > > > case scenario is that every vCPU has different MTRR settings, which means that > > > kvm_mmu_page_role would need to be expanded by 10 bits in order to track every > > > possible vcpu_idx (currently capped at 1024). > > > > Yes, that's insanity. I was also a bit skeptical about Ben's try_get_mt_mask callback, > > but this would be much much worse. > > Yeah, the implementation of that felt a bit kludgy to me too, but > refactoring the handling of all those CR bits was way more complex > than I wanted to handle in this patch set. > I'd love to see some of those CR0 / MTRR settings be set on a VM basis > and enforced as uniform across vCPUs. Architecturally, we can't do that. Even a perfectly well-behaved guest will have (small) periods where the BSP has different settings than APs. And it's technically legal to have non-uniform MTRR and CR0.CD/NW configurations, even though no modern BIOS/kernel does that. Except for non-coherent DMA, it's a moot point because KVM can simply ignore guest cacheability settings. > Looking up vCPU 0 and basing things on that feels extra hacky though, > especially if we're still not asserting uniformity of settings across > vCPUs. IMO, it's marginally less hacky than what KVM has today as it allows KVM's behavior to be clearly and sanely stated, e.g. KVM uses vCPU0's cacheability settings when mapping non-coherent DMA. Compare that with today's behavior where the cacheability settings depend on which vCPU first faulted in the address for a given MMU role and instance of the associated root, and whether other vCPUs share an MMU role/root. > If we need to track that state to accurately virtualize the hardware > though, that would be unfortunate.