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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6CBD3EB64DD for ; Tue, 25 Jul 2023 06:19:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 05DAB8E0002; Tue, 25 Jul 2023 02:19:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 00DBA8E0001; Tue, 25 Jul 2023 02:19:08 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E3F418E0002; Tue, 25 Jul 2023 02:19:08 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id D7CC48E0001 for ; Tue, 25 Jul 2023 02:19:08 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 7CB5040D2B for ; Tue, 25 Jul 2023 06:19:08 +0000 (UTC) X-FDA: 81049131576.16.A6921B0 Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by imf27.hostedemail.com (Postfix) with ESMTP id EACB54000C for ; Tue, 25 Jul 2023 06:19:04 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=none; spf=pass (imf27.hostedemail.com: domain of benh@kernel.crashing.org designates 63.228.1.57 as permitted sender) smtp.mailfrom=benh@kernel.crashing.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1690265946; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=94nkZ9rcgNpb75Jxc03tG2l39VZ0yEQ7ZWGZPbqs4rI=; b=BizC75kBd6YfeOtkEKtmBbNsrWSik2aJVpAqgjAv/8TTSgVHBfxDKF/khFaXZvONiShzNr DLviirH3njC2ynrIzwzHoOyY7a0PiR+ii7W1bBqczfEui4xFLL4l0HnkjaDwTmxfRhaBNa 44iFI3KCa+Sp+J9sdFnMZXiEjgXPBYg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1690265946; a=rsa-sha256; cv=none; b=B14yfQx8eNZ/ZLsS4h6fWrMkN3vV6+qquBkEYYnOfaKCuYOzTgU71ZX+8kZIPe6xZsQkZz q2Z2rzi1eveG9xsxwkYBFZIQaNCGqvcfuS40A7CqOIowgPx54E4W4Ti9s29zgXXFQIyMqI 8w4c4500xImrE/NRtRLkxHLYF6Hw3Zs= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=none; spf=pass (imf27.hostedemail.com: domain of benh@kernel.crashing.org designates 63.228.1.57 as permitted sender) smtp.mailfrom=benh@kernel.crashing.org; dmarc=none Received: from [IPv6:::1] (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 36P6ImRw024173; Tue, 25 Jul 2023 01:18:49 -0500 Message-ID: <0101c83334721e28b603211c427941e8d31ea9d8.camel@kernel.crashing.org> Subject: Re: [PATCH v3 1/6] kvm: determine memory type from VMA From: Benjamin Herrenschmidt To: Alex Williamson , Jason Gunthorpe Cc: Catalin Marinas , Marc Zyngier , ankita@nvidia.com, naoya.horiguchi@nec.com, oliver.upton@linux.dev, aniketa@nvidia.com, cjia@nvidia.com, kwankhede@nvidia.com, targupta@nvidia.com, vsethi@nvidia.com, acurrid@nvidia.com, apopple@nvidia.com, jhubbard@nvidia.com, danw@nvidia.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, Lorenzo Pieralisi , Clint Sbisa , osamaabb@amazon.com Date: Tue, 25 Jul 2023 16:18:48 +1000 In-Reply-To: <20230717123524.0cefedd0.alex.williamson@redhat.com> References: <20230405180134.16932-1-ankita@nvidia.com> <20230405180134.16932-2-ankita@nvidia.com> <86r0spl18x.wl-maz@kernel.org> <67a7374a72053107661ecc2b2f36fdb3ff6cc6ae.camel@kernel.crashing.org> <20230717123524.0cefedd0.alex.williamson@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.44.4-0ubuntu1 MIME-Version: 1.0 X-Rspamd-Queue-Id: EACB54000C X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 1zs1b56e7hhkro7t11j3n1f1jjwhj54t X-HE-Tag: 1690265944-755491 X-HE-Meta: U2FsdGVkX19VdBOE/CcbMHsPy4dQas4d42HyWS8MhBTuGmiie3t21XkG/Hffnl0EYUlDB+snrbNbMLAaKUCVX7X/B0UOWAtrKU0vIU57y3XCeG92bQWz9sh5X1o9m0DuBg1t8OFozIjp1eJjWK74bj9dZC8zVI0RT9bc4Ynxj/jaVkrXBQ/F93UZpt1bIW5g1wegmlYALShS2o3JyF0IwPIYbchNYpRxoxkGO7pN8qLSzwCPj47v02WU3iP31eq0hBRSxqTUhXtK92akc9uFeEwi/xnklSBLfb9sunPXRW0iZNRXPIz3h8aIHdQcvZcKTPerB1cORRyzl+83X7umDv7K9zzZOqzGzhCFykfu5YXkxOOcIpgNxMYDX87vHgAIrq9Bp8XwvQb3FAK8pVdE4Bs2mUujJalPJ/eZ/UeeILm8dMJPy+gh2FSId/u5OYCP9CGr8oYuuOt+iZG0Fh7BEh054sx0vD4kaeIruq7BSqIQaf6pe5uyUau6zWJin1+OpoT6IPBnLYu4xPRMR4zw7cYWL7BMsj1r347HhhhJtj4rjtEgZRNgdyRwDQl0f6hcisMZ2Esqv8qyA8SF+OKax2l3tp/j6SmzjqhDNzVuLZ1v7vMvqXY5ih119RN2abT2K+5g7yohAEPlHc0N5ACRjIhK//qUeSpftpo/kf/vvBHflAt/Kv2vutzi7roYCpKoRRkOm4obQnw3HLobocXa7upMPg+oy6gSheiB46c0uD18kHaV9i+80LjozJSpDvkKw2c4Ai0UzOzGNrS86Yrv/iGQWZ1ZAwsCNVULdSpPIPLEx+j9tBNavEFTo2dSSlNBb1KSZL1BDrJITR1hs3KTAKAVEyQwd7juCDKpNYXCFFXtUx7Q1W57RHVubg5rthReMeuCC/zoTBMD9mePOM3KfsZlP654nsH2PWrukwgDxRBzpJNFDxCdC+vC0yftS+SmLTCX/adpIaPqu6ld/zN IX8+XpgU cx8B8fV11niOVkX47/xFNJ3RLbgDsXKdzaCz/Z3LqqGI0E3AUoLljjLYvHQ2PfsV/9Z31JIh4dXJ9faIZlWCdz72CNkDKRhBfWQKz X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, 2023-07-17 at 12:35 -0600, Alex Williamson wrote: > On Sun, 16 Jul 2023 19:30:23 -0300 > Jason Gunthorpe wrote: >=20 > > On Sun, Jul 16, 2023 at 08:09:02AM -0700, Catalin Marinas wrote: > >=20 > > > In terms of security for arm64 at least, Device vs Normal NC (or nc v= s > > > wc in Linux terminology) doesn't make much difference with the former > > > occasionally being worse. The kernel would probably trust the DPDK co= de > > > if it allows direct device access.=C2=A0=20 > >=20 > > RDMA and DRM already allow device drivers to map WC to userspace on > > demand, we expect the platform to support this. > >=20 > > > > So the userspace component needs to be responsible for selecting th= e > > > > mapping, the same way using the PCI sysfs resource files today allo= ws > > > > to do that by selecting the _wc variant.=C2=A0=20 > > >=20 > > > I guess the sysfs interface is just trying to work around the VFIO > > > limitations.=C2=A0=20 > >=20 > > I think just nobody has ever asked for VFIO WC support. The main > > non-VM user is DPDK and none of the NIC drivers have wanted this (DPDK > > applications areis more of throughput than latency focused typically) >=20 > Yes, QEMU can't know whether the device or driver want a WC BAR > mapping, so we've left it for KVM manipulation relative to VM use > cases.=C2=A0 Nobody has followed through with a complete proposal to enab= le > it otherwise for direct userspace driver access, but I don't think > there's opposition to providing such a thing.=C2=A0 Thanks, Ok, this is really backburner work for me but I'll try to cook up a POC patch in the near (hopefully) future along the lines of the subregions I proposed and we can discuss from there. Cheers, Ben.