Re: [PATCH] Revert "iommu/arm-smmu-v3: Decrease the queue size of evtq and priq"
On Tue, 7 Dec 2021 14:32:48 +0800, Zhou Wang wrote: > The commit f115f3c0d5d8 ("iommu/arm-smmu-v3: Decrease the queue size of > evtq and priq") decreases evtq and priq, which may lead evtq/priq to be > full with fault events, e.g HiSilicon ZIP/SEC/HPRE have maximum 1024 queues > in one device, every queue could be binded with one process and trigger a > fault event. So let's revert f115f3c0d5d8. > > In fact, if an implementation of SMMU really does not need so long evtq > and priq, value of IDR1_EVTQS and IDR1_PRIQS can be set to proper ones. > > [...] Applied to will (for-joerg/arm-smmu/updates), thanks! [1/1] Revert "iommu/arm-smmu-v3: Decrease the queue size of evtq and priq" https://git.kernel.org/will/c/477436699e78 Cheers, -- Will https://fixes.arm64.dev https://next.arm64.dev https://will.arm64.dev ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[GIT PULL] iommu/arm-smmu: Updates for 5.17
Hi Joerg, Please pull these Arm SMMU updates for 5.17. Once again, there's not a lot here. In fact, it's mostly a combination of non-critical fixes and DT compatible string additions. Summary in the tag. Cheers, Will --->8 The following changes since commit 0fcfb00b28c0b7884635dacf38e46d60bf3d4eb1: Linux 5.16-rc4 (2021-12-05 14:08:22 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git tags/arm-smmu-updates for you to fetch changes up to 477436699e7801276fa7306e20318156cb535249: Revert "iommu/arm-smmu-v3: Decrease the queue size of evtq and priq" (2021-12-15 10:14:06 +) Arm SMMU updates for 5.17 - Revert evtq and priq back to their former sizes - Return early on short-descriptor page-table allocation failure - Fix page fault reporting for Adreno GPU on SMMUv2 - Make SMMUv3 MMU notifier ops 'const' - Numerous new compatible strings for Qualcomm SMMUv2 implementations David Heidelberg (1): dt-bindings: arm-smmu: Add compatible for the SDX55 SoC Rikard Falkeborn (1): iommu/arm-smmu-v3: Constify arm_smmu_mmu_notifier_ops Rob Clark (1): iommu/arm-smmu-qcom: Fix TTBR0 read Vinod Koul (2): dt-bindings: arm-smmu: Add compatible for SM8450 SoC iommu: arm-smmu-impl: Add SM8450 qcom iommu implementation Yunfei Wang (1): iommu/io-pgtable-arm-v7s: Add error handle for page table allocation failure Zhou Wang (1): Revert "iommu/arm-smmu-v3: Decrease the queue size of evtq and priq" Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 2 ++ drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3-sva.c | 2 +- drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 5 ++--- drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c| 3 ++- drivers/iommu/io-pgtable-arm-v7s.c| 6 +- 5 files changed, 12 insertions(+), 6 deletions(-) ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 04/18] driver core: platform: Add driver dma ownership management
Hi Greg, On 2021/12/13 8:50, Lu Baolu wrote: On 12/10/21 9:23 AM, Lu Baolu wrote: Hi Greg, Jason and Christoph, On 12/9/21 9:20 AM, Lu Baolu wrote: On 12/7/21 9:16 PM, Jason Gunthorpe wrote: On Tue, Dec 07, 2021 at 10:57:25AM +0800, Lu Baolu wrote: On 12/6/21 11:06 PM, Jason Gunthorpe wrote: On Mon, Dec 06, 2021 at 06:36:27AM -0800, Christoph Hellwig wrote: I really hate the amount of boilerplate code that having this in each bus type causes. +1 I liked the first version of this series better with the code near really_probe(). Can we go back to that with some device_configure_dma() wrapper condtionally called by really_probe as we discussed? [...] diff --git a/drivers/base/dd.c b/drivers/base/dd.c index 68ea1f949daa..68ca5a579eb1 100644 --- a/drivers/base/dd.c +++ b/drivers/base/dd.c @@ -538,6 +538,32 @@ static int call_driver_probe(struct device *dev, struct device_driver *drv) return ret; } +static int device_dma_configure(struct device *dev, struct device_driver *drv) +{ + int ret; + + if (!dev->bus->dma_configure) + return 0; + + ret = dev->bus->dma_configure(dev); + if (ret) + return ret; + + if (!drv->suppress_auto_claim_dma_owner) + ret = iommu_device_set_dma_owner(dev, DMA_OWNER_DMA_API, NULL); + + return ret; +} + +static void device_dma_cleanup(struct device *dev, struct device_driver *drv) +{ + if (!dev->bus->dma_configure) + return; + + if (!drv->suppress_auto_claim_dma_owner) + iommu_device_release_dma_owner(dev, DMA_OWNER_DMA_API); +} + static int really_probe(struct device *dev, struct device_driver *drv) { bool test_remove = IS_ENABLED(CONFIG_DEBUG_TEST_DRIVER_REMOVE) && @@ -574,11 +600,8 @@ static int really_probe(struct device *dev, struct device_driver *drv) if (ret) goto pinctrl_bind_failed; - if (dev->bus->dma_configure) { - ret = dev->bus->dma_configure(dev); - if (ret) - goto probe_failed; - } + if (device_dma_configure(dev, drv)) + goto pinctrl_bind_failed; ret = driver_sysfs_add(dev); if (ret) { @@ -660,6 +683,8 @@ static int really_probe(struct device *dev, struct device_driver *drv) if (dev->bus) blocking_notifier_call_chain(&dev->bus->p->bus_notifier, BUS_NOTIFY_DRIVER_NOT_BOUND, dev); + + device_dma_cleanup(dev, drv); pinctrl_bind_failed: device_links_no_driver(dev); devres_release_all(dev); @@ -1204,6 +1229,7 @@ static void __device_release_driver(struct device *dev, struct device *parent) else if (drv->remove) drv->remove(dev); + device_dma_cleanup(dev, drv); device_links_driver_cleanup(dev); devres_release_all(dev); diff --git a/include/linux/device/driver.h b/include/linux/device/driver.h index a498ebcf4993..374a3c2cc10d 100644 --- a/include/linux/device/driver.h +++ b/include/linux/device/driver.h @@ -100,6 +100,7 @@ struct device_driver { const char *mod_name; /* used for built-in modules */ bool suppress_bind_attrs; /* disables bind/unbind via sysfs */ + bool suppress_auto_claim_dma_owner; enum probe_type probe_type; const struct of_device_id *of_match_table; Does this work for you? Can I work towards this in the next version? A kindly ping ... Is this heading the right direction? I need your advice to move ahead. :-) Can I do it like this? :-) Best regards, baolu ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [patch V3 00/35] genirq/msi, PCI/MSI: Spring cleaning - Part 2
On Tue, Dec 14 2021 at 22:19, Thomas Gleixner wrote: > On Tue, Dec 14 2021 at 14:56, Nishanth Menon wrote: > > thanks for trying. I'll have a look again with brain awake tomorrow > morning. Morning was busy with other things, but I found what my sleepy brain managed to do wrong yesterday evening. Let me reintegrate the pile and I'll send you an update. Thanks, tglx ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [SPAM][PATCH] iommu/mediatek: Validate number of phandles associated with "mediatek,larbs"
On Wed, Dec 15, 2021 at 01:30:45PM +0800, Yong Wu wrote: > On Tue, 2021-12-14 at 07:02 -0800, Guenter Roeck wrote: > > On 12/13/21 11:31 PM, Yong Wu wrote: > > > On Fri, 2021-12-10 at 12:57 -0800, Guenter Roeck wrote: > > > > Since commit baf94e6ebff9 ("iommu/mediatek: Add device link for > > > > smi- > > > > common > > > > and m4u"), the driver assumes that at least one phandle > > > > associated > > > > with > > > > "mediatek,larbs" exists. If that is not the case, for example if > > > > reason > > > > "mediatek,larbs" is provided as boolean property, the code will > > > > use > > > > an > > > > uninitialized pointer and may crash. To fix the problem, ensure > > > > that > > > > the > > > > number of phandles associated with "mediatek,larbs" is at least 1 > > > > and > > > > bail out immediately if that is not the case. > > > > > > From the dt-binding, "mediatek,larbs" always is a phandle-array. I > > > assumed the dts should conform to the dt-binding before. Then the > > > problem is that if we should cover the case that someone > > > abuses/attacks > > > the dts. Could you help add more comment in the commit message? > > > something like: this is for avoid abuse the dt-binding. > > > > > > > This doesn't have to be an abuse or attack. It can simply be an error > > by the person who wrote the devicetree file. Sure, bugs or lack of > > A minor question: If someone wrote error data that don't conform to the > dtbinding, the error result is expected. He should fix that problem, > right? If we could avoid abort and show error message at the beginning, > it's better of course. > Sure. However, such an error should not result in a crash but should be caught in an error handler. > > error checking can often be used for attacks, but that doesn't mean > > that all bad data is an exploit or attack. > > > > > > > > > > Cc: Yong Wu > > > > Cc: Tomasz Figa > > > > Fixes: baf94e6ebff9 ("iommu/mediatek: Add device link for smi- > > > > common > > > > and m4u") > > > > Reported-by: kernel test robot > > > > Reported-by: Dan Carpenter > > > > Signed-off-by: Guenter Roeck > > > > --- > > > > drivers/iommu/mtk_iommu.c | 2 ++ > > > > 1 file changed, 2 insertions(+) > > > > > > > > diff --git a/drivers/iommu/mtk_iommu.c > > > > b/drivers/iommu/mtk_iommu.c > > > > index 25b834104790..0bbe32d0a2a6 100644 > > > > --- a/drivers/iommu/mtk_iommu.c > > > > +++ b/drivers/iommu/mtk_iommu.c > > > > @@ -828,6 +828,8 @@ static int mtk_iommu_probe(struct > > > > platform_device > > > > *pdev) > > > > "mediatek,larbs", > > > > NULL); > > > > if (larb_nr < 0) > > > > return larb_nr; > > > > + if (larb_nr == 0) > > > > + return -EINVAL; > > > > > > Just assigning the larbnode to NULL may be simpler. In this case, > > > it > > > won't enter the loop below, and return 0 in the > > > of_parse_phandle(larbnode, "mediatek,smi", 0). > > > > > > - struct device_node *larbnode, *smicomm_node; > > > + struct device_node *larbnode = NULL, *smicomm_node; > > > > > > > It is an option, but it would need to be explained and would not be > > as simple as it looks. And, yes, it would result in unnecessary code > > execution. > > > > Why does it need to be explained ? I spent quite some additional > > time with the code trying to understand _why_ it works, and we should > > make sure that others don't have to spend that time. > > > > Anyway, that additional time made me find additional problems with > > the code. > > > > The for loop below assigns larbnode to the last node it finds. > > However, that node can be disabled. > > > > if (!of_device_is_available(larbnode)) { > > of_node_put(larbnode); > > continue; > > } > > > > Is such a disabled larbnode, if it is the last one, the node to use > > when looking for "mediatek,smi" ? > > > > Also, there is > > > > ret = of_property_read_u32(larbnode, "mediatek,larb-id", &id); > > if (ret)/* The id is consecutive if there is no this > > property */ > > id = i; > > > > There are two problems with this code. First, neither i nor id are > > range > > checked, but used later in > > > > data->larb_imu[id].dev = &plarbdev->dev; > > > > That means a devicetree with a bad value for "mediatek,larb-id" > > or more than MTK_LARB_NR_MAX larb nodes will result in writes after > > the end of struct mtk_iommu_data. > > > > On top of that, the comment states that the nodes are consecutive if > > there > > is no "mediatek,larb-id". However, that isn't really the case if > > there > > are disabled nodes. If there are disabled nodes, there will be a gap > > in > > larb_imu[]. I don't know if that matters; if it doesn't, there should > > be > > a comment about it in the code. > > > > Last but not least, it would probably make sense to explain what the > > "last" > > larb node
Re: [patch V3 00/35] genirq/msi, PCI/MSI: Spring cleaning - Part 2
On Wed, Dec 15 2021 at 17:18, Thomas Gleixner wrote: > On Tue, Dec 14 2021 at 22:19, Thomas Gleixner wrote: >> On Tue, Dec 14 2021 at 14:56, Nishanth Menon wrote: >> >> thanks for trying. I'll have a look again with brain awake tomorrow >> morning. > > Morning was busy with other things, but I found what my sleepy brain > managed to do wrong yesterday evening. > > Let me reintegrate the pile and I'll send you an update. git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git msi-v4.1-part-2 git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git msi-v4.2-part-3 That should cure the problem. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[patch V4 09-01/35] PCI/MSI: Decouple MSI[-X] disable from pcim_release()
The MSI core will introduce runtime allocation of MSI related data. This data will be devres managed and has to be set up before enabling PCI/MSI[-X]. This would introduce an ordering issue vs. pcim_release(). The setup order is: pcim_enable_device() devres_alloc(pcim_release...); ... pci_irq_alloc() msi_setup_device_data() devres_alloc(msi_device_data_release, ...) and once the device is released these release functions are invoked in the opposite order: msi_device_data_release() ... pcim_release() pci_disable_msi[x]() which is obviously wrong, because pci_disable_msi[x]() requires the MSI data to be available to tear down the MSI[-X] interrupts. Remove the MSI[-X] teardown from pcim_release() and add an explicit action to be installed on the attempt of enabling PCI/MSI[-X]. This allows the MSI core data allocation to be ordered correctly in a subsequent step. Reported-by: Nishanth Menon Signed-off-by: Thomas Gleixner --- V4: New patch --- drivers/pci/msi/msi.c | 33 + drivers/pci/pci.c |5 - include/linux/pci.h |3 ++- 3 files changed, 35 insertions(+), 6 deletions(-) --- a/drivers/pci/msi/msi.c +++ b/drivers/pci/msi/msi.c @@ -341,6 +341,31 @@ void pci_restore_msi_state(struct pci_de } EXPORT_SYMBOL_GPL(pci_restore_msi_state); +static void pcim_msi_release(void *pcidev) +{ + struct pci_dev *dev = pcidev; + + dev->is_msi_managed = false; + pci_free_irq_vectors(dev); +} + +/* + * Needs to be separate from pcim_release to prevent an ordering problem + * vs. msi_device_data_release() in the MSI core code. + */ +static int pcim_setup_msi_release(struct pci_dev *dev) +{ + int ret; + + if (!pci_is_managed(dev) || dev->is_msi_managed) + return 0; + + ret = devm_add_action(&dev->dev, pcim_msi_release, dev); + if (!ret) + dev->is_msi_managed = true; + return ret; +} + static struct msi_desc * msi_setup_entry(struct pci_dev *dev, int nvec, struct irq_affinity *affd) { @@ -884,6 +909,10 @@ static int __pci_enable_msi_range(struct if (nvec > maxvec) nvec = maxvec; + rc = pcim_setup_msi_release(dev); + if (rc) + return rc; + for (;;) { if (affd) { nvec = irq_calc_affinity_vectors(minvec, nvec, affd); @@ -927,6 +956,10 @@ static int __pci_enable_msix_range(struc if (WARN_ON_ONCE(dev->msix_enabled)) return -EINVAL; + rc = pcim_setup_msi_release(dev); + if (rc) + return rc; + for (;;) { if (affd) { nvec = irq_calc_affinity_vectors(minvec, nvec, affd); --- a/drivers/pci/pci.c +++ b/drivers/pci/pci.c @@ -2024,11 +2024,6 @@ static void pcim_release(struct device * struct pci_devres *this = res; int i; - if (dev->msi_enabled) - pci_disable_msi(dev); - if (dev->msix_enabled) - pci_disable_msix(dev); - for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) if (this->region_mask & (1 << i)) pci_release_region(dev, i); --- a/include/linux/pci.h +++ b/include/linux/pci.h @@ -425,7 +425,8 @@ struct pci_dev { unsigned intats_enabled:1; /* Address Translation Svc */ unsigned intpasid_enabled:1;/* Process Address Space ID */ unsigned intpri_enabled:1; /* Page Request Interface */ - unsigned intis_managed:1; + unsigned intis_managed:1; /* Managed via devres */ + unsigned intis_msi_managed:1; /* MSI release via devres installed */ unsigned intneeds_freset:1; /* Requires fundamental reset */ unsigned intstate_saved:1; unsigned intis_physfn:1; ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[patch V4 09-02/35] PCI/MSI: Allocate MSI device data on first use
Allocate MSI device data on first use, i.e. when a PCI driver invokes one of the PCI/MSI enablement functions. Add a wrapper function to ensure that the ordering vs. pcim_msi_release() is correct. Signed-off-by: Thomas Gleixner --- V4: Adopted to ensure devres ordering --- drivers/pci/msi/msi.c | 17 +++-- 1 file changed, 15 insertions(+), 2 deletions(-) --- a/drivers/pci/msi/msi.c +++ b/drivers/pci/msi/msi.c @@ -366,6 +366,19 @@ static int pcim_setup_msi_release(struct return ret; } +/* + * Ordering vs. devres: msi device data has to be installed first so that + * pcim_msi_release() is invoked before it on device release. + */ +static int pci_setup_msi_context(struct pci_dev *dev) +{ + int ret = msi_setup_device_data(&dev->dev); + + if (!ret) + ret = pcim_setup_msi_release(dev); + return ret; +} + static struct msi_desc * msi_setup_entry(struct pci_dev *dev, int nvec, struct irq_affinity *affd) { @@ -909,7 +922,7 @@ static int __pci_enable_msi_range(struct if (nvec > maxvec) nvec = maxvec; - rc = pcim_setup_msi_release(dev); + rc = pci_setup_msi_context(dev); if (rc) return rc; @@ -956,7 +969,7 @@ static int __pci_enable_msix_range(struc if (WARN_ON_ONCE(dev->msix_enabled)) return -EINVAL; - rc = pcim_setup_msi_release(dev); + rc = pci_setup_msi_context(dev); if (rc) return rc; ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [patch V4 09-01/35] PCI/MSI: Decouple MSI[-X] disable from pcim_release()
On Wed, Dec 15, 2021 at 06:16:44PM +0100, Thomas Gleixner wrote: > The MSI core will introduce runtime allocation of MSI related data. This > data will be devres managed and has to be set up before enabling > PCI/MSI[-X]. This would introduce an ordering issue vs. pcim_release(). > > The setup order is: > >pcim_enable_device() > devres_alloc(pcim_release...); > ... > pci_irq_alloc() > msi_setup_device_data() >devres_alloc(msi_device_data_release, ...) > > and once the device is released these release functions are invoked in the > opposite order: > > msi_device_data_release() > ... > pcim_release() >pci_disable_msi[x]() > > which is obviously wrong, because pci_disable_msi[x]() requires the MSI > data to be available to tear down the MSI[-X] interrupts. > > Remove the MSI[-X] teardown from pcim_release() and add an explicit action > to be installed on the attempt of enabling PCI/MSI[-X]. > > This allows the MSI core data allocation to be ordered correctly in a > subsequent step. > > Reported-by: Nishanth Menon > Signed-off-by: Thomas Gleixner > --- > V4: New patch Reviewed-by: Greg Kroah-Hartman ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [patch V4 09-02/35] PCI/MSI: Allocate MSI device data on first use
On Wed, Dec 15, 2021 at 06:19:49PM +0100, Thomas Gleixner wrote: > Allocate MSI device data on first use, i.e. when a PCI driver invokes one > of the PCI/MSI enablement functions. > > Add a wrapper function to ensure that the ordering vs. pcim_msi_release() > is correct. > > Signed-off-by: Thomas Gleixner Reviewed-by: Greg Kroah-Hartman ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [patch V3 00/35] genirq/msi, PCI/MSI: Spring cleaning - Part 2
On 17:35-20211215, Thomas Gleixner wrote: >git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git > msi-v4.1-part-2 [...] > That should cure the problem. And it sure does. Thanks for looking closer and providing a fix. https://gist.github.com/nmenon/9862a1c31b17fd6dfe0a30c54d396187 (msi-v4.1-part-2) looks clean Also while I had detected pointer corruption in the previous v4 https://gist.github.com/nmenon/ce4d12f460db5cd511185c047d5d35d0 Running it again on v4.1 does indicate the fix is in place. https://gist.github.com/nmenon/3231fbb0faa1b9c827b40d1ae6160626 please feel free to add: Tested-by: Nishanth Menon -- Regards, Nishanth Menon Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 1/4] dt-bindings: arm-smmu: Document nvidia,memory-controller property
On Thu, 09 Dec 2021 17:35:57 +0100, Thierry Reding wrote: > From: Thierry Reding > > On NVIDIA SoC's the ARM SMMU needs to interact with the memory > controller in order to map memory clients to the corresponding stream > IDs. Document how the nvidia,memory-controller property can be used to > achieve this. > > Note that this is a backwards-incompatible change that is, however, > necessary to ensure correctness. Without the new property, most of the > devices would still work but it is not guaranteed that all will. > > Signed-off-by: Thierry Reding > --- > Changes in v2: > - clarify why the new nvidia,memory-controller property is required > > .../devicetree/bindings/iommu/arm,smmu.yaml | 17 + > 1 file changed, 17 insertions(+) > Reviewed-by: Rob Herring ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [PATCH V7 4/5] scsi: storvsc: Add Isolation VM support for storvsc driver
> From: Tianyu Lan > Sent: Sunday, December 12, 2021 11:14 PM > To: KY Srinivasan ; Haiyang Zhang > ; Stephen Hemminger ; > wei@kernel.org; Dexuan Cui ; t...@linutronix.de; > mi...@redhat.com; b...@alien8.de; dave.han...@linux.intel.com; > x...@kernel.org; h...@zytor.com; da...@davemloft.net; k...@kernel.org; > j...@linux.ibm.com; martin.peter...@oracle.com; a...@arndb.de; > h...@infradead.org; m.szyprow...@samsung.com; robin.mur...@arm.com; > thomas.lenda...@amd.com; Tianyu Lan ; Michael > Kelley (LINUX) > Cc: iommu@lists.linux-foundation.org; linux-a...@vger.kernel.org; linux- > hyp...@vger.kernel.org; linux-ker...@vger.kernel.org; linux- > s...@vger.kernel.org; net...@vger.kernel.org; vkuznets > ; brijesh.si...@amd.com; konrad.w...@oracle.com; > h...@lst.de; j...@8bytes.org; parri.and...@gmail.com; > dave.han...@intel.com > Subject: [PATCH V7 4/5] scsi: storvsc: Add Isolation VM support for storvsc > driver > > From: Tianyu Lan > > In Isolation VM, all shared memory with host needs to mark visible to host via > hvcall. vmbus_establish_gpadl() has already done it for storvsc rx/tx ring > buffer. > The page buffer used by vmbus_sendpacket_ > mpb_desc() still needs to be handled. Use DMA API(scsi_dma_map/unmap) to > map these memory during sending/receiving packet and return swiotlb bounce > buffer dma address. In Isolation VM, swiotlb bounce buffer is marked to be > visible to host and the swiotlb force mode is enabled. > > Set device's dma min align mask to HV_HYP_PAGE_SIZE - 1 in order to keep the > original data offset in the bounce buffer. > > Signed-off-by: Tianyu Lan Reviewed-by: Long Li > --- > drivers/hv/vmbus_drv.c | 4 > drivers/scsi/storvsc_drv.c | 37 + > include/linux/hyperv.h | 1 + > 3 files changed, 26 insertions(+), 16 deletions(-) > > diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c index > 392c1ac4f819..ae6ec503399a 100644 > --- a/drivers/hv/vmbus_drv.c > +++ b/drivers/hv/vmbus_drv.c > @@ -33,6 +33,7 @@ > #include > #include > #include > +#include > #include > #include "hyperv_vmbus.h" > > @@ -2078,6 +2079,7 @@ struct hv_device *vmbus_device_create(const guid_t > *type, > return child_device_obj; > } > > +static u64 vmbus_dma_mask = DMA_BIT_MASK(64); > /* > * vmbus_device_register - Register the child device > */ > @@ -2118,6 +2120,8 @@ int vmbus_device_register(struct hv_device > *child_device_obj) > } > hv_debug_add_dev_dir(child_device_obj); > > + child_device_obj->device.dma_mask = &vmbus_dma_mask; > + child_device_obj->device.dma_parms = &child_device_obj->dma_parms; > return 0; > > err_kset_unregister: > diff --git a/drivers/scsi/storvsc_drv.c b/drivers/scsi/storvsc_drv.c index > 20595c0ba0ae..ae293600d799 100644 > --- a/drivers/scsi/storvsc_drv.c > +++ b/drivers/scsi/storvsc_drv.c > @@ -21,6 +21,8 @@ > #include > #include > #include > +#include > + > #include > #include > #include > @@ -1336,6 +1338,7 @@ static void storvsc_on_channel_callback(void > *context) > continue; > } > request = (struct storvsc_cmd_request > *)scsi_cmd_priv(scmnd); > + scsi_dma_unmap(scmnd); > } > > storvsc_on_receive(stor_device, packet, request); @@ > -1749,7 +1752,6 @@ static int storvsc_queuecommand(struct Scsi_Host *host, > struct scsi_cmnd *scmnd) > struct hv_host_device *host_dev = shost_priv(host); > struct hv_device *dev = host_dev->dev; > struct storvsc_cmd_request *cmd_request = scsi_cmd_priv(scmnd); > - int i; > struct scatterlist *sgl; > unsigned int sg_count; > struct vmscsi_request *vm_srb; > @@ -1831,10 +1833,11 @@ static int storvsc_queuecommand(struct Scsi_Host > *host, struct scsi_cmnd *scmnd) > payload_sz = sizeof(cmd_request->mpb); > > if (sg_count) { > - unsigned int hvpgoff, hvpfns_to_add; > unsigned long offset_in_hvpg = offset_in_hvpage(sgl->offset); > unsigned int hvpg_count = HVPFN_UP(offset_in_hvpg + length); > - u64 hvpfn; > + struct scatterlist *sg; > + unsigned long hvpfn, hvpfns_to_add; > + int j, i = 0; > > if (hvpg_count > MAX_PAGE_BUFFER_COUNT) { > > @@ -1848,21 +1851,22 @@ static int storvsc_queuecommand(struct Scsi_Host > *host, struct scsi_cmnd *scmnd) > payload->range.len = length; > payload->range.offset = offset_in_hvpg; > > + sg_count = scsi_dma_map(scmnd); > + if (sg_count < 0) > + return SCSI_MLQUEUE_DEVICE_BUSY; > > - for (i = 0; sgl != NULL; sgl = sg_next(sgl)) { > + for_each_sg(sgl, sg, sg_count, j) { > /* > - * Init values for the current sgl entry. h
[PATCH] iommu: Use correctly sized arguments for bit field
The find.h APIs are designed to be used only on unsigned long arguments. This can technically result in a over-read, but it is harmless in this case. Regardless, fix it to avoid the warning seen under -Warray-bounds, which we'd like to enable globally: In file included from ./include/linux/bitmap.h:9, from drivers/iommu/intel/iommu.c:17: drivers/iommu/intel/iommu.c: In function 'domain_context_mapping_one': ./include/linux/find.h:119:37: warning: array subscript 'long unsigned int[0]' is partly outside array bounds of 'int[1]' [-Warray-bounds] 119 | unsigned long val = *addr & GENMASK(size - 1, 0); | ^ drivers/iommu/intel/iommu.c:2115:18: note: while referencing 'max_pde' 2115 | int pds, max_pde; | ^~~ Signed-off-by: Kees Cook --- drivers/iommu/intel/iommu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c index b6a8f3282411..99f9e8229384 100644 --- a/drivers/iommu/intel/iommu.c +++ b/drivers/iommu/intel/iommu.c @@ -2112,10 +2112,10 @@ static void domain_exit(struct dmar_domain *domain) */ static inline unsigned long context_get_sm_pds(struct pasid_table *table) { - int pds, max_pde; + unsigned long pds, max_pde; max_pde = table->max_pasid >> PASID_PDE_SHIFT; - pds = find_first_bit((unsigned long *)&max_pde, MAX_NR_PASID_BITS); + pds = find_first_bit(&max_pde, MAX_NR_PASID_BITS); if (pds < 7) return 0; -- 2.30.2 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v2 00/33] Separate struct slab from struct page
On Tue, Dec 14, 2021 at 05:03:12PM -0800, Roman Gushchin wrote: > On Tue, Dec 14, 2021 at 01:57:22PM +0100, Vlastimil Babka wrote: > > On 12/1/21 19:14, Vlastimil Babka wrote: > > > Folks from non-slab subsystems are Cc'd only to patches affecting them, > > > and > > > this cover letter. > > > > > > Series also available in git, based on 5.16-rc3: > > > https://git.kernel.org/pub/scm/linux/kernel/git/vbabka/linux.git/log/?h=slab-struct_slab-v2r2 > > > > Pushed a new branch slab-struct-slab-v3r3 with accumulated fixes and small > > tweaks > > and a new patch from Hyeonggon Yoo on top. To avoid too much spam, here's a > > range diff: > > Hi Vlastimil! > > I've started to review this patchset (btw, a really nice work, I like > the resulting code way more). Because I'm looking at v3 and I don't have > the whole v2 in my mailbox, here is what I've now: > > * mm: add virt_to_folio() and folio_address() > Reviewed-by: Roman Gushchin > > * mm/slab: Dissolve slab_map_pages() in its caller > Reviewed-by: Roman Gushchin > > * mm/slub: Make object_err() static > Reviewed-by: Roman Gushchin > > * mm: Split slab into its own type > 1) Shouldn't SLAB_MATCH() macro use struct folio instead of struct page for > the > comparison? > 2) page_slab() is used only in kasan and only in one place, so maybe it's > better > to not introduce it as a generic helper? > Other than that > Reviewed-by: Roman Gushchin > > * mm: Add account_slab() and unaccount_slab() > 1) maybe change the title to convert/replace instead of add? > 2) maybe move later changes to memcg_alloc_page_obj_cgroups() to this patch? > Reviewed-by: Roman Gushchin > > * mm: Convert virt_to_cache() to use struct slab > Reviewed-by: Roman Gushchin > > * mm: Convert __ksize() to struct slab > It looks like certain parts of __ksize() can be merged between slab, slub and > slob? > Reviewed-by: Roman Gushchin > > * mm: Use struct slab in kmem_obj_info() > Reviewed-by: Roman Gushchin Part 2: * mm: Convert check_heap_object() to use struct slab Reviewed-by: Roman Gushchin * mm/slub: Convert detached_freelist to use a struct slab How about to convert free_nonslab_page() to free_nonslab_folio()? And maybe rename it to something like free_large_kmalloc()? If I'm not missing something, large kmallocs is the only way how we can end up there with a !slab folio/page. * mm/slub: Convert kfree() to use a struct slab Reviewed-by: Roman Gushchin * mm/slub: Convert __slab_lock() and __slab_unlock() to struct slab Reviewed-by: Roman Gushchin * mm/slub: Convert print_page_info() to print_slab_info() Do we really need to explicitly convert slab_folio()'s result to (struct folio *)? Reviewed-by: Roman Gushchin * mm/slub: Convert alloc_slab_page() to return a struct slab Reviewed-by: Roman Gushchin * mm/slub: Convert __free_slab() to use struct slab Reviewed-by: Roman Gushchin * mm/slub: Convert pfmemalloc_match() to take a struct slab Cool! Removing pfmemalloc_unsafe() is really nice. Reviewed-by: Roman Gushchin * mm/slub: Convert most struct page to struct slab by spatch Reviewed-by: Roman Gushchin * mm/slub: Finish struct page to struct slab conversion Reviewed-by: Roman Gushchin * mm/slab: Convert kmem_getpages() and kmem_freepages() to struct slab Reviewed-by: Roman Gushchin * mm/slab: Convert most struct page to struct slab by spatch Another patch with the same title? Rebase error? * mm/slab: Finish struct page to struct slab conversion And this one too? Thanks! Roman ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH 1/1] iommu/vt-d: Remove unused macros
These macros has no reference in the tree anymore. Cleanup them. Signed-off-by: Lu Baolu --- include/linux/intel-svm.h | 6 -- 1 file changed, 6 deletions(-) diff --git a/include/linux/intel-svm.h b/include/linux/intel-svm.h index 57cceecbe37f..1b73bab7eeff 100644 --- a/include/linux/intel-svm.h +++ b/include/linux/intel-svm.h @@ -8,12 +8,6 @@ #ifndef __INTEL_SVM_H__ #define __INTEL_SVM_H__ -/* Values for rxwp in fault_cb callback */ -#define SVM_REQ_READ (1<<3) -#define SVM_REQ_WRITE (1<<2) -#define SVM_REQ_EXEC (1<<1) -#define SVM_REQ_PRIV (1<<0) - /* Page Request Queue depth */ #define PRQ_ORDER 2 #define PRQ_RING_MASK ((0x1000 << PRQ_ORDER) - 0x20) -- 2.25.1 ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [patch V3 00/35] genirq/msi, PCI/MSI: Spring cleaning - Part 2
Hi Thomas, On 17:35-20211215, Thomas Gleixner wrote: >git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git > msi-v4.2-part-3 As you helped offline, summarizing the details on part3 of the series: I was seeing failure[1] of NFS(DMA) on all TI K3 platforms: [1.013258] ti-bcdma 485c0100.dma-controller: Number of rings: 68 [1.019963] ti-bcdma 485c0100.dma-controller: Failed to allocate IRQs -28 [1.026938] ti-bcdma 485c0100.dma-controller: Failed to allocate MSI interrupts Rationale as you explained: " -28 is ENOSPC, which is returned when the interrupt allocation in the MSI domain fails. Fix below. " Which turned out to be the fixup[2] you suggested and I confirm that fixes the problem for me. With the fixup in place: Tested-by: Nishanth Menon for part 3 of the series as well. Thanks once again for your help. Hope we can roll in the fixes for part3. [1] https://gist.github.com/nmenon/5971ab27aa626c022e276cc946e4b6c3 [2] --- a/drivers/soc/ti/ti_sci_inta_msi.c +++ b/drivers/soc/ti/ti_sci_inta_msi.c @@ -68,6 +68,7 @@ static int ti_sci_inta_msi_alloc_descs(s int set, i, count = 0; memset(&msi_desc, 0, sizeof(msi_desc)); + msi_desc.nvec_used = 1; for (set = 0; set < res->sets; set++) { for (i = 0; i < res->desc[set].num; i++, count++) { -- Regards, Nishanth Menon Key (0xDDB5849D1736249D)/Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
RE: [patch V3 00/35] genirq/msi, PCI/MSI: Spring cleaning - Part 2
From: Thomas Gleixner Sent: Wednesday, December 15, 2021 8:36 AM > > On Wed, Dec 15 2021 at 17:18, Thomas Gleixner wrote: > > > On Tue, Dec 14 2021 at 22:19, Thomas Gleixner wrote: > >> On Tue, Dec 14 2021 at 14:56, Nishanth Menon wrote: > >> > >> thanks for trying. I'll have a look again with brain awake tomorrow > >> morning. > > > > Morning was busy with other things, but I found what my sleepy brain > > managed to do wrong yesterday evening. > > > > Let me reintegrate the pile and I'll send you an update. > >git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git > msi-v4.1-part-2 >git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git > msi-v4.2-part-3 > > That should cure the problem. Tested the msi-v4.2-part-3 tag in two different Azure/Hyper-V VMs. One is a Generation 1 VM that has legacy PCI devices and one is a Generation 2 VM with no legacy PCI devices. Tested hot add and remove of Mellanox CX-3 and CX-4 SR-IOV NIC virtual functions that are directly mapped into the VM. Also tested local NVMe devices directly mapped into one of the VMs. No issues encountered. So for Azure/Hyper-V specifically, Tested-by: Michael Kelley ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu