Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp3000955iog; Mon, 20 Jun 2022 09:06:05 -0700 (PDT) X-Google-Smtp-Source: AGRyM1vN8uiuBzd2mL5BudPll1OHP8qgBSdsSndyov7nErAkbU54lRtZ5npOY0wwh3P6Z7tQi5+d X-Received: by 2002:a17:907:6e01:b0:704:8c0e:872f with SMTP id sd1-20020a1709076e0100b007048c0e872fmr21394549ejc.387.1655741165165; Mon, 20 Jun 2022 09:06:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1655741165; cv=none; d=google.com; s=arc-20160816; b=qEoxyusQJI295rXAVGyOwWFAahCQ3RRNsax+NMCRjROZrnBNEsqwz2RN2DtP1xzU62 eB3eerXes2aWoB1Qwu1iJ4K0v5GLQu8pcsYUmEj6tdMG6kGonOhZMitEjw6pumYREeol Rw4Nk6YHIQuhjfdSR4ASrt/GxMnLFgobwqhH2C5QIQE+oXE2De2mDbx559u20jM7D1sS f7MQpCF+KNvTiAc0FpN4F/Alb2iSPhbcpfxz1vALD9zwBZR2jpYghL19deEvBBnck1aj yvLmCjSv8bmxcUA1b7gF9oTOcQme2My8hYnH2LfIq+1z5418ihl9/wtk59h9Woo4GIwj YsuA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:message-id:date:subject:cc:to:from :dkim-signature; bh=BxFmrRIa+vekezXU2ndkJI53IFxQQRuwCL2hgCyh3rI=; b=ndWwVgyV+I0YEP5vC7Y51nrGh7WFdh6d74LmmtiQgzUwv/Mn6L3dkkP1UVHn39w8X3 Mj8znzB2CI3tq6zVrqVNosyCEBIssyh1ZS1f7nu0bDngW5K1ykwtfm0QtQnoKD19dXR/ M9E1vxFPb7c9eqMccsTp6JVWo7bZKmAgWq4qtSecjXEHQup8tlAQpukGwM43sX2qRsPu g1p2wkBkYJGCvm95danTrhqXG4HrOhhNK0fg9RUS/75tJAHMkw+J/yWv3eoWabqmRgK5 EHVN27pkRIVdlG1uRvI6cRizFYegbdgkwxqj31VDRy0D1rAT3ttoWfB55ldkAGeN2du1 pSZg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=EE5uYpfU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id c8-20020a50e3c8000000b004356a5f330fsi10058117edm.445.2022.06.20.09.05.36; Mon, 20 Jun 2022 09:06:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=EE5uYpfU; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241427AbiFTPtH (ORCPT + 99 others); Mon, 20 Jun 2022 11:49:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48220 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229653AbiFTPtF (ORCPT ); Mon, 20 Jun 2022 11:49:05 -0400 Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C02AA1BEA0 for ; Mon, 20 Jun 2022 08:49:02 -0700 (PDT) Received: by mail-lf1-x12a.google.com with SMTP id a2so17917928lfg.5 for ; Mon, 20 Jun 2022 08:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:date:message-id; bh=BxFmrRIa+vekezXU2ndkJI53IFxQQRuwCL2hgCyh3rI=; b=EE5uYpfUwbW+yhCsitbDozwmKkNg4mpG4ZQahK3XlYeTGhDYoqvVpHCoT5xzpURTcc cjNo0lfLdmeVJ5IQ69SU5T0l5SyOsyTVRZ/JsJgYtYepPqmK4x7OlqRlJs6A+dxXh09z TyqSN8Ltk0iX1VNgQ3wwi4LxxDz9REMLqH6/vXtkx6JVA0buOi5ldRHYWRVIGBavD/oT b8au3yNt/IwMuIePkU8N12rbDfxXhc9SDjRLMjVsdttQ2o7IWrpQ6oW1nDpitO/31dHU cYm9lqncdKbu0sq+m+mFIPb1hRuVEeWq3M4mVzMtBEQ9S3WQW6hoqAGucaMBRHAv9N8q VRjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=BxFmrRIa+vekezXU2ndkJI53IFxQQRuwCL2hgCyh3rI=; b=wvVBTNyT95rMv3aSaclinNsxiUg9RcBoMNdrXwCVHAmZ/zZqZLvduNfCKIz35HOAqe fvhQ7iguo6vp/SfJoaIO1nz5sR8SI9QXGVgR4L67J+/H2161h1squlFE6LRliS0BKsmt I+zI8xhzMzchq0nx/72L/QIG2QQyg4H5UB2ucL5l4mysAhaVnqxOHMYizg/1tQclOdxd OlapqeqqwlSVeB+RtJIxPuDuW0DajxuZ1nFpSTfoL9I19z9X85EY03iy/sahXCgCjokY YyYNdASUB9nqfQikYWT5zKNQYfCsTnp+nlR03hR/EbTHdqp5BaK64bZM/W82JcC+v0m/ Ss9Q== X-Gm-Message-State: AJIora9yFgtzFh8eUDtJyQYEdpK9Q1kJCyGh1TiOGQbypBU9QVKRJrNg eW9aoxxb95ziL8mrpO6yDYp4qyenmFs= X-Received: by 2002:a05:6512:228c:b0:479:2fa9:6773 with SMTP id f12-20020a056512228c00b004792fa96773mr13621418lfu.413.1655740140978; Mon, 20 Jun 2022 08:49:00 -0700 (PDT) Received: from otyshchenko.router ([212.22.223.21]) by smtp.gmail.com with ESMTPSA id m9-20020a2e9349000000b0024f3d1dae94sm1690149ljh.28.2022.06.20.08.48.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Jun 2022 08:49:00 -0700 (PDT) From: Oleksandr Tyshchenko To: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org Cc: Oleksandr Tyshchenko , Stefano Stabellini , Juergen Gross , Julien Grall Subject: [PATCH V1 0/2] Ability to allocate contiguous (was DMAable) pages using unpopulated-alloc Date: Mon, 20 Jun 2022 18:48:54 +0300 Message-Id: <1655740136-3974-1-git-send-email-olekstysh@gmail.com> X-Mailer: git-send-email 2.7.4 X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Oleksandr Tyshchenko Hello all. You can find previous discussion at [1]. The purpose of this patch series is to get feedback about supporting the allocation of contiguous pages by Linux's unpopulated-alloc. The unpopulated-alloc feature has been enabled on Arm since the extended-regions support reached upstream. With that (if, of course, we run new Xen version and Xen was able to allocate extended regions), we don't allocate the real RAM pages from host memory and balloon them out (in order to obtain physical memory space to map the guest pages into) anymore, we use the unpopulated pages instead. And it seems that all users I have played with on Arm (I mean, Xen PV and virtio backends) are happy with the pages provided by xen_alloc_unpopulated_pages(). It is worth mentioning that these pages are not contiguous, but this wasn't an issue so far. There is one place, where we still steal RAM pages if user-space Xen PV backend tries to establish grant mapping with a need to be backed by a DMA buffer for the sake of zero-copy (see dma_alloc*() usage in gnttab_dma_alloc_pages()). And, if I am not mistaken (there might be pitfalls which I am not aware of), we could avoid wasting real RAM pages in that particular case also by adding an ability to allocate unpopulated contiguous pages (which are guaranteed to be contiguous in IPA). The benefit is quite clear here: 1. Avoid wasting real RAM pages (reducing the amount of CMA memory usable) for allocating physical memory space to map the granted buffer into (which can be big enough if we deal with Xen PV Display driver using multiple Full HD buffers) 2. Avoid superpage shattering in Xen P2M when establishing stage-2 mapping for that granted buffer 3. Avoid extra operations needed for the granted buffer to be properly mapped and unmapped such as ballooning in/out real RAM pages The corresponding series is located at [2]. In my Arm64 based environment the series works good. Only build tested on x86. Any feedback/help would be highly appreciated. [1] https://lore.kernel.org/xen-devel/1652810658-27810-1-git-send-email-olekstysh@gmail.com/ [2] https://github.com/otyshchenko1/linux/commits/unpopulated-cma1 Oleksandr Tyshchenko (2): xen/unpopulated-alloc: Introduce helpers for contiguous allocations xen/grant-table: Use unpopulated contiguous pages instead of real RAM ones drivers/xen/grant-table.c | 24 +++++ drivers/xen/unpopulated-alloc.c | 188 +++++++++++++++++++++++++++++----------- include/xen/xen.h | 20 +++++ 3 files changed, 182 insertions(+), 50 deletions(-) -- 2.7.4