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 8C942C77B7D for ; Mon, 15 May 2023 18:00:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S244267AbjEOSAg (ORCPT ); Mon, 15 May 2023 14:00:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60752 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245108AbjEOSAG (ORCPT ); Mon, 15 May 2023 14:00:06 -0400 Received: from mail-yb1-xb49.google.com (mail-yb1-xb49.google.com [IPv6:2607:f8b0:4864:20::b49]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id BAD521BB93 for ; Mon, 15 May 2023 10:57:22 -0700 (PDT) Received: by mail-yb1-xb49.google.com with SMTP id 3f1490d57ef6-ba7831dfe95so4241169276.2 for ; Mon, 15 May 2023 10:57:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1684173429; x=1686765429; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=99srR1wR+oKvE5/WokGr4LZs8iI5brQIGfN7GCM4UrE=; b=qgBmAUsdMhWoFgdfIMBysrOMi/gESv0r34Xoj0igegtNAqMmPuZYSN8teIqqNTO4qr +o9xeOyk9osBGJxQbQuznSPE37lto98WL25ntsbJrltXSslcw1N9UwCjtAleA783eS5O 9YwANM1uEr3ANtlR1gIiXFGuiQX6HZHez7Az1JmZfWcgZ8XXRvwsKlQVSp1qYogeiohP HZiUVEoNqJwtMnWDAcgFy21hoDfY46Zz54Xrc7sGdVcVXFt7SRAKBWqGimi1IwSKlxe6 LTURlyPrfkfy2KvuKglvcB3GJiMGve4uIMdIImYsP6Uo1qtixcy8iwFrsPFnos8ejlvp S2tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684173429; x=1686765429; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=99srR1wR+oKvE5/WokGr4LZs8iI5brQIGfN7GCM4UrE=; b=gNzRRJQE7oXrvJ6uEoDvPKyrABNKJZQNxweiHa9DMeKVIP9S+GU75hOrXXKFv34aTr 1FEF9vrmXfdBkkLP5NUyYSgf0RMPrjqN0g+0E2DuuHrzp+eTaHP40Iddmpyl7VdmYqxe S5krAzMrQtLTJ1uic9yMFotx5f4JjrJfrvTBa/PHqS86NBro84cRVIWFCWcVDmJ1C+XK CtVcSdLewi9Mm3s01fcDnhGJ8E3Pgq/cYhqaZTMpCAMzBrxCMbNZtGuvz68gvzy4o6SV i4WKDgP2PFwZSi6dlagB5N+aA2G9etiZ+fYHBFn7XIzX52yfoDHg1EuUwJv9MUi725jN w1Yw== X-Gm-Message-State: AC+VfDxO+VtPhpAyjU84aQwprpnbgE/gc3jV2YDvfPIGzMXcOacP3sK6 FhxSj5yrZ6T+BrX62hn0OT5cdU0z2dA= X-Google-Smtp-Source: ACHHUZ4He0csQ4Oev4VXrHXbI7rX8wyUIkfOSTVuja6DxDI6qDgf1L+qcXE8dfIu5YKaWZQqJrs9xqp4fJ0= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a25:5454:0:b0:ba2:1a28:c852 with SMTP id i81-20020a255454000000b00ba21a28c852mr14179279ybb.7.1684173429090; Mon, 15 May 2023 10:57:09 -0700 (PDT) Date: Mon, 15 May 2023 10:57:07 -0700 In-Reply-To: <66685365-86f9-9ddf-d63b-f87621b05b88@intel.com> Mime-Version: 1.0 References: <20230513003600.818142-1-seanjc@google.com> <20230513003600.818142-6-seanjc@google.com> <66685365-86f9-9ddf-d63b-f87621b05b88@intel.com> Message-ID: Subject: Re: [PATCH v3 05/28] drm/i915/gvt: Explicitly check that vGPU is attached before shadowing From: Sean Christopherson To: Zhi A Wang Cc: Paolo Bonzini , Zhenyu Wang , "kvm@vger.kernel.org" , "intel-gvt-dev@lists.freedesktop.org" , "intel-gfx@lists.freedesktop.org" , "linux-kernel@vger.kernel.org" , Yan Y Zhao , Ben Gardon Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 15, 2023, Zhi A Wang wrote: > On 5/13/2023 8:35 AM, Sean Christopherson wrote: > > Move the check that a vGPU is attacked from is_2MB_gtt_possible() to its > > sole caller, ppgtt_populate_shadow_entry(). All of the paths in > > ppgtt_populate_shadow_entry() eventually check for attachment by way of > > intel_gvt_dma_map_guest_page(), but explicitly checking can avoid > > unnecessary work and will make it more obvious that a future cleanup of > > is_2MB_gtt_possible() isn't introducing a bug. > > > > It might be better move this check to shadow_ppgtt_mm() which is used > in both shadow page table creation and pinning path so that the path > can bail out even earlier when creating a shadow page table but a vGPU > has not been attached to KVM yet. Ah, yes, that'll work. I traced through all of the paths that lead to ppgtt_populate_shadow_entry(), and shadow_ppgtt_mm() is the only caller that isn't already gated by INTEL_VGPU_STATUS_ATTACHED or INTEL_VGPU_STATUS_ACTIVE (ACTIVE is set iff ATTACHED is set). I'll move the check up to shadow_ppgtt_mm() in the next version. Thanks! workload_thread() <= pick_next_workload() => INTEL_VGPU_STATUS_ACTIVE | -> dispatch_workload() | |-> prepare_workload() | -> intel_vgpu_sync_oos_pages() | | | |-> ppgtt_set_guest_page_sync() | | | |-> sync_oos_page() | | | |-> ppgtt_populate_shadow_entry() | |-> intel_vgpu_flush_post_shadow() | 1: |-> ppgtt_handle_guest_write_page_table() | |-> ppgtt_handle_guest_entry_add() | 2: | -> ppgtt_populate_spt_by_guest_entry() | | | |-> ppgtt_populate_spt() | | | |-> ppgtt_populate_shadow_entry() | | | |-> ppgtt_populate_spt_by_guest_entry() [see 2] | |-> ppgtt_populate_shadow_entry() kvmgt_page_track_write() <= KVM callback => INTEL_VGPU_STATUS_ATTACHED | |-> intel_vgpu_page_track_handler() | |-> ppgtt_write_protection_handler() | |-> ppgtt_handle_guest_write_page_table_bytes() | |-> ppgtt_handle_guest_write_page_table() [see 1]