From: Zhi Wang <zhiw@nvidia.com>
To: Ankit Agrawal <ankita@nvidia.com>,
Jason Gunthorpe <jgg@nvidia.com>,
"maz@kernel.org" <maz@kernel.org>,
"oliver.upton@linux.dev" <oliver.upton@linux.dev>,
"james.morse@arm.com" <james.morse@arm.com>,
"suzuki.poulose@arm.com" <suzuki.poulose@arm.com>,
"yuzenghui@huawei.com" <yuzenghui@huawei.com>,
"reinette.chatre@intel.com" <reinette.chatre@intel.com>,
"surenb@google.com" <surenb@google.com>,
"stefanha@redhat.com" <stefanha@redhat.com>,
"brauner@kernel.org" <brauner@kernel.org>,
"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
"will@kernel.org" <will@kernel.org>,
"mark.rutland@arm.com" <mark.rutland@arm.com>,
"alex.williamson@redhat.com" <alex.williamson@redhat.com>,
"kevin.tian@intel.com" <kevin.tian@intel.com>,
"yi.l.liu@intel.com" <yi.l.liu@intel.com>,
"ardb@kernel.org" <ardb@kernel.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"andreyknvl@gmail.com" <andreyknvl@gmail.com>,
"wangjinchao@xfusion.com" <wangjinchao@xfusion.com>,
"gshan@redhat.com" <gshan@redhat.com>,
"shahuang@redhat.com" <shahuang@redhat.com>,
"ricarkol@google.com" <ricarkol@google.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"lpieralisi@kernel.org" <lpieralisi@kernel.org>,
"rananta@google.com" <rananta@google.com>,
"ryan.roberts@arm.com" <ryan.roberts@arm.com>,
"david@redhat.com" <david@redhat.com>,
"linus.walleij@linaro.org" <linus.walleij@linaro.org>,
"bhe@redhat.com" <bhe@redhat.com>
Cc: Aniket Agashe <aniketa@nvidia.com>, Neo Jia <cjia@nvidia.com>,
Kirti Wankhede <kwankhede@nvidia.com>,
"Tarun Gupta (SW-GPU)" <targupta@nvidia.com>,
Vikram Sethi <vsethi@nvidia.com>,
Andy Currid <ACurrid@nvidia.com>,
Alistair Popple <apopple@nvidia.com>,
John Hubbard <jhubbard@nvidia.com>,
Dan Williams <danw@nvidia.com>,
"kvmarm@lists.linux.dev" <kvmarm@lists.linux.dev>,
Matt Ochs <mochs@nvidia.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v8 2/4] mm: introduce new flag to indicate wc safe
Date: Tue, 20 Feb 2024 08:26:39 +0000 [thread overview]
Message-ID: <bc5cdc2e-50d8-435a-8f9d-a0053a99598d@nvidia.com> (raw)
In-Reply-To: <20240220072926.6466-3-ankita@nvidia.com>
On 2/20/24 07:29, Ankit Agrawal wrote:
> From: Ankit Agrawal <ankita@nvidia.com>
>
> The VM_ALLOW_ANY_UNCACHED flag is implemented for ARM64, allowing KVM
> stage 2 device mapping attributes to use NormalNC rather than
> DEVICE_nGnRE, which allows guest mappings supporting combining
> attributes (WC). ARM does not architecturally guarantee this is safe,
> and indeed some MMIO regions like the GICv2 VCPU interface can trigger
> uncontained faults if NormalNC is used.
>
> Even worse we expect there are platforms where even DEVICE_nGnRE can
> allow uncontained faults in corner cases. Unfortunately existing ARM IP
> requires platform integration to take responsibility to prevent this.
>
> To safely use VFIO in KVM the platform must guarantee full safety in the
> guest where no action taken against a MMIO mapping can trigger an
> uncontained failure. We belive that most VFIO PCI platforms support this
A nit, let's use passive voice in the patch comment. Also belive is mostly
a typo.
> for both mapping types, at least in common flows, based on some
> expectations of how PCI IP is integrated. This can be enabled more broadly,
> for instance into vfio-platform drivers, but only after the platform
> vendor completes auditing for safety.
>
> The VMA flag VM_ALLOW_ANY_UNCACHED was found to be the simplest and
> cleanest way to communicate the information from VFIO to KVM that
> mapping the region in S2 as NormalNC is safe. KVM consumes it to
> activate the code that does the S2 mapping as NormalNC.
>
> Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
> Acked-by: David Hildenbrand <david@redhat.com>
> Signed-off-by: Ankit Agrawal <ankita@nvidia.com>
> ---
> include/linux/mm.h | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index f5a97dec5169..59576e56c58b 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -391,6 +391,20 @@ extern unsigned int kobjsize(const void *objp);
> # define VM_UFFD_MINOR VM_NONE
> #endif /* CONFIG_HAVE_ARCH_USERFAULTFD_MINOR */
>
> +/*
> + * This flag is used to connect VFIO to arch specific KVM code. It
> + * indicates that the memory under this VMA is safe for use with any
> + * non-cachable memory type inside KVM. Some VFIO devices, on some
> + * platforms, are thought to be unsafe and can cause machine crashes
> + * if KVM does not lock down the memory type.
> + */
> +#ifdef CONFIG_64BIT
> +#define VM_ALLOW_ANY_UNCACHED_BIT 39
> +#define VM_ALLOW_ANY_UNCACHED BIT(VM_ALLOW_ANY_UNCACHED_BIT)
> +#else
> +#define VM_ALLOW_ANY_UNCACHED VM_NONE
> +#endif
> +
> /* Bits set in the VMA until the stack is in its final location */
> #define VM_STACK_INCOMPLETE_SETUP (VM_RAND_READ | VM_SEQ_READ | VM_STACK_EARLY)
>
next prev parent reply other threads:[~2024-02-20 8:26 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-20 7:29 [PATCH v8 0/4] kvm: arm64: allow the VM to select DEVICE_* and NORMAL_NC for IO memory ankita
2024-02-20 7:29 ` [PATCH v8 1/4] kvm: arm64: introduce new flag for non-cacheable " ankita
2024-02-20 12:21 ` Will Deacon
2024-02-20 14:27 ` Lorenzo Pieralisi
2024-02-21 6:01 ` Ankit Agrawal
2024-02-20 7:29 ` [PATCH v8 2/4] mm: introduce new flag to indicate wc safe ankita
2024-02-20 8:26 ` Zhi Wang [this message]
2024-02-20 8:51 ` Ankit Agrawal
2024-02-20 9:07 ` Zhi Wang
2024-02-20 9:08 ` Ankit Agrawal
2024-02-20 9:09 ` David Hildenbrand
2024-02-20 9:33 ` Zhi Wang
2024-02-20 9:40 ` Ankit Agrawal
2024-02-20 7:29 ` [PATCH v8 3/4] kvm: arm64: set io memory s2 pte as normalnc for vfio pci device ankita
2024-02-23 17:07 ` Marc Zyngier
2024-02-20 7:29 ` [PATCH v8 4/4] vfio: convey kvm that the vfio-pci device is wc safe ankita
2024-02-20 9:56 ` Catalin Marinas
2024-02-20 12:11 ` Ankit Agrawal
2024-02-22 20:52 ` Alex Williamson
2024-02-23 17:02 ` [PATCH v8 0/4] kvm: arm64: allow the VM to select DEVICE_* and NORMAL_NC for IO memory Marc Zyngier
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=bc5cdc2e-50d8-435a-8f9d-a0053a99598d@nvidia.com \
--to=zhiw@nvidia.com \
--cc=ACurrid@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=alex.williamson@redhat.com \
--cc=andreyknvl@gmail.com \
--cc=aniketa@nvidia.com \
--cc=ankita@nvidia.com \
--cc=apopple@nvidia.com \
--cc=ardb@kernel.org \
--cc=bhe@redhat.com \
--cc=brauner@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=cjia@nvidia.com \
--cc=danw@nvidia.com \
--cc=david@redhat.com \
--cc=gshan@redhat.com \
--cc=james.morse@arm.com \
--cc=jgg@nvidia.com \
--cc=jhubbard@nvidia.com \
--cc=kevin.tian@intel.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=kwankhede@nvidia.com \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lpieralisi@kernel.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=mochs@nvidia.com \
--cc=oliver.upton@linux.dev \
--cc=rananta@google.com \
--cc=reinette.chatre@intel.com \
--cc=ricarkol@google.com \
--cc=ryan.roberts@arm.com \
--cc=shahuang@redhat.com \
--cc=stefanha@redhat.com \
--cc=surenb@google.com \
--cc=suzuki.poulose@arm.com \
--cc=targupta@nvidia.com \
--cc=vsethi@nvidia.com \
--cc=wangjinchao@xfusion.com \
--cc=will@kernel.org \
--cc=yi.l.liu@intel.com \
--cc=yuzenghui@huawei.com \
/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