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
WARNING: multiple messages have this Message-ID (diff)
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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply other threads:[~2023-09-07 18:15 UTC|newest] Thread overview: 110+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-09-07 18:14 ankita [this message] 2023-09-07 18:14 ` [PATCH v1 0/2] KVM: arm64: support write combining and cachable IO memory in VMs ankita 2023-09-07 18:14 ` [PATCH v1 1/2] KVM: arm64: determine memory type from VMA ankita 2023-09-07 18:14 ` ankita 2023-09-07 19:12 ` Jason Gunthorpe 2023-09-07 19:12 ` Jason Gunthorpe 2023-10-05 16:15 ` Catalin Marinas 2023-10-05 16:15 ` Catalin Marinas 2023-10-05 16:54 ` Jason Gunthorpe 2023-10-05 16:54 ` Jason Gunthorpe 2023-10-10 14:25 ` Catalin Marinas 2023-10-10 14:25 ` Catalin Marinas 2023-10-10 15:05 ` Jason Gunthorpe 2023-10-10 15:05 ` Jason Gunthorpe 2023-10-10 17:19 ` Catalin Marinas 2023-10-10 17:19 ` Catalin Marinas 2023-10-10 18:23 ` Jason Gunthorpe 2023-10-10 18:23 ` Jason Gunthorpe 2023-10-11 17:45 ` Catalin Marinas 2023-10-11 17:45 ` Catalin Marinas 2023-10-11 18:38 ` Jason Gunthorpe 2023-10-11 18:38 ` Jason Gunthorpe 2023-10-12 16:16 ` Catalin Marinas 2023-10-12 16:16 ` Catalin Marinas 2024-03-10 3:49 ` Ankit Agrawal 2024-03-10 3:49 ` Ankit Agrawal 2024-03-19 13:38 ` Jason Gunthorpe 2024-03-19 13:38 ` Jason Gunthorpe 2023-10-23 13:20 ` Shameerali Kolothum Thodi 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-07 18:14 ` ankita 2023-09-08 16:40 ` Catalin Marinas 2023-09-08 16:40 ` Catalin Marinas 2023-09-11 14:57 ` Lorenzo Pieralisi 2023-09-11 14:57 ` Lorenzo Pieralisi 2023-09-11 17:20 ` Jason Gunthorpe 2023-09-11 17:20 ` Jason Gunthorpe 2023-09-13 15:26 ` Lorenzo Pieralisi 2023-09-13 15:26 ` Lorenzo Pieralisi 2023-09-13 18:54 ` Jason Gunthorpe 2023-09-13 18:54 ` Jason Gunthorpe 2023-09-26 8:31 ` Lorenzo Pieralisi 2023-09-26 8:31 ` Lorenzo Pieralisi 2023-09-26 12:25 ` Jason Gunthorpe 2023-09-26 12:25 ` Jason Gunthorpe 2023-09-26 13:52 ` Catalin Marinas 2023-09-26 13:52 ` Catalin Marinas 2023-09-26 16:12 ` Lorenzo Pieralisi 2023-09-26 16:12 ` Lorenzo Pieralisi 2023-10-05 9:56 ` Lorenzo Pieralisi 2023-10-05 9:56 ` Lorenzo Pieralisi 2023-10-05 11:56 ` Jason Gunthorpe 2023-10-05 11:56 ` Jason Gunthorpe 2023-10-05 14:08 ` Lorenzo Pieralisi 2023-10-05 14:08 ` Lorenzo Pieralisi 2023-10-12 12:35 ` Will Deacon 2023-10-12 12:35 ` Will Deacon 2023-10-12 13:20 ` Jason Gunthorpe 2023-10-12 13:20 ` Jason Gunthorpe 2023-10-12 14:29 ` Lorenzo Pieralisi 2023-10-12 14:29 ` Lorenzo Pieralisi 2023-10-12 13:53 ` Catalin Marinas 2023-10-12 13:53 ` Catalin Marinas 2023-10-12 14:48 ` Will Deacon 2023-10-12 14:48 ` Will Deacon 2023-10-12 15:44 ` Jason Gunthorpe 2023-10-12 15:44 ` Jason Gunthorpe 2023-10-12 16:39 ` Will Deacon 2023-10-12 16:39 ` Will Deacon 2023-10-12 18:36 ` Jason Gunthorpe 2023-10-12 18:36 ` Jason Gunthorpe 2023-10-13 9:29 ` Will Deacon 2023-10-13 9:29 ` Will Deacon 2023-10-12 17:26 ` Catalin Marinas 2023-10-12 17:26 ` Catalin Marinas 2023-10-13 9:29 ` Will Deacon 2023-10-13 9:29 ` Will Deacon 2023-10-13 13:08 ` Catalin Marinas 2023-10-13 13:08 ` Catalin Marinas 2023-10-13 13:45 ` Jason Gunthorpe 2023-10-13 13:45 ` Jason Gunthorpe 2023-10-19 11:07 ` Catalin Marinas 2023-10-19 11:07 ` Catalin Marinas 2023-10-19 11:51 ` Jason Gunthorpe 2023-10-19 11:51 ` Jason Gunthorpe 2023-10-20 11:21 ` Catalin Marinas 2023-10-20 11:21 ` Catalin Marinas 2023-10-20 11:47 ` Jason Gunthorpe 2023-10-20 11:47 ` Jason Gunthorpe 2023-10-20 14:03 ` Lorenzo Pieralisi 2023-10-20 14:03 ` Lorenzo Pieralisi 2023-10-20 14:28 ` Jason Gunthorpe 2023-10-20 14:28 ` Jason Gunthorpe 2023-10-19 13:35 ` Lorenzo Pieralisi 2023-10-19 13:35 ` Lorenzo Pieralisi 2023-10-13 15:28 ` Lorenzo Pieralisi 2023-10-13 15:28 ` Lorenzo Pieralisi 2023-10-19 11:12 ` Catalin Marinas 2023-10-19 11:12 ` Catalin Marinas 2023-11-09 15:34 ` Lorenzo Pieralisi 2023-11-09 15:34 ` Lorenzo Pieralisi 2023-11-10 14:26 ` Jason Gunthorpe 2023-11-10 14:26 ` Jason Gunthorpe 2023-11-13 0:42 ` Lorenzo Pieralisi 2023-11-13 0:42 ` Lorenzo Pieralisi 2023-11-13 17:41 ` Catalin Marinas 2023-11-13 17:41 ` Catalin Marinas 2023-10-12 12:27 ` Will Deacon 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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.