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
