--- /dev/null
+From c0a454b9044fdc99486853aa424e5b3be2107078 Mon Sep 17 00:00:00 2001
+From: Mark Brown <broonie@kernel.org>
+Date: Mon, 5 Sep 2022 15:22:55 +0100
+Subject: arm64/bti: Disable in kernel BTI when cross section thunks are broken
+
+From: Mark Brown <broonie@kernel.org>
+
+commit c0a454b9044fdc99486853aa424e5b3be2107078 upstream.
+
+GCC does not insert a `bti c` instruction at the beginning of a function
+when it believes that all callers reach the function through a direct
+branch[1]. Unfortunately the logic it uses to determine this is not
+sufficiently robust, for example not taking account of functions being
+placed in different sections which may be loaded separately, so we may
+still see thunks being generated to these functions. If that happens,
+the first instruction in the callee function will result in a Branch
+Target Exception due to the missing landing pad.
+
+While this has currently only been observed in the case of modules
+having their main code loaded sufficiently far from their init section
+to require thunks it could potentially happen for other cases so the
+safest thing is to disable BTI for the kernel when building with an
+affected toolchain.
+
+[1]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671
+
+Reported-by: D Scott Phillips <scott@os.amperecomputing.com>
+[Bits of the commit message are lifted from his report & workaround]
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Link: https://lore.kernel.org/r/20220905142255.591990-1-broonie@kernel.org
+Cc: <stable@vger.kernel.org> # v5.10+
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/arm64/Kconfig | 2 ++
+ 1 file changed, 2 insertions(+)
+
+--- a/arch/arm64/Kconfig
++++ b/arch/arm64/Kconfig
+@@ -1884,6 +1884,8 @@ config ARM64_BTI_KERNEL
+ depends on CC_HAS_BRANCH_PROT_PAC_RET_BTI
+ # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94697
+ depends on !CC_IS_GCC || GCC_VERSION >= 100100
++ # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106671
++ depends on !CC_IS_GCC
+ # https://github.com/llvm/llvm-project/commit/a88c722e687e6780dcd6a58718350dc76fcc4cc9
+ depends on !CC_IS_CLANG || CLANG_VERSION >= 120000
+ depends on (!FUNCTION_GRAPH_TRACER || DYNAMIC_FTRACE_WITH_REGS)
--- /dev/null
+From 2380f1e8195ef612deea1dc7a3d611c5d2b9b56a Mon Sep 17 00:00:00 2001
+From: Jason Gunthorpe <jgg@nvidia.com>
+Date: Fri, 9 Sep 2022 16:46:31 -0300
+Subject: iommu: Fix false ownership failure on AMD systems with PASID activated
+
+From: Jason Gunthorpe <jgg@nvidia.com>
+
+commit 2380f1e8195ef612deea1dc7a3d611c5d2b9b56a upstream.
+
+The AMD IOMMU driver cannot activate PASID mode on a RID without the RID's
+translation being set to IDENTITY. Further it requires changing the RID's
+page table layout from the normal v1 IOMMU_DOMAIN_IDENTITY layout to a
+different v2 layout.
+
+It does this by creating a new iommu_domain, configuring that domain for
+v2 identity operation and then attaching it to the group, from within the
+driver. This logic assumes the group is already set to the IDENTITY domain
+and is being used by the DMA API.
+
+However, since the ownership logic is based on the group's domain pointer
+equaling the default domain to detect DMA API ownership, this causes it to
+look like the group is not attached to the DMA API any more. This blocks
+attaching drivers to any other devices in the group.
+
+In a real system this manifests itself as the HD-audio devices on some AMD
+platforms losing their device drivers.
+
+Work around this unique behavior of the AMD driver by checking for
+equality of IDENTITY domains based on their type, not their pointer
+value. This allows the AMD driver to have two IDENTITY domains for
+internal purposes without breaking the check.
+
+Have the AMD driver properly declare that the special domain it created is
+actually an IDENTITY domain.
+
+Cc: Robin Murphy <robin.murphy@arm.com>
+Cc: stable@vger.kernel.org
+Fixes: 512881eacfa7 ("bus: platform,amba,fsl-mc,PCI: Add device DMA ownership management")
+Reported-by: Takashi Iwai <tiwai@suse.de>
+Tested-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
+Reviewed-by: Robin Murphy <robin.murphy@arm.com>
+Link: https://lore.kernel.org/r/0-v1-ea566e16b06b+811-amd_owner_jgg@nvidia.com
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iommu/amd/iommu_v2.c | 2 ++
+ drivers/iommu/iommu.c | 21 +++++++++++++++++++--
+ 2 files changed, 21 insertions(+), 2 deletions(-)
+
+--- a/drivers/iommu/amd/iommu_v2.c
++++ b/drivers/iommu/amd/iommu_v2.c
+@@ -786,6 +786,8 @@ int amd_iommu_init_device(struct pci_dev
+ if (dev_state->domain == NULL)
+ goto out_free_states;
+
++ /* See iommu_is_default_domain() */
++ dev_state->domain->type = IOMMU_DOMAIN_IDENTITY;
+ amd_iommu_domain_direct_map(dev_state->domain);
+
+ ret = amd_iommu_domain_enable_v2(dev_state->domain, pasids);
+--- a/drivers/iommu/iommu.c
++++ b/drivers/iommu/iommu.c
+@@ -3089,6 +3089,24 @@ out:
+ return ret;
+ }
+
++static bool iommu_is_default_domain(struct iommu_group *group)
++{
++ if (group->domain == group->default_domain)
++ return true;
++
++ /*
++ * If the default domain was set to identity and it is still an identity
++ * domain then we consider this a pass. This happens because of
++ * amd_iommu_init_device() replacing the default idenytity domain with an
++ * identity domain that has a different configuration for AMDGPU.
++ */
++ if (group->default_domain &&
++ group->default_domain->type == IOMMU_DOMAIN_IDENTITY &&
++ group->domain && group->domain->type == IOMMU_DOMAIN_IDENTITY)
++ return true;
++ return false;
++}
++
+ /**
+ * iommu_device_use_default_domain() - Device driver wants to handle device
+ * DMA through the kernel DMA API.
+@@ -3107,8 +3125,7 @@ int iommu_device_use_default_domain(stru
+
+ mutex_lock(&group->mutex);
+ if (group->owner_cnt) {
+- if (group->domain != group->default_domain ||
+- group->owner) {
++ if (group->owner || !iommu_is_default_domain(group)) {
+ ret = -EBUSY;
+ goto unlock_out;
+ }
--- /dev/null
+From 91c98fe7941499e4127cdc359c30841b873dd43a Mon Sep 17 00:00:00 2001
+From: Jean-Philippe Brucker <jean-philippe@linaro.org>
+Date: Thu, 25 Aug 2022 16:46:24 +0100
+Subject: iommu/virtio: Fix interaction with VFIO
+
+From: Jean-Philippe Brucker <jean-philippe@linaro.org>
+
+commit 91c98fe7941499e4127cdc359c30841b873dd43a upstream.
+
+Commit e8ae0e140c05 ("vfio: Require that devices support DMA cache
+coherence") requires IOMMU drivers to advertise
+IOMMU_CAP_CACHE_COHERENCY, in order to be used by VFIO. Since VFIO does
+not provide to userspace the ability to maintain coherency through cache
+invalidations, it requires hardware coherency. Advertise the capability
+in order to restore VFIO support.
+
+The meaning of IOMMU_CAP_CACHE_COHERENCY also changed from "IOMMU can
+enforce cache coherent DMA transactions" to "IOMMU_CACHE is supported".
+While virtio-iommu cannot enforce coherency (of PCIe no-snoop
+transactions), it does support IOMMU_CACHE.
+
+We can distinguish different cases of non-coherent DMA:
+
+(1) When accesses from a hardware endpoint are not coherent. The host
+ would describe such a device using firmware methods ('dma-coherent'
+ in device-tree, '_CCA' in ACPI), since they are also needed without
+ a vIOMMU. In this case mappings are created without IOMMU_CACHE.
+ virtio-iommu doesn't need any additional support. It sends the same
+ requests as for coherent devices.
+
+(2) When the physical IOMMU supports non-cacheable mappings. Supporting
+ those would require a new feature in virtio-iommu, new PROBE request
+ property and MAP flags. Device drivers would use a new API to
+ discover this since it depends on the architecture and the physical
+ IOMMU.
+
+(3) When the hardware supports PCIe no-snoop. It is possible for
+ assigned PCIe devices to issue no-snoop transactions, and the
+ virtio-iommu specification is lacking any mention of this.
+
+ Arm platforms don't necessarily support no-snoop, and those that do
+ cannot enforce coherency of no-snoop transactions. Device drivers
+ must be careful about assuming that no-snoop transactions won't end
+ up cached; see commit e02f5c1bb228 ("drm: disable uncached DMA
+ optimization for ARM and arm64"). On x86 platforms, the host may or
+ may not enforce coherency of no-snoop transactions with the physical
+ IOMMU. But according to the above commit, on x86 a driver which
+ assumes that no-snoop DMA is compatible with uncached CPU mappings
+ will also work if the host enforces coherency.
+
+ Although these issues are not specific to virtio-iommu, it could be
+ used to facilitate discovery and configuration of no-snoop. This
+ would require a new feature bit, PROBE property and ATTACH/MAP
+ flags.
+
+Cc: stable@vger.kernel.org
+Fixes: e8ae0e140c05 ("vfio: Require that devices support DMA cache coherence")
+Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
+Reviewed-by: Robin Murphy <robin.murphy@arm.com>
+Link: https://lore.kernel.org/r/20220825154622.86759-1-jean-philippe@linaro.org
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iommu/virtio-iommu.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+diff --git a/drivers/iommu/virtio-iommu.c b/drivers/iommu/virtio-iommu.c
+index 08eeafc9529f..80151176ba12 100644
+--- a/drivers/iommu/virtio-iommu.c
++++ b/drivers/iommu/virtio-iommu.c
+@@ -1006,7 +1006,18 @@ static int viommu_of_xlate(struct device *dev, struct of_phandle_args *args)
+ return iommu_fwspec_add_ids(dev, args->args, 1);
+ }
+
++static bool viommu_capable(enum iommu_cap cap)
++{
++ switch (cap) {
++ case IOMMU_CAP_CACHE_COHERENCY:
++ return true;
++ default:
++ return false;
++ }
++}
++
+ static struct iommu_ops viommu_ops = {
++ .capable = viommu_capable,
+ .domain_alloc = viommu_domain_alloc,
+ .probe_device = viommu_probe_device,
+ .probe_finalize = viommu_probe_finalize,
+--
+2.37.3
+
--- /dev/null
+From 53fc7ad6edf210b497230ce74b61b322a202470c Mon Sep 17 00:00:00 2001
+From: Lu Baolu <baolu.lu@linux.intel.com>
+Date: Tue, 23 Aug 2022 14:15:55 +0800
+Subject: iommu/vt-d: Correctly calculate sagaw value of IOMMU
+
+From: Lu Baolu <baolu.lu@linux.intel.com>
+
+commit 53fc7ad6edf210b497230ce74b61b322a202470c upstream.
+
+The Intel IOMMU driver possibly selects between the first-level and the
+second-level translation tables for DMA address translation. However,
+the levels of page-table walks for the 4KB base page size are calculated
+from the SAGAW field of the capability register, which is only valid for
+the second-level page table. This causes the IOMMU driver to stop working
+if the hardware (or the emulated IOMMU) advertises only first-level
+translation capability and reports the SAGAW field as 0.
+
+This solves the above problem by considering both the first level and the
+second level when calculating the supported page table levels.
+
+Fixes: b802d070a52a1 ("iommu/vt-d: Use iova over first level")
+Cc: stable@vger.kernel.org
+Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
+Link: https://lore.kernel.org/r/20220817023558.3253263-1-baolu.lu@linux.intel.com
+Signed-off-by: Joerg Roedel <jroedel@suse.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/iommu/intel/iommu.c | 28 +++++++++++++++++++++++++---
+ 1 file changed, 25 insertions(+), 3 deletions(-)
+
+--- a/drivers/iommu/intel/iommu.c
++++ b/drivers/iommu/intel/iommu.c
+@@ -422,14 +422,36 @@ static inline int domain_pfn_supported(s
+ return !(addr_width < BITS_PER_LONG && pfn >> addr_width);
+ }
+
++/*
++ * Calculate the Supported Adjusted Guest Address Widths of an IOMMU.
++ * Refer to 11.4.2 of the VT-d spec for the encoding of each bit of
++ * the returned SAGAW.
++ */
++static unsigned long __iommu_calculate_sagaw(struct intel_iommu *iommu)
++{
++ unsigned long fl_sagaw, sl_sagaw;
++
++ fl_sagaw = BIT(2) | (cap_fl1gp_support(iommu->cap) ? BIT(3) : 0);
++ sl_sagaw = cap_sagaw(iommu->cap);
++
++ /* Second level only. */
++ if (!sm_supported(iommu) || !ecap_flts(iommu->ecap))
++ return sl_sagaw;
++
++ /* First level only. */
++ if (!ecap_slts(iommu->ecap))
++ return fl_sagaw;
++
++ return fl_sagaw & sl_sagaw;
++}
++
+ static int __iommu_calculate_agaw(struct intel_iommu *iommu, int max_gaw)
+ {
+ unsigned long sagaw;
+ int agaw;
+
+- sagaw = cap_sagaw(iommu->cap);
+- for (agaw = width_to_agaw(max_gaw);
+- agaw >= 0; agaw--) {
++ sagaw = __iommu_calculate_sagaw(iommu);
++ for (agaw = width_to_agaw(max_gaw); agaw >= 0; agaw--) {
+ if (test_bit(agaw, &sagaw))
+ break;
+ }
hwmon-asus-ec-sensors-add-missing-sensors-for-x570-i.patch
hwmon-asus-ec-sensors-add-definitions-for-rog-zenith.patch
hwmon-asus-ec-sensors-autoload-module-via-dmi-data.patch
+arm64-bti-disable-in-kernel-bti-when-cross-section-thunks-are-broken.patch
+iommu-vt-d-correctly-calculate-sagaw-value-of-iommu.patch
+iommu-virtio-fix-interaction-with-vfio.patch
+iommu-fix-false-ownership-failure-on-amd-systems-with-pasid-activated.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
