Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp94563iob; Tue, 17 May 2022 19:57:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxUud06O4a5xM3s2cCwrXnOm2ZIVGduTqWARG7rcYuX1fxCsLmuyJ590UFI6xbA0Gmr0S3d X-Received: by 2002:a17:90a:b703:b0:1dd:1e2f:97d7 with SMTP id l3-20020a17090ab70300b001dd1e2f97d7mr39373736pjr.62.1652842666203; Tue, 17 May 2022 19:57:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652842666; cv=none; d=google.com; s=arc-20160816; b=Yj/9rIx4dcjrBqLq260iLnqeWaFvScEvGTPUxNO89B0WgNb9j0s14M72eAizQBXpRi D5kzp+52rLU/fQ68qlOuLBuAsZRsjNQOmB2aczUq3W0fE9/+peelG2kCJNwTEjdXTY2u qJm681QkOp/s3Kj1mSDEPyyQTUBAoklrlcG1ByOgOQbb1zCGqhLFsycHhhGQFQf1ScQ1 7530oR/U6HxNsEorkQNArNsWebsmNsiRK4dWK4SOS24DbMqZaOwKVx+/zpFCtE8ZFXXC gSzH0Y/xnc2gKjdrr3cBb0kKEGJOly6kxBkfuEfJootyHex9blZnNaonxjSsxvay4Y4I DPmg== 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=EKSmnvJVRKuNiorxmh6RKpW9+C+oBWZuirhwngUpiFA=; b=M+nIluSo50nKGxXLFa5gjLeQjjKQHRaul3aGIjlGGhOuq6qd8FTRSBGzo8eT9VCs8b gaFhwyEkB9XEOso1ahWEsw8HeuVG5UWq5XvBRr26jeuv8LAa9c/7bovXN/NDMe3GcO3S Vfn8q8whoEMmZIF9GdCBWCZzwWJTRos2PHHX9MvWVF9JbdnA7oayNtwy+pNUDoxgYcyz rhZaIcHcr5o/1oiB2ale5UwNSKrbA+gtA/Xe5ny+zAyADnxqbblVCJiy8H6zqe5fP6e5 /GrWpmFOpxFw23l/K+pH1ACNOjyVZkEdflJ3S9LLMIkiNvKncv20EHqIZj+ZB1y/NBoV EFtg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=d8XJLJsZ; 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 x17-20020a631711000000b003f24d6ac522si1077495pgl.8.2022.05.17.19.57.34; Tue, 17 May 2022 19:57:46 -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=d8XJLJsZ; 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 S1351926AbiEQSFl (ORCPT + 99 others); Tue, 17 May 2022 14:05:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40678 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1351895AbiEQSF0 (ORCPT ); Tue, 17 May 2022 14:05:26 -0400 Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2F67251582 for ; Tue, 17 May 2022 11:04:31 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id p189so10866511wmp.3 for ; Tue, 17 May 2022 11:04:31 -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=EKSmnvJVRKuNiorxmh6RKpW9+C+oBWZuirhwngUpiFA=; b=d8XJLJsZpEXABv6ZORuvVlkZV/eZ0n5QWvVfV1Il8MFmUInxoYkMl3Kmq2wMRGnu/Y tGbJqIujPWUGCNgZ/tqGy1+5cJlA7oXSk+0oDV1jG1oZ7o9gkyVG9ATGIB0RjMTRhhL3 OB76y7+GsffV/CyOU75jAwBwYjMFeWYOacizhtdmid6sisM4pzfceqYcyTq1aNYQkZ42 XcUOTZerZ4FvdaSvcQx0+uErEOW1VaA0Js5mUP10jFw0gcH5pu2DuTZ4HlBZo/OWP7lq bUhyWznZSNRpzW/t/T6xXZf95iBXy/9wwFuCzKZcv/KtEhRZzwvHKypq/MhU7fck63m3 Gdxw== 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=EKSmnvJVRKuNiorxmh6RKpW9+C+oBWZuirhwngUpiFA=; b=2blnNmERAldlNgAf/dEtDb7YHJQOPDWqzmIMRhdK82Ld0IA1h3W0FfEco7ZdwMzbzc LfzzQM4dfm3+zeRUn75nP49DutBqkziMBG8+qyH8SQQD9xKjkifcJmrzX79qrNSLXtZ3 nX3XhWP75qtWKxSmp17ZOhuhHHkgaejyCMfBHvwYHXxJhwWuYuCXx41eFizTxoBLiST6 oan6lKFw8zjwKmFFbS8kQqJiWJpd/T8oFVbOnDiVDsLLS+Fr5oT1oe5kGnCGYxFTPdq6 N0hyu6hEF12JNCv1Pn1sK2tf/XPTYQ586f8+L7v03mi3jzLE+ZDBvaOcsa77XPdkfZXD nprg== X-Gm-Message-State: AOAM533B4OGkm0QIJOCqrPkvtyu0TsvkoSCUh30VmSgG9lmeKN6TBYqG wknBrswu16vM67BdEDk16Ym6JWGleJk= X-Received: by 2002:a05:600c:3caa:b0:394:8fb8:716 with SMTP id bg42-20020a05600c3caa00b003948fb80716mr32758904wmb.105.1652810670151; Tue, 17 May 2022 11:04:30 -0700 (PDT) Received: from otyshchenko.router ([212.22.223.21]) by smtp.gmail.com with ESMTPSA id c3-20020adfc6c3000000b0020c5253d8dasm12978625wrh.38.2022.05.17.11.04.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 May 2022 11:04:29 -0700 (PDT) From: Oleksandr Tyshchenko To: xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org Cc: Oleksandr Tyshchenko , Stefano Stabellini , Boris Ostrovsky , Juergen Gross , Julien Grall Subject: [RFC PATCH 0/2] Ability to allocate DMAable pages using unpopulated-alloc Date: Tue, 17 May 2022 21:04:16 +0300 Message-Id: <1652810658-27810-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. The purpose of this RFC patch series is to get feedback about supporting the allocation of DMAable 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 DMAable 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 Please note, there are several TODOs (described in corresponding commit subjects), which I will try to eliminate in next versions if we find a common ground regarding the approach. Any feedback/help would be highly appreciated. Oleksandr Tyshchenko (2): xen/unpopulated-alloc: Introduce helpers for DMA allocations xen/grant-table: Use unpopulated DMAable pages instead of real RAM ones drivers/xen/grant-table.c | 27 +++++++ drivers/xen/unpopulated-alloc.c | 167 ++++++++++++++++++++++++++++++++++++++++ include/xen/xen.h | 15 ++++ 3 files changed, 209 insertions(+) -- 2.7.4