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 B0258C04A94 for ; Wed, 9 Aug 2023 14:33:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233397AbjHIOdt (ORCPT ); Wed, 9 Aug 2023 10:33:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53356 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233384AbjHIOdr (ORCPT ); Wed, 9 Aug 2023 10:33:47 -0400 Received: from mail-pl1-x649.google.com (mail-pl1-x649.google.com [IPv6:2607:f8b0:4864:20::649]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2DE4BEE for ; Wed, 9 Aug 2023 07:33:47 -0700 (PDT) Received: by mail-pl1-x649.google.com with SMTP id d9443c01a7336-1bbb34b0abaso88665505ad.1 for ; Wed, 09 Aug 2023 07:33:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1691591626; x=1692196426; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=jZmbaKKKm3CHbI/QJJpHHXp/km2ij6zusR5ThdOY8EE=; b=DUi7yCKZeHIQOn9Fthn5OjHUhJCT5ipdMgkg2xVzFQPT+Dno1JgMSzuaGqJnec7h2e k+Z7kpr+D6ku5ye4Y6Eo7mDbKoNBW9n6UpATdPMSt2qu7OS+JRrwoR8Bnl03vE6oqRed IdDFcMCZspBAGdgCY0gFnYb8aKK0+wCIjcoCRQhWqa5loj4vewG+g6iwkycBJQSMkLjj F3MgG8WkunnGIX9Tntelx5mF9rV8NItN1nwrgI3NHer6l3ddA7FkQSXwfAflMybwce6F EdaQfPWL6IZPj1YAXH1asOjn4XATl8RQIyRiPv89SVJFee5ERZGSewxIkqk4Plzps/v2 kuwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691591626; x=1692196426; 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=jZmbaKKKm3CHbI/QJJpHHXp/km2ij6zusR5ThdOY8EE=; b=IvPU+7CVApxw+HHk6Mtslmjm0At21GXTqMk6XNa+Qk3cb738uwWr9pGpNfZsQcCMsm pMZmvlyjacJXeo8rFzuwgNJvCrwkFR2GXoaKU5SPoigKlxPPy6O4Xd46LHv/IOAC0a7i dQYHoTmAEvi9ka4mWtyLCif8RXFZM/r7/eufoe8F8K1plCvi8ufGbhVCPYVQ9v8sI6dY ueKBl6uVKL0N3dTQhxE4PDJEwxyu9LQIGK1yq184WUHR5yqkpbPvQq9O7NRaCMUfVdGx 2fuXbQCqogXOIGo1atBAOSwl41PpmmlEk8zsSb9D/7OLepGNiHP3+chrOsX0bxDiztRJ +qCQ== X-Gm-Message-State: AOJu0YwG0pjAqDAr30c9otwcwD+c0wsrhc000pEWCqi27jwIaXP3oJfN n4xgxISiEJVpEJj/n2y922fFq3SHyCA= X-Google-Smtp-Source: AGHT+IFTcanp2PgeUlsBe6acnCorL6mrsLeGVUyMlUhGhob9bR6LKZlVBrq9Y6Q4E1OFc7EkekhTTOPkt/g= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:902:e542:b0:1b8:5541:9d3e with SMTP id n2-20020a170902e54200b001b855419d3emr300692plf.6.1691591626649; Wed, 09 Aug 2023 07:33:46 -0700 (PDT) Date: Wed, 9 Aug 2023 07:33:45 -0700 In-Reply-To: Mime-Version: 1.0 References: <20221223005739.1295925-1-seanjc@google.com> <20221223005739.1295925-20-seanjc@google.com> <5581418b-2e1c-6011-f0a4-580df7e00b44@gmail.com> Message-ID: Subject: Re: [PATCH 19/27] KVM: x86/mmu: Use page-track notifiers iff there are external users From: Sean Christopherson To: Yan Zhao Cc: Like Xu , kvm@vger.kernel.org, intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, Zhenyu Wang , Ben Gardon , Paolo Bonzini , intel-gvt-dev@lists.freedesktop.org, Zhi Wang Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Aug 09, 2023, Yan Zhao wrote: > On Mon, Aug 07, 2023 at 10:19:07AM -0700, Sean Christopherson wrote: > > On Mon, Aug 07, 2023, Like Xu wrote: > > > On 23/12/2022 8:57 am, Sean Christopherson wrote: > > > > +static inline void kvm_page_track_write(struct kvm_vcpu *vcpu, gpa_t gpa, > > > > + const u8 *new, int bytes) > > > > +{ > > > > + __kvm_page_track_write(vcpu, gpa, new, bytes); > > > > + > > > > + kvm_mmu_track_write(vcpu, gpa, new, bytes); > > > > +} > > > > > > The kvm_mmu_track_write() is only used for x86, where the incoming parameter > > > "u8 *new" has not been required since 0e0fee5c539b ("kvm: mmu: Fix race in > > > emulated page table writes"), please help confirm if it's still needed ? Thanks. > > > A minor clean up is proposed. > > > > Hmm, unless I'm misreading things, KVMGT ultimately doesn't consume @new either. > > So I think we can remove @new from kvm_page_track_write() entirely. > Sorry for the late reply. > Yes, KVMGT does not consume @new and it reads the guest PTE again in the > page track write handler. > > But I have a couple of questions related to the memtioned commit as > below: > > (1) If "re-reading the current value of the guest PTE after the MMU lock has > been acquired", then should KVMGT also acquire the MMU lock too? No. If applicable, KVMGT should read the new/current value after acquiring whatever lock protects the generation (or update) of the shadow entries. I suspect KVMGT already does this, but I don't have time to confirm that at this exact memory. The race that was fixed in KVM was: vCPU0 vCPU1 write X write Y sync SPTE w/ Y sync SPTE w/ X Reading the value after acquiring mmu_lock ensures that both vCPUs will see whatever value "loses" the race, i.e. whatever written value is processed second ('Y' in the above sequence). > If so, could we move the MMU lock and unlock into kvm_page_track_write() > as it's common. > > (2) Even if KVMGT consumes @new, > will kvm_page_track_write() be called for once or twice if there are two > concurent emulated write? Twice, kvm_page_track_write() is wired up directly to the emulation of the write, i.e. there is no batching.