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 2670FC3DA7F for ; Mon, 12 Aug 2024 23:45:35 +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-Transfer-Encoding: Content-Type:Cc:To:From:Subject:Message-ID:References:Mime-Version: In-Reply-To:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=UrUY3rIeJYoBe0Ouux9HKw4xsjRgOYNubTcynFZwH0s=; b=VgVKK3BQXk75J1vz6rSJtCLmwQ HmPYPpJZlRvHAwKUZL15LupEU4MjkK0piIiDnSMlktuZ/oYxeeCdDFwpV5ptDlXFO9mnYhbIqsAgJ 1SciQWFFlqJm/pjfe1Jspr9inVoAILrpyp1bJF2l/YD4AXRCInyXiXZHHH+J/d4SEsgmcvXeWkBRB qM2rr2dQXy9MYv8rjAk2Qj7NC9BFr6qR6ID+d73n99Kbm4C9bEuh3sW/gnwpqhKFoC7A2ZFQciIXl j4uxDa8i/dsM32JYd/QIz87UoEqo52OJjGpxlfARhSfk7MekL9a/8qeDflF2tMdP5lI1d3TufEJyE XxNur9Ew==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sdej3-00000001qza-3b1v; Mon, 12 Aug 2024 23:45:21 +0000 Received: from mail-pf1-x44a.google.com ([2607:f8b0:4864:20::44a]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sdeiR-00000001qtC-1jBj for linux-arm-kernel@lists.infradead.org; Mon, 12 Aug 2024 23:44:44 +0000 Received: by mail-pf1-x44a.google.com with SMTP id d2e1a72fcca58-70e923f6632so4295610b3a.3 for ; Mon, 12 Aug 2024 16:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1723506281; x=1724111081; darn=lists.infradead.org; h=content-transfer-encoding:cc:to:from:subject:message-id:references :mime-version:in-reply-to:date:from:to:cc:subject:date:message-id :reply-to; bh=UrUY3rIeJYoBe0Ouux9HKw4xsjRgOYNubTcynFZwH0s=; b=j+2d1J7fXLlAVHC0ykeQPIVLkHb6HvWGcDfEtEAu0h9ElNkNWjV6X1W6B5uE/e9ylr lSoZSF8tbdEM1OqLfBfVah7CTPdcU8bS3B1l+YWxvP+DYxnsX8PVsrCcqBdQF1ITPKeC KGp9Bx4lRzqA5yqV5wl3/EcGq8K1mqD9saA++0zRa0TfAhaOar4g/S7Djjvkj+xAwoAN Gc5xDbbzujoiKffOnyzMmcXe9nakB6gUg2d6atMKk64fbgCJd6TKgyF4UnK3rDLCuylA KEPRjq/tx3nwQgwC4aFcD5riAhJp97U/2wpYRR3WMzf155kgimfnu/W956+mWFAyeKtH FoOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723506281; x=1724111081; h=content-transfer-encoding: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=UrUY3rIeJYoBe0Ouux9HKw4xsjRgOYNubTcynFZwH0s=; b=AtBmWTC6vrziDWWW9gfF9CCm+sl+VVq9+1WaPTUeJmzZKYfzrFlHQFn/WXvgqi7/ay wMt7Kos1c7KsoWgnCZJ2Ih0fGbQux961XdsGu2BmHtIeCHfq1U1/p4Ods47lKOW8tqQg RxWuSvW8rGTEwq8EU0Dy671ilXmGqwg9ImY1cSaNurJTT1GRxGVDtxowH40xQfaXd69H S0tBnAysDa/Pcu+8ABnYjwyyJ+VAxUVWEX9g+REYx8s3uEUVbqkl2983ffBEtnlC+pcq L/n//SoUI3a3yFqzI7PVVvl9arkMr5eK5rKjULuKXRnG0Z0rEnegg1ck0PUk1ly7eXXN ceRA== X-Forwarded-Encrypted: i=1; AJvYcCVRiLw0nJErMegaHIZzDp7+c3iCUI3n/Jbp5n64BER5NKwDkTlQTyc/DRZ1L1swYhBx4vw0IUSM2/bIFHbH0RyjfcBUbwx5cVEFPou5W3Ty/EZNGZk= X-Gm-Message-State: AOJu0YzsKvNbRxD+2KI6WqMAggN0k0FYzWC85ujuEWnnO+rgeWtr8CPa kIm8D3/g+81bPe9tuIrdXI/yRZU32eoirS+awEVTmC7IQ8o9murNLVL0kx3VGtXFPtQ4NmF/deQ 3jg== X-Google-Smtp-Source: AGHT+IGdc2rxTHl1QtaSN9GH/Q9+wvgi/0cyWFA0UrSnLq1lqIiESyoGNp3cjAk7IHs7Im6Tod87VUtigrY= X-Received: from zagreus.c.googlers.com ([fda3:e722:ac3:cc00:7f:e700:c0a8:5c37]) (user=seanjc job=sendgmr) by 2002:a05:6a00:66e8:b0:710:4d94:f9aa with SMTP id d2e1a72fcca58-712552c0336mr7070b3a.6.1723506281370; Mon, 12 Aug 2024 16:44:41 -0700 (PDT) Date: Mon, 12 Aug 2024 16:44:40 -0700 In-Reply-To: Mime-Version: 1.0 References: <20240809160909.1023470-1-peterx@redhat.com> <20240809160909.1023470-11-peterx@redhat.com> Message-ID: Subject: Re: [PATCH 10/19] KVM: Use follow_pfnmap API From: Sean Christopherson To: Axel Rasmussen Cc: Peter Xu , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Oscar Salvador , Jason Gunthorpe , 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="utf-8" Content-Transfer-Encoding: quoted-printable X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240812_164443_471699_4A203A1C X-CRM114-Status: GOOD ( 24.68 ) 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 Mon, Aug 12, 2024, Axel Rasmussen wrote: > On Mon, Aug 12, 2024 at 11:58=E2=80=AFAM Peter Xu wro= te: > > > > On Fri, Aug 09, 2024 at 10:23:20AM -0700, Axel Rasmussen wrote: > > > On Fri, Aug 9, 2024 at 9:09=E2=80=AFAM Peter Xu w= rote: > > > > > > > > Use the new pfnmap API to allow huge MMIO mappings for VMs. The re= st work > > > > is done perfectly on the other side (host_pfn_mapping_level()). > > > > > > 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 a= s > > > 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 twi= ce" > > 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 a= nd get whatever PFN+size it found, i.e. that KVM wouldn't care about pfn-mapped ve= rsus regular pages. That might be feasible after dropping all of KVM's refcount= ing shenanigans[*]? Not sure, haven't thought too much about it, precisely bec= ause I too think it won't provide any meaningful performance boost. > > But I agree with you, sounds like something we can consider trying. I > > would be curious on whether the perf difference would be measurable in = this > > specific case, though. I mean, this first walk will heat up all the > > things, so I'd expect the 2nd walk (which is lockless) later be pretty = fast > > normally. >=20 > Agreed, the main benefit is probably just code simplification. +1. I wouldn't spend much time, if any, trying to plumb the size back out. Unless we can convert regular pages as well, it'd probably be more confusin= g to have separate ways of getting the mapping size.