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 71712C43217 for ; Mon, 28 Nov 2022 23:49:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234786AbiK1Xt1 (ORCPT ); Mon, 28 Nov 2022 18:49:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60050 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234725AbiK1XtZ (ORCPT ); Mon, 28 Nov 2022 18:49:25 -0500 Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6D63C28727 for ; Mon, 28 Nov 2022 15:49:23 -0800 (PST) Received: by mail-pj1-x1034.google.com with SMTP id o5-20020a17090a678500b00218cd5a21c9so11683985pjj.4 for ; Mon, 28 Nov 2022 15:49: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=58wLbXZQqSCYCg7xOlR8lAwt7cU3HWV7an3QPAF/aSM=; b=V4B8cV49OnyUFCKxirfutkS1FWLot5o98FEE7gocZSgtTylMRh9bB7f8k4+7V/+IEw b21NSnkAfwsPcR8rSgl1q/PM9RoO2MnnEiEeoCfk6sPvXAQwc0N6U/tj2NJqLXuP+q6/ hFGjUTeJNjHe7m9UAMZChUNJ+6NXq4ql9YSG3TqWDCbZNheTVZk1s0JGgeQS/DW4buyg 5Ey0SXZadlvtR0rWaiehRDUGXxFhJUcgwPK/fjPe0U7x4n2IznvCPNLnod84A2GcCjeK HN+WDTghUgmMlGA115HAIuUXMJKIGeMl0xf9kf1X3OqToZ5qdcGIpxOMZzlvEbuW3+iH DJNg== 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=58wLbXZQqSCYCg7xOlR8lAwt7cU3HWV7an3QPAF/aSM=; b=G9+AEJfPSy9jZ/vw5EdAgU1wPLgnUvBR2OP1dYQqvoDPB6ZoSSMzc4U9FR9hjaE+Zc qsBMkSlob5N7N57+PIEZij0ZQC4BBOUuEEAU635774e2zFxVZ5N5Q2j78MkUfiCjTQ7Q q8ueGbAJVEguFSkg6skgigVGH5A+Pe3JEdz/mXYvW6NXPixZkZY18X+Y8VkbbaNxDjFA Tt0a3FyrUZ3NPTWQd0SlRH3cuacQKF+xy3vmETmvjaR+4D9y4xhbBlOcyiJsiuQkBiYx 5Yp6A/SXFoEktp+tg8hCUkjEfFOrJnDWMqel/lo2EeqtyjFmq7PF63JLfjcFmzxGoH8d RXkw== X-Gm-Message-State: ANoB5plFv6LCGh8tfafh/VwLmoOdsmzDFv1E5wes7Cjov/3JorNDMgu/ SUXegZ3Y7CBS73D7US9g8IxtQQ== X-Google-Smtp-Source: AA0mqf4VO9eAEZiHJ6+DrNZcAiIfTkyyefhpiaHEGVgY/dey2gslJzVQcjvIR8D5DhPM7ImWl0knIQ== X-Received: by 2002:a17:902:bb84:b0:184:e4db:e3e with SMTP id m4-20020a170902bb8400b00184e4db0e3emr38177995pls.47.1669679362812; Mon, 28 Nov 2022 15:49:22 -0800 (PST) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id x23-20020a170902b41700b001890cbd1ff1sm9376946plr.149.2022.11.28.15.49.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Nov 2022 15:49:22 -0800 (PST) Date: Mon, 28 Nov 2022 23:49:19 +0000 From: Sean Christopherson To: Yan Zhao Cc: "Huang, Kai" , "kvm@vger.kernel.org" , "Shahar, Sagi" , "isaku.yamahata@gmail.com" , "linux-kernel@vger.kernel.org" , "Aktas, Erdem" , "sean.j.christopherson@intel.com" , "dmatlack@google.com" , "Yamahata, Isaku" , "pbonzini@redhat.com" Subject: Re: [PATCH v10 035/108] KVM: x86/mmu: Track shadow MMIO value on a per-VM basis Message-ID: References: <887a77acc9bf96f7c7bea519ab7ebdd27fb67985.camel@intel.com> <8e14a7732a2d873846d07c4ec467fb7c48b2307f.camel@intel.com> <1ad20facd81dd346e00ff686ae4a0550123de851.camel@intel.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 Fri, Nov 25, 2022, Yan Zhao wrote: > On Fri, Nov 25, 2022 at 09:07:09AM +0800, Huang, Kai wrote: > > On Fri, 2022-11-25 at 08:37 +0800, Yan Zhao wrote: > > > On Fri, Nov 25, 2022 at 08:45:01AM +0800, Huang, Kai wrote: > > > > On Fri, 2022-11-25 at 08:12 +0800, Yan Zhao wrote: > > > > > On Fri, Nov 25, 2022 at 08:13:48AM +0800, Huang, Kai wrote: > > > > > > On Tue, 2022-11-22 at 10:10 +0800, Yan Zhao wrote: > > > > > > > Also make enable_mmio_caching to be a per-VM value? > > > > > > > As if the shadow_mmio_value is 0, mmio_caching needs to be disabled. > > > > > > > > > > > > If I recall correctly, Sean said we can disable TDX guests if mmio_caching is > > > > > > disabled (we also will need to change to allow enable_mmio_caching to still be > > > > > > true when mmio_value is 0). > > > > > > > > > > > > SEV_ES has similar logic: > > > > > > > > > > > > void __init sev_hardware_setup(void) > > > > > > { > > > > > > > > > > > > ... > > > > > > > > > > > > /* > > > > > > * SEV-ES requires MMIO caching as KVM doesn't have access to the guest > > > > > > * instruction stream, i.e. can't emulate in response to a #NPF and > > > > > > * instead relies on #NPF(RSVD) being reflected into the guest as #VC > > > > > > * (the guest can then do a #VMGEXIT to request MMIO emulation). > > > > > > */ > > > > > > if (!enable_mmio_caching) > > > > > > goto out; > > > > > > > > > > > > > > > > Would enabling mmio caching in per-VM basis be better? > > > > > > > > > > > > > We need Paolo/Sean to decide. > > > > > > > > The thing is TDX guests always require mmio_caching being enabled. For VMX > > > > guests, normally we will always enable mmio_caching too. So I think per-VM > > > > basis mmio_caching is not that useful. > > > With per-VM basis enabling, I think we can get rid of the kvm_gfn_shared_mask(kvm) > > > in below code and also in handle_abnormal_pfn() > > > > > > static inline bool is_mmio_spte(struct kvm *kvm, u64 spte) > > > { > > > return (spte & shadow_mmio_mask) == kvm->arch.shadow_mmio_value && > > > likely(enable_mmio_caching || kvm_gfn_shared_mask(kvm)); > > > } > > > > > > > It needs to go anyway regardless per-VM mmio_caching or not, as explained we > > need to change to allow enable_mmio_caching to be true even mmio_value is 0. Yes, the kvm_gfn_shared_mask() in is_mmio_spte() should not exist. > Or it's better to check enable_mmio_caching is true in > kvm_mmu_set_mmio_spte_value() as below. > > void kvm_mmu_set_mmio_spte_value(struct kvm *kvm, u64 mmio_value) > { > WARN_ON(!enable_mmio_caching); > kvm->arch.shadow_mmio_value = mmio_value; Eh, if you're going to bother with that assert, capture the more subtle aspects as well, e.g. that EPT is enabled and that shadow_mmio_mask has been set to the expected value. I would also ditch the helper and just open code this in TDX code, I doubt there's a use case outside of TDX+VMX coexistence.