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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 9D59DC52D7B for ; Wed, 14 Aug 2024 14:24:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:Cc:To:From: Subject:Message-ID:References:Mime-Version:In-Reply-To:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Lg7Z6HPc6YbnuAyQKf9l4Kwwyg7M7gxKeR8BkfMVjOA=; b=YYKPrYRuoIVnZ9P/exKA6iebKl 3ORd+w+arZHmfjxrPzlzsWsxXKFyDRhyldvWdzhQ5qHu5yEFe9YGrFloVtsNrEj1ZTSN+xkfxhKcP z5My6jGF6oIAhJ1Z1RkJilGrVTpd4SCByq1SgLO4IPuB2+N/vwzwvFu9+IiGZPT1wm8qL53agbRS1 JA2jVFPydwxgbG3nNSVn99Xeuu5pJhVevJpi4m3m4ZhtTIqZjYRdTZVuFu5JhLa+pO+A+8J8W9ZV+ CLRrzXASmbFtwyMCyBw22oebNXqA6OJY20zqJJSf4f5vMD2D96cj6npkW9ZofYUjFPQq14ymsBzZv SMWuy5MQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1seEv3-00000007GDN-0nw8; Wed, 14 Aug 2024 14:24:09 +0000 Received: from mail-pg1-x549.google.com ([2607:f8b0:4864:20::549]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1seEuP-00000007G4D-2rO3 for linux-arm-kernel@lists.infradead.org; Wed, 14 Aug 2024 14:23:30 +0000 Received: by mail-pg1-x549.google.com with SMTP id 41be03b00d2f7-7a1914d0936so5419347a12.3 for ; Wed, 14 Aug 2024 07:23:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1723645408; x=1724250208; darn=lists.infradead.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=Lg7Z6HPc6YbnuAyQKf9l4Kwwyg7M7gxKeR8BkfMVjOA=; b=1PKHNOld/bTr3eCGB8S+s08A1nAhL+2Aiy9CQSyyfhYLK4sQImeWc+F6KHrB/W9I9n t0Ca3Es0kYtMiqdzgd7AfYrkGEqrZ0J3i6CHOT606DDTMomhHRMcOvBmVYffzcaS2vUV fENRpCGKpNNbADjYTONl1KAHwJsv+M64AtU3xxVTApRGdpxVeu8I1WtHYvSQiLhjreTZ VucMqyg7x+RSgSHqbbIFo0/VCzR70dKgGfSy8wlZY1xj6vXipsXv5bEEjXQ/qdoNRv1t 84Rb1t6ktQCZ6Harb+yVq6E3DBrbqvMe1TjvWN39nXR+DYbf2ukfZTA33D1KM3dhFd5H nuZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723645408; x=1724250208; 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=Lg7Z6HPc6YbnuAyQKf9l4Kwwyg7M7gxKeR8BkfMVjOA=; b=Nyye0MD5/xTLifgpkJE83b3p7qOypVYnEiWKG0sBzV+lp2o3fONVRXyFJPBhqscsgM AOb4edny46ONSAskCXgFFUTzPmlH5HVbyhNAXbrVzLYGxN/cqa44gRMAfZpM8UDFfEOA mAQvUMydAKX7V8GqfjSO+MoeII8zOlAXCYwvgiuEDedmRMPUmvXjRxRx6xFRr/Tz5hGi GOmx8yayuKmZUeBOkbNNyFDYPkLjPn+e/LefcNAtZlB6LvM2bHQC+dDWNcQC4qDraaCc 3/BV/8ZCJKLRNgxXbU5rp61fEfs7tQczeWSKL9ifAnxkF2tpdIQI6uP/4x63HaUZmyoz eeXw== X-Forwarded-Encrypted: i=1; AJvYcCXTa59UNXmwQ/laFexgvRNsN4HgHMPba43b0AhdNQ1K2vx/Pfnyh5dgGSqFhJEsMboKzMGNJCenhgPh+uapcR5QvbmsCA4IgfAx/fQAeVnm5zq49bo= X-Gm-Message-State: AOJu0Ywap0Q9Jz83m1tm58tcYBiogAeGp9qNMb6vmYVM2sUua5VdeFjq kaGLlLHn+2Q6NanJOB6oyMiCWpdcpZUarFveAhRumtwQG58Yy2KcGg68HRoHK0/Hj3H9s2Hj0XA HNg== X-Google-Smtp-Source: AGHT+IE8K9ernEt/qh7dn+1OHmtOhjlZRg5DWU6KU712b9wel2NvDzCtf+nXpMhkwXka1BX1I745J1ypunQ= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a17:90a:b10f:b0:2cb:4b7e:ffa3 with SMTP id 98e67ed59e1d1-2d3aaa74a9emr7282a91.1.1723645407394; Wed, 14 Aug 2024 07:23:27 -0700 (PDT) Date: Wed, 14 Aug 2024 07:23:26 -0700 In-Reply-To: <20240814131514.GJ2032816@nvidia.com> Mime-Version: 1.0 References: <20240809160909.1023470-1-peterx@redhat.com> <20240809160909.1023470-11-peterx@redhat.com> <20240814131514.GJ2032816@nvidia.com> Message-ID: Subject: Re: [PATCH 10/19] KVM: Use follow_pfnmap API From: Sean Christopherson To: Jason Gunthorpe Cc: Axel Rasmussen , Peter Xu , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Oscar Salvador , linux-arm-kernel@lists.infradead.org, x86@kernel.org, Will Deacon , Gavin Shan , Paolo Bonzini , Zi Yan , Andrew Morton , Catalin Marinas , Ingo Molnar , Alistair Popple , Borislav Petkov , David Hildenbrand , Thomas Gleixner , kvm@vger.kernel.org, Dave Hansen , Alex Williamson , Yan Zhao Content-Type: text/plain; charset="us-ascii" X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240814_072329_743221_B6196D06 X-CRM114-Status: GOOD ( 22.34 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Aug 14, 2024, Jason Gunthorpe wrote: > On Mon, Aug 12, 2024 at 04:44:40PM -0700, Sean Christopherson wrote: > > > > > > I don't think it has to be done in this series, but a future > > > > > optimization to consider is having follow_pfnmap just tell the caller > > > > > about the mapping level directly. It already found this information as > > > > > part of its walk. I think there's a possibility to simplify KVM / > > > > > avoid it having to do its own walk again later. > > > > > > > > AFAIU pfnmap isn't special in this case, as we do the "walk pgtable twice" > > > > idea also to a generic page here, so probably not directly relevant to this > > > > patch alone. > > > > Ya. My original hope was that KVM could simply walk the host page tables and get > > whatever PFN+size it found, i.e. that KVM wouldn't care about pfn-mapped versus > > regular pages. That might be feasible after dropping all of KVM's refcounting > > shenanigans[*]? Not sure, haven't thought too much about it, precisely because > > I too think it won't provide any meaningful performance boost. > > The main thing, from my perspective, is that KVM reliably creates 1G > mappings in its table if the VMA has 1G mappings, across all arches > and scenarios. For normal memory and PFNMAP equally. Yes, KVM walks the host page tables for the user virtual address and uses whatever page size it finds, regardless of what the mapping type. > Not returning the size here makes me wonder if that actually happens? It does happen, the idea here was purely to avoid the second page table walk. > Does KVM have another way to know what size entry to create? > > Jason