From: <ankita@nvidia.com>
To: <ankita@nvidia.com>, <jgg@nvidia.com>, <maz@kernel.org>,
<oliver.upton@linux.dev>, <catalin.marinas@arm.com>,
<will@kernel.org>
Cc: <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>,
<linux-arm-kernel@lists.infradead.org>, <kvmarm@lists.linux.dev>,
<linux-kernel@vger.kernel.org>
Subject: [PATCH v1 0/2] KVM: arm64: support write combining and cachable IO memory in VMs
Date: Thu, 7 Sep 2023 11:14:57 -0700 [thread overview]
Message-ID: <20230907181459.18145-1-ankita@nvidia.com> (raw)
From: Ankit Agrawal <ankita@nvidia.com>
Today KVM forces all of the memory to either NORMAL or DEVICE_nGnRE
largely based on pfn_is_map_memory() and ignores the per-VMA flags
that indicate the memory attributes.
This means there is no way for a VM to get NORMAL_NC IO memory (what
Linux calls WC memory, which is used for performance in certain NIC
and GPU devices). There is also no way for a VM to get cachable IO
memory (like from a CXL or pre-CXL device). In both cases the memory
will be forced to be DEVICE_nGnRE and the VM's memory attributes will
be ignored.
After some discussions with ARM and CPU architects we reached the
conclusion there was no need for KVM to prevent the VM from selecting
between DEVICE_* and NORMAL_NC for IO memory in VMs. There was a fear
that NORMAL_NC could result in uncontained failures, but upon deeper
analysis it turns out there are already possible cases for uncontained
failures with DEVICE types too. Ultimately the platform must be
implemented in a way that ensures that all DEVICE_* and NORMAL_NC
accesses have no uncontained failures.
Fortunately real platforms do tend to implement this.
This is similar to x86 where various BIOS choices can result in
uncontained failures (machine checks in x86 speak) on IO memory. On
either architecture there is no way for KVM to know if the underlying
platform is fully safe or not.
This series expands the assumption that any uncachable IO will not
have any uncontained failures for DEVICE_* and NORMAL_NC and that
cachable IO will not have uncontained failures for NORMAL. We hope ARM
will publish information helping platform designers follow these
guidelines.
Additionally have KVM drive the decision on cachable or not entirely
on the VMA. If the VMA is cachable then the KVM memory is made NORMAL
regardless of pfn_is_map_memory(). This closes a hole where cachable
VMA mappings in a process could be accessed via an uncached alias
through KVM.
Applied over next-20230906
Ankit Agrawal (2):
KVM: arm64: determine memory type from VMA
KVM: arm64: allow the VM to select DEVICE_* and NORMAL_NC for IO
memory
arch/arm64/include/asm/kvm_pgtable.h | 8 ++++++
arch/arm64/include/asm/memory.h | 2 ++
arch/arm64/kvm/hyp/pgtable.c | 4 +--
arch/arm64/kvm/mmu.c | 40 +++++++++++++++++++++++++---
4 files changed, 48 insertions(+), 6 deletions(-)
--
2.17.1
next reply other threads:[~2023-09-07 18:15 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-07 18:14 ankita [this message]
2023-09-07 18:14 ` [PATCH v1 1/2] KVM: arm64: determine memory type from VMA ankita
2023-09-07 19:12 ` Jason Gunthorpe
2023-10-05 16:15 ` Catalin Marinas
2023-10-05 16:54 ` Jason Gunthorpe
2023-10-10 14:25 ` Catalin Marinas
2023-10-10 15:05 ` Jason Gunthorpe
2023-10-10 17:19 ` Catalin Marinas
2023-10-10 18:23 ` Jason Gunthorpe
2023-10-11 17:45 ` Catalin Marinas
2023-10-11 18:38 ` Jason Gunthorpe
2023-10-12 16:16 ` Catalin Marinas
2024-03-10 3:49 ` Ankit Agrawal
2024-03-19 13:38 ` Jason Gunthorpe
2023-10-23 13:20 ` Shameerali Kolothum Thodi
2023-09-07 18:14 ` [PATCH v1 2/2] KVM: arm64: allow the VM to select DEVICE_* and NORMAL_NC for IO memory ankita
2023-09-08 16:40 ` Catalin Marinas
2023-09-11 14:57 ` Lorenzo Pieralisi
2023-09-11 17:20 ` Jason Gunthorpe
2023-09-13 15:26 ` Lorenzo Pieralisi
2023-09-13 18:54 ` Jason Gunthorpe
2023-09-26 8:31 ` Lorenzo Pieralisi
2023-09-26 12:25 ` Jason Gunthorpe
2023-09-26 13:52 ` Catalin Marinas
2023-09-26 16:12 ` Lorenzo Pieralisi
2023-10-05 9:56 ` Lorenzo Pieralisi
2023-10-05 11:56 ` Jason Gunthorpe
2023-10-05 14:08 ` Lorenzo Pieralisi
2023-10-12 12:35 ` Will Deacon
2023-10-12 13:20 ` Jason Gunthorpe
2023-10-12 14:29 ` Lorenzo Pieralisi
2023-10-12 13:53 ` Catalin Marinas
2023-10-12 14:48 ` Will Deacon
2023-10-12 15:44 ` Jason Gunthorpe
2023-10-12 16:39 ` Will Deacon
2023-10-12 18:36 ` Jason Gunthorpe
2023-10-13 9:29 ` Will Deacon
2023-10-12 17:26 ` Catalin Marinas
2023-10-13 9:29 ` Will Deacon
2023-10-13 13:08 ` Catalin Marinas
2023-10-13 13:45 ` Jason Gunthorpe
2023-10-19 11:07 ` Catalin Marinas
2023-10-19 11:51 ` Jason Gunthorpe
2023-10-20 11:21 ` Catalin Marinas
2023-10-20 11:47 ` Jason Gunthorpe
2023-10-20 14:03 ` Lorenzo Pieralisi
2023-10-20 14:28 ` Jason Gunthorpe
2023-10-19 13:35 ` Lorenzo Pieralisi
2023-10-13 15:28 ` Lorenzo Pieralisi
2023-10-19 11:12 ` Catalin Marinas
2023-11-09 15:34 ` Lorenzo Pieralisi
2023-11-10 14:26 ` Jason Gunthorpe
2023-11-13 0:42 ` Lorenzo Pieralisi
2023-11-13 17:41 ` Catalin Marinas
2023-10-12 12:27 ` Will Deacon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230907181459.18145-1-ankita@nvidia.com \
--to=ankita@nvidia.com \
--cc=acurrid@nvidia.com \
--cc=aniketa@nvidia.com \
--cc=apopple@nvidia.com \
--cc=catalin.marinas@arm.com \
--cc=cjia@nvidia.com \
--cc=danw@nvidia.com \
--cc=jgg@nvidia.com \
--cc=jhubbard@nvidia.com \
--cc=kvmarm@lists.linux.dev \
--cc=kwankhede@nvidia.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=oliver.upton@linux.dev \
--cc=targupta@nvidia.com \
--cc=vsethi@nvidia.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).