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 X-Spam-Level: X-Spam-Status: No, score=-21.3 required=3.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT, USER_IN_DEF_DKIM_WL autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B884AC47089 for ; Thu, 27 May 2021 12:51:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8D7D4613CC for ; Thu, 27 May 2021 12:51:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235799AbhE0MxO (ORCPT ); Thu, 27 May 2021 08:53:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54170 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234523AbhE0MxL (ORCPT ); Thu, 27 May 2021 08:53:11 -0400 Received: from mail-wm1-x34a.google.com (mail-wm1-x34a.google.com [IPv6:2a00:1450:4864:20::34a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A0556C061574 for ; Thu, 27 May 2021 05:51:38 -0700 (PDT) Received: by mail-wm1-x34a.google.com with SMTP id f141-20020a1c1f930000b029017ce5240ed6so79128wmf.5 for ; Thu, 27 May 2021 05:51:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:message-id:mime-version:subject:from:to:cc; bh=OFJTCYvTlm44Js7Oh0x+dWK8ho65pfFD2cK8memDcmU=; b=QB0AuKgJ00Z+R2vn+s/ZmfmnVBgsEKhuVuQ5GcbOcE0XrgCVuJ6+3mvy4BAzFdXFy2 1X1e/i9+3FlsRBqEHHm0KtN9SrVPvMu+S2ddDDgER5HsSXUzyEaApDT28GZ26LYc4kLD p1S/TVyiTqbLFEKpoN51NO4vJcLb9llEHm1hPXEenjscHufgWUjbLPFWPcVnOrMennnS LytX8aVgRwM9l/sQBgnwFzTnBYXKyxIAHjwuyyXS+ZFRIXPHSsnDThBI97VtcTWM2C3e MvvORRmCCYIza9KQ6XEe0MOeu9OEXlC/ONYqaxNATER10dOwNAT4jwSKlvDUKeh5IBQO +rDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:message-id:mime-version:subject:from:to:cc; bh=OFJTCYvTlm44Js7Oh0x+dWK8ho65pfFD2cK8memDcmU=; b=ucYeZVkBkfakFmAzmAssC7xVMUJkvRoDWmRr4QUp+iNNK1429hUD3b7xZOU/QbhqUX Xzya7D7d6arp+9LYRkhDrMUBqVZ+eTvG5BlIhcn7zI3v6VO365le/cMRRwt1TEpiteYO 7ddqaihW0bWHYO/NsaIFFd3pQIhZ+VxjDq+jCnBJ0Bft9afmUsfBvjPNh9MGv+hW+L2H m1ixSjcEpM3PwCMN5wu4yckq0EIKiwzkubvN5xfLQRmP+7pQdfjpX6mMI2dxAVSn92DS yDnxS2AGBS10bb/sbUrcnGp6D/9HuicHJpzydNnGeF/Ki9xBGRIUULeHYI6iZ0QWgr3F Qopw== X-Gm-Message-State: AOAM5313bO+67ShGu9he7aiCsW+FS6dFdH9qCGp/QdJwtP4XMcnvVUnn S04jjhwKp5T2srGTAF/wuSUZ7Z/uWjnU X-Google-Smtp-Source: ABdhPJyAac0auDLnAIfnc5GbbqU7TodPnilNsvhasp1h2deq/n8uFLQy6e5SlSjZZmZ6iix6pWbwR7ycCt06 X-Received: from r2d2-qp.c.googlers.com ([fda3:e722:ac3:cc00:28:9cb1:c0a8:1652]) (user=qperret job=sendgmr) by 2002:a05:600c:35cc:: with SMTP id r12mr1310535wmq.1.1622119896122; Thu, 27 May 2021 05:51:36 -0700 (PDT) Date: Thu, 27 May 2021 12:51:27 +0000 Message-Id: <20210527125134.2116404-1-qperret@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.31.1.818.g46aad6cb9e-goog Subject: [PATCH 0/7] KVM: arm64: Reduce hyp_vmemmap overhead From: Quentin Perret To: maz@kernel.org, will@kernel.org, james.morse@arm.com, alexandru.elisei@arm.com, catalin.marinas@arm.com, suzuki.poulose@arm.com Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kernel-team@android.com, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi all, When running in nVHE protected mode, the hypervisor manages its own vmemmap and uses it to store page metadata, e.g. refcounts. This series shrinks the size of struct hyp_page from 32 bytes to 4 bytes without loss of functionality, hence reducing the cost of the hyp vmemmap from 8MB/GB to 1MB/GB with 4K pages. The series has two immediate benefits: - the memory overhead of the nVHE protected mode is reduced; - it refactors the host stage-2 memory pools in a way that allows better re-use of pages to map MMIO ranges, allowing more MMIO mappings (currently limited to 1GB IPA space) most of the time. But more importantly, the series reduces the hyp vmemmap overhead enough that we might consider covering _all_ of memory with it at EL2 in the future. This would simplify significantly the dynamic admission of memory into the EL2 allocator, which will be required when the hypervisor will allocate stage-2 page-tables of guests for instance. This would also allow the hypervisor to refcount pages it doesn't 'own', which be useful to track shared pages and such. The series is split as follows - patches 01-03 move the list_head of each page from struct hyp_page to the page itself -- the pages are attached to the free lists only when they are free by definition; - patches 04-05 remove the hyp_pool pointer from struct hyp_page as that information can be inferred from the context; - patches 06-07 reduce the size of the remaining members of struct hyp_page which are currently oversized for the needs of the hypervisor. On a last note, I believe we could actually make hyp_page fit in 16bits when using 4K pages: limiting the MAX_ORDER to 7 should suffice and require only 3 bits, and 13bits should be enough for the refcount for the existing use-cases. I decided not to implement this as we probably want to keep some room to grow in hyp_page (e.g. add flags, ...), that might cause issues to make refcounts atomic, and 16bits are not enough with 64K pages so we'd have to deal with that separately, but that _is_ a possibility. Thanks! Quentin Quentin Perret (7): KVM: arm64: Move hyp_pool locking out of refcount helpers KVM: arm64: Use refcount at hyp to check page availability KVM: arm64: Remove list_head from hyp_page KVM: arm64: Unify MMIO and mem host stage-2 pools KVM: arm64: Remove hyp_pool pointer from struct hyp_page KVM: arm64: Use less bits for hyp_page order KVM: arm64: Use less bits for hyp_page refcount arch/arm64/kvm/hyp/include/nvhe/gfp.h | 33 ++----- arch/arm64/kvm/hyp/include/nvhe/mem_protect.h | 2 +- arch/arm64/kvm/hyp/include/nvhe/memory.h | 7 +- arch/arm64/kvm/hyp/include/nvhe/mm.h | 13 +-- arch/arm64/kvm/hyp/nvhe/mem_protect.c | 59 +++++++------ arch/arm64/kvm/hyp/nvhe/page_alloc.c | 87 ++++++++++++------- arch/arm64/kvm/hyp/nvhe/setup.c | 30 ++++--- arch/arm64/kvm/hyp/reserved_mem.c | 3 +- 8 files changed, 123 insertions(+), 111 deletions(-) -- 2.31.1.818.g46aad6cb9e-goog 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 X-Spam-Level: X-Spam-Status: No, score=-11.5 required=3.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED,DKIM_INVALID,DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B5CC7C4707F for ; Thu, 27 May 2021 12:51:42 +0000 (UTC) Received: from mm01.cs.columbia.edu (mm01.cs.columbia.edu [128.59.11.253]) by mail.kernel.org (Postfix) with ESMTP id 27C59613CA for ; Thu, 27 May 2021 12:51:42 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 27C59613CA Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvmarm-bounces@lists.cs.columbia.edu Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 9021D4A1A7; Thu, 27 May 2021 08:51:41 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Authentication-Results: mm01.cs.columbia.edu (amavisd-new); dkim=softfail (fail, message has been altered) header.i=@google.com Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8T1f6IfmS7I; Thu, 27 May 2021 08:51:40 -0400 (EDT) Received: from mm01.cs.columbia.edu (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 6C6FD4A19B; Thu, 27 May 2021 08:51:40 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mm01.cs.columbia.edu (Postfix) with ESMTP id 3D84C4A023 for ; Thu, 27 May 2021 08:51:39 -0400 (EDT) X-Virus-Scanned: at lists.cs.columbia.edu Received: from mm01.cs.columbia.edu ([127.0.0.1]) by localhost (mm01.cs.columbia.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5AeglxVw4G0 for ; Thu, 27 May 2021 08:51:38 -0400 (EDT) Received: from mail-wm1-f74.google.com (mail-wm1-f74.google.com [209.85.128.74]) by mm01.cs.columbia.edu (Postfix) with ESMTPS id F1BF440808 for ; Thu, 27 May 2021 08:51:37 -0400 (EDT) Received: by mail-wm1-f74.google.com with SMTP id r15-20020a05600c35cfb029017cc4b1e9faso1448689wmq.8 for ; Thu, 27 May 2021 05:51:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:message-id:mime-version:subject:from:to:cc; bh=OFJTCYvTlm44Js7Oh0x+dWK8ho65pfFD2cK8memDcmU=; b=QB0AuKgJ00Z+R2vn+s/ZmfmnVBgsEKhuVuQ5GcbOcE0XrgCVuJ6+3mvy4BAzFdXFy2 1X1e/i9+3FlsRBqEHHm0KtN9SrVPvMu+S2ddDDgER5HsSXUzyEaApDT28GZ26LYc4kLD p1S/TVyiTqbLFEKpoN51NO4vJcLb9llEHm1hPXEenjscHufgWUjbLPFWPcVnOrMennnS LytX8aVgRwM9l/sQBgnwFzTnBYXKyxIAHjwuyyXS+ZFRIXPHSsnDThBI97VtcTWM2C3e MvvORRmCCYIza9KQ6XEe0MOeu9OEXlC/ONYqaxNATER10dOwNAT4jwSKlvDUKeh5IBQO +rDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:message-id:mime-version:subject:from:to:cc; bh=OFJTCYvTlm44Js7Oh0x+dWK8ho65pfFD2cK8memDcmU=; b=Ksday17KBUKtySp+bg2Zulbvh0vnYt2P/8KU1S8+9Z0K/dN0+o+F4F6J+IcHPe/+gW qe5tpyUrFASUOp67fKAc8fGTvkdUuuk0MJHk7EfUmPjVWUDv4wzdKyn0my1LfGSH9jwl Zhz7ShP1AucTF8Chdf3jsDFEohwM14aQT/XRm2l6uM0rqEuScybNVbH9BUjB67dFEH1M 16QZtdTpkEltBJBCslu3OuxMUXrmA5lR6m+JFXW9b66mNQUZg0kJvNs+PLRpHDwxOefB QXoB4JkP2TF05BLGe4YOa4ueYrXD0Fv8ka6/TTeCsgM4TltTA6Fpl9e8kb75E/D2JAME KAAw== X-Gm-Message-State: AOAM531jOe82niNHu2kCp0za3ITyKmmpUYszU4p8v6Y9pz+tK3usv3M2 1J3wAmvGIj5If+7LntIZ9QxVVHgUrelO X-Google-Smtp-Source: ABdhPJyAac0auDLnAIfnc5GbbqU7TodPnilNsvhasp1h2deq/n8uFLQy6e5SlSjZZmZ6iix6pWbwR7ycCt06 X-Received: from r2d2-qp.c.googlers.com ([fda3:e722:ac3:cc00:28:9cb1:c0a8:1652]) (user=qperret job=sendgmr) by 2002:a05:600c:35cc:: with SMTP id r12mr1310535wmq.1.1622119896122; Thu, 27 May 2021 05:51:36 -0700 (PDT) Date: Thu, 27 May 2021 12:51:27 +0000 Message-Id: <20210527125134.2116404-1-qperret@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.31.1.818.g46aad6cb9e-goog Subject: [PATCH 0/7] KVM: arm64: Reduce hyp_vmemmap overhead From: Quentin Perret To: maz@kernel.org, will@kernel.org, james.morse@arm.com, alexandru.elisei@arm.com, catalin.marinas@arm.com, suzuki.poulose@arm.com Cc: kernel-team@android.com, kvmarm@lists.cs.columbia.edu, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org X-BeenThere: kvmarm@lists.cs.columbia.edu X-Mailman-Version: 2.1.14 Precedence: list List-Id: Where KVM/ARM decisions are made List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: kvmarm-bounces@lists.cs.columbia.edu Sender: kvmarm-bounces@lists.cs.columbia.edu Hi all, When running in nVHE protected mode, the hypervisor manages its own vmemmap and uses it to store page metadata, e.g. refcounts. This series shrinks the size of struct hyp_page from 32 bytes to 4 bytes without loss of functionality, hence reducing the cost of the hyp vmemmap from 8MB/GB to 1MB/GB with 4K pages. The series has two immediate benefits: - the memory overhead of the nVHE protected mode is reduced; - it refactors the host stage-2 memory pools in a way that allows better re-use of pages to map MMIO ranges, allowing more MMIO mappings (currently limited to 1GB IPA space) most of the time. But more importantly, the series reduces the hyp vmemmap overhead enough that we might consider covering _all_ of memory with it at EL2 in the future. This would simplify significantly the dynamic admission of memory into the EL2 allocator, which will be required when the hypervisor will allocate stage-2 page-tables of guests for instance. This would also allow the hypervisor to refcount pages it doesn't 'own', which be useful to track shared pages and such. The series is split as follows - patches 01-03 move the list_head of each page from struct hyp_page to the page itself -- the pages are attached to the free lists only when they are free by definition; - patches 04-05 remove the hyp_pool pointer from struct hyp_page as that information can be inferred from the context; - patches 06-07 reduce the size of the remaining members of struct hyp_page which are currently oversized for the needs of the hypervisor. On a last note, I believe we could actually make hyp_page fit in 16bits when using 4K pages: limiting the MAX_ORDER to 7 should suffice and require only 3 bits, and 13bits should be enough for the refcount for the existing use-cases. I decided not to implement this as we probably want to keep some room to grow in hyp_page (e.g. add flags, ...), that might cause issues to make refcounts atomic, and 16bits are not enough with 64K pages so we'd have to deal with that separately, but that _is_ a possibility. Thanks! Quentin Quentin Perret (7): KVM: arm64: Move hyp_pool locking out of refcount helpers KVM: arm64: Use refcount at hyp to check page availability KVM: arm64: Remove list_head from hyp_page KVM: arm64: Unify MMIO and mem host stage-2 pools KVM: arm64: Remove hyp_pool pointer from struct hyp_page KVM: arm64: Use less bits for hyp_page order KVM: arm64: Use less bits for hyp_page refcount arch/arm64/kvm/hyp/include/nvhe/gfp.h | 33 ++----- arch/arm64/kvm/hyp/include/nvhe/mem_protect.h | 2 +- arch/arm64/kvm/hyp/include/nvhe/memory.h | 7 +- arch/arm64/kvm/hyp/include/nvhe/mm.h | 13 +-- arch/arm64/kvm/hyp/nvhe/mem_protect.c | 59 +++++++------ arch/arm64/kvm/hyp/nvhe/page_alloc.c | 87 ++++++++++++------- arch/arm64/kvm/hyp/nvhe/setup.c | 30 ++++--- arch/arm64/kvm/hyp/reserved_mem.c | 3 +- 8 files changed, 123 insertions(+), 111 deletions(-) -- 2.31.1.818.g46aad6cb9e-goog _______________________________________________ kvmarm mailing list kvmarm@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/kvmarm 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 X-Spam-Level: X-Spam-Status: No, score=-12.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id F2783C47089 for ; Thu, 27 May 2021 12:53:17 +0000 (UTC) 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 mail.kernel.org (Postfix) with ESMTPS id ABA56613CA for ; Thu, 27 May 2021 12:53:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org ABA56613CA Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:From:Subject:Mime-Version: Message-Id:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Owner; bh=U52lWNN8Gp8th95rTos4Mh4+dg+3zAxwW3ycpvt3JIo=; b=YUz deZ9Tw3zgsVWdgYyRKI4eaCZI4NciwSl9jGxDu3e2Ug9DWGJTQBi6X8gsn0xTOugtSfCB7nIFiGk7 7q8rLldBrWFpq2tkeg6/Tic5rRaAXuEQ05YuGCzF5EIB3JuOZn3qS3d0X+ygWYiZ2qhYNLZJZVFLh D4Ed/1+F52iepHCvTfxzVMa97fLL/hpuEBR7u9Nubu3lvEnQXARDNNQafg0nRbqctPsyyVAhyN820 ++LKKrcAGKfrNM3w3X27wllkhnEUsUUzS1o93T26JGg/z7WqJc3IaOBOokdg2iDSLrXV2ON6Q7o/d 0yqnx7bTnl/qzkj3XITuNAghov1Yh1g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1lmFUI-005tRj-0h; Thu, 27 May 2021 12:51:46 +0000 Received: from mail-wm1-x34a.google.com ([2a00:1450:4864:20::34a]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1lmFUC-005tOI-BH for linux-arm-kernel@lists.infradead.org; Thu, 27 May 2021 12:51:42 +0000 Received: by mail-wm1-x34a.google.com with SMTP id y205-20020a1ce1d60000b029019278214067so185585wmg.3 for ; Thu, 27 May 2021 05:51:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:message-id:mime-version:subject:from:to:cc; bh=OFJTCYvTlm44Js7Oh0x+dWK8ho65pfFD2cK8memDcmU=; b=QB0AuKgJ00Z+R2vn+s/ZmfmnVBgsEKhuVuQ5GcbOcE0XrgCVuJ6+3mvy4BAzFdXFy2 1X1e/i9+3FlsRBqEHHm0KtN9SrVPvMu+S2ddDDgER5HsSXUzyEaApDT28GZ26LYc4kLD p1S/TVyiTqbLFEKpoN51NO4vJcLb9llEHm1hPXEenjscHufgWUjbLPFWPcVnOrMennnS LytX8aVgRwM9l/sQBgnwFzTnBYXKyxIAHjwuyyXS+ZFRIXPHSsnDThBI97VtcTWM2C3e MvvORRmCCYIza9KQ6XEe0MOeu9OEXlC/ONYqaxNATER10dOwNAT4jwSKlvDUKeh5IBQO +rDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:message-id:mime-version:subject:from:to:cc; bh=OFJTCYvTlm44Js7Oh0x+dWK8ho65pfFD2cK8memDcmU=; b=GhkmEtDqa8W4xmSOqOZhyf4pgO298kL+ud1cTeH1JOrTSYKMtXIKkv9hmCDeX2Y9mc RwiatpqHPt8+yHEEgIc5f6lRSm3zb0aZ8omRh7Dw0F0eT56i0CUOnTFoWStqsnkYuswg KU7gJQyO+Z8d+CNlm58MXRuFgzgFHefsf/MpEsl9bPENRf+cHmkIdY1Jd5/MvaissKC9 FzEwlFvBYoxGNAbD2qzq97A9ybR+6WxQnxsHzBld9V+WRObZpHOoGZShNetwJ05WzVGV Z8gpw79jXHCoqLOx5785a+kCZn3uajAmIT/ArWeCIiRuhG/7/zv7SSsw6QUj4o+JKb7j gx4A== X-Gm-Message-State: AOAM533GnKQUC/fGPGOcdAPpHCooUlD2YxirKJmEM5j3kygyYdDYEm6c IIUPG0gmV0AfnAzG95C2xyOwAksfqKlz X-Google-Smtp-Source: ABdhPJyAac0auDLnAIfnc5GbbqU7TodPnilNsvhasp1h2deq/n8uFLQy6e5SlSjZZmZ6iix6pWbwR7ycCt06 X-Received: from r2d2-qp.c.googlers.com ([fda3:e722:ac3:cc00:28:9cb1:c0a8:1652]) (user=qperret job=sendgmr) by 2002:a05:600c:35cc:: with SMTP id r12mr1310535wmq.1.1622119896122; Thu, 27 May 2021 05:51:36 -0700 (PDT) Date: Thu, 27 May 2021 12:51:27 +0000 Message-Id: <20210527125134.2116404-1-qperret@google.com> Mime-Version: 1.0 X-Mailer: git-send-email 2.31.1.818.g46aad6cb9e-goog Subject: [PATCH 0/7] KVM: arm64: Reduce hyp_vmemmap overhead From: Quentin Perret To: maz@kernel.org, will@kernel.org, james.morse@arm.com, alexandru.elisei@arm.com, catalin.marinas@arm.com, suzuki.poulose@arm.com Cc: linux-arm-kernel@lists.infradead.org, kvmarm@lists.cs.columbia.edu, kernel-team@android.com, linux-kernel@vger.kernel.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210527_055140_441863_99CB8461 X-CRM114-Status: GOOD ( 17.21 ) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi all, When running in nVHE protected mode, the hypervisor manages its own vmemmap and uses it to store page metadata, e.g. refcounts. This series shrinks the size of struct hyp_page from 32 bytes to 4 bytes without loss of functionality, hence reducing the cost of the hyp vmemmap from 8MB/GB to 1MB/GB with 4K pages. The series has two immediate benefits: - the memory overhead of the nVHE protected mode is reduced; - it refactors the host stage-2 memory pools in a way that allows better re-use of pages to map MMIO ranges, allowing more MMIO mappings (currently limited to 1GB IPA space) most of the time. But more importantly, the series reduces the hyp vmemmap overhead enough that we might consider covering _all_ of memory with it at EL2 in the future. This would simplify significantly the dynamic admission of memory into the EL2 allocator, which will be required when the hypervisor will allocate stage-2 page-tables of guests for instance. This would also allow the hypervisor to refcount pages it doesn't 'own', which be useful to track shared pages and such. The series is split as follows - patches 01-03 move the list_head of each page from struct hyp_page to the page itself -- the pages are attached to the free lists only when they are free by definition; - patches 04-05 remove the hyp_pool pointer from struct hyp_page as that information can be inferred from the context; - patches 06-07 reduce the size of the remaining members of struct hyp_page which are currently oversized for the needs of the hypervisor. On a last note, I believe we could actually make hyp_page fit in 16bits when using 4K pages: limiting the MAX_ORDER to 7 should suffice and require only 3 bits, and 13bits should be enough for the refcount for the existing use-cases. I decided not to implement this as we probably want to keep some room to grow in hyp_page (e.g. add flags, ...), that might cause issues to make refcounts atomic, and 16bits are not enough with 64K pages so we'd have to deal with that separately, but that _is_ a possibility. Thanks! Quentin Quentin Perret (7): KVM: arm64: Move hyp_pool locking out of refcount helpers KVM: arm64: Use refcount at hyp to check page availability KVM: arm64: Remove list_head from hyp_page KVM: arm64: Unify MMIO and mem host stage-2 pools KVM: arm64: Remove hyp_pool pointer from struct hyp_page KVM: arm64: Use less bits for hyp_page order KVM: arm64: Use less bits for hyp_page refcount arch/arm64/kvm/hyp/include/nvhe/gfp.h | 33 ++----- arch/arm64/kvm/hyp/include/nvhe/mem_protect.h | 2 +- arch/arm64/kvm/hyp/include/nvhe/memory.h | 7 +- arch/arm64/kvm/hyp/include/nvhe/mm.h | 13 +-- arch/arm64/kvm/hyp/nvhe/mem_protect.c | 59 +++++++------ arch/arm64/kvm/hyp/nvhe/page_alloc.c | 87 ++++++++++++------- arch/arm64/kvm/hyp/nvhe/setup.c | 30 ++++--- arch/arm64/kvm/hyp/reserved_mem.c | 3 +- 8 files changed, 123 insertions(+), 111 deletions(-) -- 2.31.1.818.g46aad6cb9e-goog _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel