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 6ECC3E7D0AA for ; Thu, 21 Sep 2023 21:07:08 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231687AbjIUVHM (ORCPT ); Thu, 21 Sep 2023 17:07:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50744 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233268AbjIUVFj (ORCPT ); Thu, 21 Sep 2023 17:05:39 -0400 Received: from mail-pf1-x44a.google.com (mail-pf1-x44a.google.com [IPv6:2607:f8b0:4864:20::44a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EF1D26DE01 for ; Thu, 21 Sep 2023 10:32:34 -0700 (PDT) Received: by mail-pf1-x44a.google.com with SMTP id d2e1a72fcca58-690a0ec0be4so1147314b3a.1 for ; Thu, 21 Sep 2023 10:32:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1695317554; x=1695922354; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=VFujV55InQpfIcmwhWIdcFo9LOSK6bP3ULKilR3pEPA=; b=CRrY5DH6PB4BwXaEGzcHDlcir4MD72Km3WSYqM2eWTj93A1wQ1C6wh8A0S9dz1YXGI 8JTJSzUPgq9gB8WJQ2650xRU4IODoJA9ttmV6GFotUyD0AKY9VjieSr9nYp3IvysXnvg DjW09svO/Iktgs4Biyc9eMa+lhhUDuHftnK2ncYtQf/72FiZV9inILs5mLFteZqO756F GKYCopYONuRUazKxfRBeTIsHjIa3nOCEPZ+IgOGq+tSCHAg45ATbTikShguve6C0EayE O9mrQGTlA30G2YuN8lwYG0zPVqwAaVdhWJ8VJWzITm7a6IhBBnfMvVuISW1yS8yy0XCE fVoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695317554; x=1695922354; 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=VFujV55InQpfIcmwhWIdcFo9LOSK6bP3ULKilR3pEPA=; b=oV/l5Lsk7CI/GlYWimyvlRfOj15gw3TwFpVccE3a6eECzvNqPP27cZ0Dcp0YJcLxNZ jsx/hB0rxPJrjUXijCROC/82X2+OjmP5PibftnPLqZ8ISmSGrmt02hyq+ndWDMQ3btJ3 pQNp/UmxQbbry6njikdBT/9Q7DvZGv7kn9+fuITV1MpJ3bTzRNmlSJaa6oYp6iBSjtTG UMNvyxkm0G/hQ0ooTEj0uXcxuHUHSN3yZgDi3CXBxwQ5Rmi/kKb/u7d6eNSCpr3Fu6xU /jXGSC4vC56eJ29KPpH02TFIHsQijVvWZPiyZvC7Qxm4EFxpGcDGW6Z0nwNYG5l23wzw BEoA== X-Gm-Message-State: AOJu0YyVIYsewoVD8Lx3fg80IsuYRGSHN+cg0SHSyYlxqMtxbGBiPw9V cqnV6iSVUdZXqEZM2lxWCcO373Kiiso= X-Google-Smtp-Source: AGHT+IGn6bxt0aytyfRrQvdNGXaSXeT8sIcIptWMB2qfEas65NY2TcrLdWuDyigFBOjNZ28AUG3erUeC33s= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:902:ce86:b0:1c3:c127:558 with SMTP id f6-20020a170902ce8600b001c3c1270558mr71199plg.0.1695306271120; Thu, 21 Sep 2023 07:24:31 -0700 (PDT) Date: Thu, 21 Sep 2023 07:24:29 -0700 In-Reply-To: Mime-Version: 1.0 References: <20230914015531.1419405-1-seanjc@google.com> <20230914015531.1419405-3-seanjc@google.com> Message-ID: Subject: Re: [RFC PATCH v12 02/33] KVM: Use gfn instead of hva for mmu_notifier_retry From: Sean Christopherson To: Xu Yilun Cc: Paolo Bonzini , Marc Zyngier , Oliver Upton , Huacai Chen , Michael Ellerman , Anup Patel , Paul Walmsley , Palmer Dabbelt , Albert Ou , "Matthew Wilcox (Oracle)" , Andrew Morton , Paul Moore , James Morris , "Serge E. Hallyn" , kvm@vger.kernel.org, linux-arm-kernel@lists.infradead.org, kvmarm@lists.linux.dev, linux-mips@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, kvm-riscv@lists.infradead.org, linux-riscv@lists.infradead.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, Chao Peng , Fuad Tabba , Jarkko Sakkinen , Anish Moorthy , Yu Zhang , Isaku Yamahata , Vlastimil Babka , Vishal Annapurve , Ackerley Tng , Maciej Szmigiero , David Hildenbrand , Quentin Perret , Michael Roth , Wang , Liam Merwick , Isaku Yamahata , "Kirill A . Shutemov" Content-Type: text/plain; charset="us-ascii" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 21, 2023, Xu Yilun wrote: > When the invalidation acrosses multiple slots, I'm not sure if the > contiguous HVA range must correspond to contiguous GFN range. If not, > are we producing a larger range than required? Multiple invalidations are all but guaranteed to yield a range that covers addresses that aren't actually being invalidated. This is true today. > And when the invalidation acrosses multiple address space, I'm almost > sure it is wrong to merge GFN ranges from different address spaces. It's not "wrong" in the sense that false positives do not cause functional problems, at worst a false positive can unnecessarily stall a vCPU until the unrelated invalidations complete. Multiple concurrent invalidations are not common, and if they do happen, they are likely related and will have spacial locality in both host virtual address space and guest physical address space. Given that, we chose for the simple (and fast!) approach of maintaining a single all-encompassing range.