Test posting to old list
Test that this will receive the auto-responder rejection. -k ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [RFC PATCH 2/2] dma-direct: Fix dma_direct_{alloc,free}() for Hyperv-V IVMs
> > @@ -305,6 +306,21 @@ void *dma_direct_alloc(struct device *dev, size_t size,
> > ret = page_address(page);
> > if (dma_set_decrypted(dev, ret, size))
> > goto out_free_pages;
> > +#ifdef CONFIG_HAS_IOMEM
> > + /*
> > +* Remap the pages in the unencrypted physical address space
> > +* when dma_unencrypted_base is set (e.g., for Hyper-V AMD
> > +* SEV-SNP isolated guests).
> > +*/
> > + if (dma_unencrypted_base) {
> > + phys_addr_t ret_pa = virt_to_phys(ret);
> > +
> > + ret_pa += dma_unencrypted_base;
> > + ret = memremap(ret_pa, size, MEMREMAP_WB);
> > + if (!ret)
> > + goto out_encrypt_pages;
> > + }
> > +#endif
>
>
> So:
>
> this needs to move into dma_set_decrypted, otherwise we don't handle
> the dma_alloc_pages case (never mind that this is pretty unreadable).
>
> Which then again largely duplicates the code in swiotlb. So I think
> what we need here is a low-level helper that does the
> set_memory_decrypted and memremap. I'm not quite sure where it
> should go, but maybe some of the people involved with memory
> encryption might have good ideas. unencrypted_base should go with
> it and then both swiotlb and dma-direct can call it.
Agreed, will look into this more (other people's ideas welcome).
> > + /*
> > +* If dma_unencrypted_base is set, the virtual address returned by
> > +* dma_direct_alloc() is in the vmalloc address range.
> > +*/
> > + if (!dma_unencrypted_base && is_vmalloc_addr(cpu_addr)) {
> > vunmap(cpu_addr);
> > } else {
> > if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_CLEAR_UNCACHED))
> > arch_dma_clear_uncached(cpu_addr, size);
> > +#ifdef CONFIG_HAS_IOMEM
> > + if (dma_unencrypted_base) {
> > + memunmap(cpu_addr);
> > + /* re-encrypt the pages using the original address */
> > + cpu_addr = page_address(pfn_to_page(PHYS_PFN(
> > + dma_to_phys(dev, dma_addr;
> > + }
> > +#endif
> > if (dma_set_encrypted(dev, cpu_addr, size))
>
> Same on the unmap side. It might also be worth looking into reordering
> the checks in some form instead o that raw dma_unencrypted_base check
> before the unmap.
Got it.
Thanks,
Andrea
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [linux-next:master] BUILD REGRESSION 088b9c375534d905a4d337c78db3b3bfbb52c4a0
On Thu, Jul 07, 2022 at 10:08:33AM +0200, Greg KH wrote: [ ... ] > > > > Unverified Error/Warning (likely false positive, please contact us if > > interested): > > > > arch/x86/events/core.c:2114 init_hw_perf_events() warn: missing error code > > 'err' > > drivers/android/binder.c:1481:19-23: ERROR: from is NULL but dereferenced. > > drivers/android/binder.c:2920:29-33: ERROR: target_thread is NULL but > > dereferenced. > > drivers/android/binder.c:353:25-35: ERROR: node -> proc is NULL but > > dereferenced. > > drivers/android/binder.c:4888:16-20: ERROR: t is NULL but dereferenced. > > drivers/base/regmap/regmap.c:1996:1: internal compiler error: in arc_ifcvt, > > at config/arc/arc.c:9637 > > drivers/char/random.c:869:1: internal compiler error: in arc_ifcvt, at > > config/arc/arc.c:9637 > > drivers/firmware/arm_scmi/clock.c:394:1: internal compiler error: in > > arc_ifcvt, at config/arc/arc.c:9637 > > drivers/firmware/arm_scmi/powercap.c:376:1: internal compiler error: in > > arc_ifcvt, at config/arc/arc.c:9637 > > drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_powertune.c:1214:1: > > internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 > > drivers/gpu/drm/amd/display/dc/os_types.h: drm/drm_print.h is included more > > than once. > > drivers/gpu/drm/bridge/ite-it66121.c:1398:1: internal compiler error: in > > arc_ifcvt, at config/arc/arc.c:9637 > > drivers/greybus/operation.c:617:1: internal compiler error: in arc_ifcvt, > > at config/arc/arc.c:9637 > > > > When the compiler crashes, why are you blaming all of these different > mailing lists? Perhaps you need to fix your compiler :) > To be fair, it says above "likely false positive, please contact us if interested". Also, the 32-bit build errors _are_ real, and the NULL dereferences in the binder driver are at the very least suspicious. Guenter ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 6/8] genirq: Add and use an irq_data_update_affinity helper
On 07.07.22 11:39, Marc Zyngier wrote:
Hello Marc
> On Sun, 03 Jul 2022 16:22:03 +0100,
> Oleksandr wrote:
>>
>> On 01.07.22 23:00, Samuel Holland wrote:
>>
>>
>> Hello Samuel
>>
>>> Some architectures and irqchip drivers modify the cpumask returned by
>>> irq_data_get_affinity_mask, usually by copying in to it. This is
>>> problematic for uniprocessor configurations, where the affinity mask
>>> should be constant, as it is known at compile time.
>>>
>>> Add and use a setter for the affinity mask, following the pattern of
>>> irq_data_update_effective_affinity. This allows the getter function to
>>> return a const cpumask pointer.
>>>
>>> Signed-off-by: Samuel Holland
>>> ---
>>>
>>> Changes in v3:
>>>- New patch to introduce irq_data_update_affinity
>>>
>>>arch/alpha/kernel/irq.c | 2 +-
>>>arch/ia64/kernel/iosapic.c | 2 +-
>>>arch/ia64/kernel/irq.c | 4 ++--
>>>arch/ia64/kernel/msi_ia64.c | 4 ++--
>>>arch/parisc/kernel/irq.c | 2 +-
>>>drivers/irqchip/irq-bcm6345-l1.c | 4 ++--
>>>drivers/parisc/iosapic.c | 2 +-
>>>drivers/sh/intc/chip.c | 2 +-
>>>drivers/xen/events/events_base.c | 7 ---
>>>include/linux/irq.h | 6 ++
>>>10 files changed, 21 insertions(+), 14 deletions(-)
>>>
>>> diff --git a/arch/alpha/kernel/irq.c b/arch/alpha/kernel/irq.c
>>> index f6d2946edbd2..15f2effd6baf 100644
>>> --- a/arch/alpha/kernel/irq.c
>>> +++ b/arch/alpha/kernel/irq.c
>>> @@ -60,7 +60,7 @@ int irq_select_affinity(unsigned int irq)
>>> cpu = (cpu < (NR_CPUS-1) ? cpu + 1 : 0);
>>> last_cpu = cpu;
>>>-cpumask_copy(irq_data_get_affinity_mask(data),
>>> cpumask_of(cpu));
>>> + irq_data_update_affinity(data, cpumask_of(cpu));
>>> chip->irq_set_affinity(data, cpumask_of(cpu), false);
>>> return 0;
>>>}
>>> diff --git a/arch/ia64/kernel/iosapic.c b/arch/ia64/kernel/iosapic.c
>>> index 35adcf89035a..99300850abc1 100644
>>> --- a/arch/ia64/kernel/iosapic.c
>>> +++ b/arch/ia64/kernel/iosapic.c
>>> @@ -834,7 +834,7 @@ iosapic_unregister_intr (unsigned int gsi)
>>> if (iosapic_intr_info[irq].count == 0) {
>>>#ifdef CONFIG_SMP
>>> /* Clear affinity */
>>> - cpumask_setall(irq_get_affinity_mask(irq));
>>> + irq_data_update_affinity(irq_get_irq_data(irq), cpu_all_mask);
>>>#endif
>>> /* Clear the interrupt information */
>>> iosapic_intr_info[irq].dest = 0;
>>> diff --git a/arch/ia64/kernel/irq.c b/arch/ia64/kernel/irq.c
>>> index ecef17c7c35b..275b9ea58c64 100644
>>> --- a/arch/ia64/kernel/irq.c
>>> +++ b/arch/ia64/kernel/irq.c
>>> @@ -57,8 +57,8 @@ static char irq_redir [NR_IRQS]; // = { [0 ... NR_IRQS-1]
>>> = 1 };
>>>void set_irq_affinity_info (unsigned int irq, int hwid, int redir)
>>>{
>>> if (irq < NR_IRQS) {
>>> - cpumask_copy(irq_get_affinity_mask(irq),
>>> -cpumask_of(cpu_logical_id(hwid)));
>>> + irq_data_update_affinity(irq_get_irq_data(irq),
>>> +cpumask_of(cpu_logical_id(hwid)));
>>> irq_redir[irq] = (char) (redir & 0xff);
>>> }
>>>}
>>> diff --git a/arch/ia64/kernel/msi_ia64.c b/arch/ia64/kernel/msi_ia64.c
>>> index df5c28f252e3..025e5133c860 100644
>>> --- a/arch/ia64/kernel/msi_ia64.c
>>> +++ b/arch/ia64/kernel/msi_ia64.c
>>> @@ -37,7 +37,7 @@ static int ia64_set_msi_irq_affinity(struct irq_data
>>> *idata,
>>> msg.data = data;
>>> pci_write_msi_msg(irq, &msg);
>>> - cpumask_copy(irq_data_get_affinity_mask(idata), cpumask_of(cpu));
>>> + irq_data_update_affinity(idata, cpumask_of(cpu));
>>> return 0;
>>>}
>>> @@ -132,7 +132,7 @@ static int dmar_msi_set_affinity(struct irq_data *data,
>>> msg.address_lo |= MSI_ADDR_DEST_ID_CPU(cpu_physical_id(cpu));
>>> dmar_msi_write(irq, &msg);
>>> - cpumask_copy(irq_data_get_affinity_mask(data), mask);
>>> + irq_data_update_affinity(data, mask);
>>> return 0;
>>>}
>>> diff --git a/arch/parisc/kernel/irq.c b/arch/parisc/kernel/irq.c
>>> index 0fe2d79fb123..5ebb1771b4ab 100644
>>> --- a/arch/parisc/kernel/irq.c
>>> +++ b/arch/parisc/kernel/irq.c
>>> @@ -315,7 +315,7 @@ unsigned long txn_affinity_addr(unsigned int irq, int
>>> cpu)
>>>{
>>>#ifdef CONFIG_SMP
>>> struct irq_data *d = irq_get_irq_data(irq);
>>> - cpumask_copy(irq_data_get_affinity_mask(d), cpumask_of(cpu));
>>> + irq_data_update_affinity(d, cpumask_of(cpu));
>>>#endif
>>> return per_cpu(cpu_data, cpu).txn_addr;
>>> diff --git a/drivers/irqchip/irq-bcm6345-l1.c
>>> b/drivers/irqchip/irq-bcm6345-l1.c
>>> index 142a7431745f..6899e37810a8 100644
>>> --- a/drivers/irqchip/irq-bcm6345-l1.c
>>> +++ b/drivers/irqchip/irq-bcm6345-l1.c
>>> @@ -216,11 +216,11 @@ static int bcm6345_l1_set_affinity(struct irq_data *d,
>>> enabled = intc->cpus[old_cpu]->enable_cache[word] & mas
Re: [PATCH v1 02/16] dt-bindings: memory: mediatek: Update condition for mt8195 smi node
On 06/07/2022 16:38, Krzysztof Kozlowski wrote: On 06/07/2022 15:48, Matthias Brugger wrote: On 04/07/2022 14:36, Krzysztof Kozlowski wrote: On 04/07/2022 12:00, Tinghan Shen wrote: The max clock items for the dts node with compatible 'mediatek,mt8195-smi-sub-common' should be 3. However, the dtbs_check of such node will get following message, arch/arm64/boot/dts/mediatek/mt8195-evb.dtb: smi@1401: clock-names: ['apb', 'smi', 'gals0'] is too long From schema: Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml Remove the last 'else' checking to fix this error. Missing fixes tag. From my understanding, fixes tags are for patches that fix bugs (hw is not working etc) and not a warning message from dtbs_check. So my point of view would be to not add a fixes tag here. Not conforming to bindings is also a bug. Missing properties or wrong properties, even if hardware is working, is still a bug. If such bug is not visible now in Linux, might be visible later in the future or visible in different OS (DTS are used by other systems and pieces of software like bootloaders). Limiting this only to Linux and to current version (hardware still works) is OK for Linux drivers, but not for DTS. If a wrong DTS breaks software, then it's worth a fixes tag, especially for the DTS part, we could argue about the bindings part, but in that case it would be probably OK. Therefore Fixes tag in general is applicable. Of course maybe to this one not really, maybe this is too trivial, or whatever, so I do not insist. But I insist on the principle - reasonable dtbs_check warnings are like compiler warnings - bugs which have to be fixed. I'm not arguing that these things shouldn't be fixed, but that they are worth being back-ported to the stable branches. Regards, Matthias ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v9 7/8] docs: trace: Add HiSilicon PTT device driver documentation
On 2022/7/7 1:57, Mathieu Poirier wrote:
> Hi,
>
> I have started looking at this set.
Thanks!
>
> On Mon, Jun 06, 2022 at 07:55:54PM +0800, Yicong Yang wrote:
>> Document the introduction and usage of HiSilicon PTT device driver.
>>
>> Signed-off-by: Yicong Yang
>> Reviewed-by: Jonathan Cameron
>> ---
>> Documentation/trace/hisi-ptt.rst | 307 +++
>> Documentation/trace/index.rst| 1 +
>
> The "get_maintainer" script clearly indicates that Jonathan Corbet maintains
> the
> Documentation directory and yet he is not CC'ed on this patch, nor is the
> linux-doc mainling list. As such, it would not be possible to merge this
> patchset.
>
sorry for missing. +cc'ed.
>> 2 files changed, 308 insertions(+)
>> create mode 100644 Documentation/trace/hisi-ptt.rst
>>
>> diff --git a/Documentation/trace/hisi-ptt.rst
>> b/Documentation/trace/hisi-ptt.rst
>> new file mode 100644
>> index ..0a3112244d40
>> --- /dev/null
>> +++ b/Documentation/trace/hisi-ptt.rst
>> @@ -0,0 +1,307 @@
>> +.. SPDX-License-Identifier: GPL-2.0
>> +
>> +==
>> +HiSilicon PCIe Tune and Trace device
>> +==
>> +
>> +Introduction
>> +
>> +
>> +HiSilicon PCIe tune and trace device (PTT) is a PCIe Root Complex
>> +integrated Endpoint (RCiEP) device, providing the capability
>> +to dynamically monitor and tune the PCIe link's events (tune),
>> +and trace the TLP headers (trace). The two functions are independent,
>> +but is recommended to use them together to analyze and enhance the
>> +PCIe link's performance.
>> +
>> +On Kunpeng 930 SoC, the PCIe Root Complex is composed of several
>> +PCIe cores. Each PCIe core includes several Root Ports and a PTT
>> +RCiEP, like below. The PTT device is capable of tuning and
>> +tracing the links of the PCIe core.
>> +::
>> +
>> + +--Core 0---+
>> + | | [ PTT ] |
>> + | | [Root Port]---[Endpoint]
>> + | | [Root Port]---[Endpoint]
>> + | | [Root Port]---[Endpoint]
>> +Root Complex |--Core 1---+
>> + | | [ PTT ] |
>> + | | [Root Port]---[ Switch ]---[Endpoint]
>> + | | [Root Port]---[Endpoint] `-[Endpoint]
>> + | | [Root Port]---[Endpoint]
>> + +---+
>> +
>> +The PTT device driver registers one PMU device for each PTT device.
>> +The name of each PTT device is composed of 'hisi_ptt' prefix with
>> +the id of the SICL and the Core where it locates. The Kunpeng 930
>> +SoC encapsulates multiple CPU dies (SCCL, Super CPU Cluster) and
>> +IO dies (SICL, Super I/O Cluster), where there's one PCIe Root
>> +Complex for each SICL.
>> +::
>> +
>> +/sys/devices/hisi_ptt_
>
> All entries added to sysfs should have corresponding documentation. See [1]
> and
> [2] for details and [3] for an example.
>
> [1]. https://elixir.bootlin.com/linux/latest/source/Documentation/ABI/README
> [2]. https://elixir.bootlin.com/linux/latest/source/Documentation/ABI/testing
> [3].
> https://elixir.bootlin.com/linux/latest/source/Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
>
ok. I'll add a patch for ABI description. Thanks for the reference.
>> +
>> +Tune
>> +
>> +
>> +PTT tune is designed for monitoring and adjusting PCIe link parameters
>> (events).
>> +Currently we support events in 4 classes. The scope of the events
>> +covers the PCIe core to which the PTT device belongs.
>> +
>> +Each event is presented as a file under $(PTT PMU dir)/tune, and
>> +a simple open/read/write/close cycle will be used to tune the event.
>> +::
>> +
>> +$ cd /sys/devices/hisi_ptt_/tune
>> +$ ls
>> +qos_tx_cplqos_tx_npqos_tx_p
>> +tx_path_rx_req_alloc_buf_level
>> +tx_path_tx_req_alloc_buf_level
>
> These look overly long... How about watermark_rx and watermark_tx?
>
These are gotten from the hardware manual and abbreviated. These events are
highly connected
to the hardware desgin so I think it's better to keep consistence. The
watermark_{rx, tx} will
become ambigious when we add more events for Rx path or other Tx path events.
The event code is composed of two parts. First part (tx_path) describes which
path it belongs to
and second part describes the function ({rx,tx}_req_alloc_buf_level). We called
the link path
between CPU and PCIe RC as Rx path and the path between PCIe RC to the PCIe
link as Tx path.
So we need to have tx_path prefix for the Tx path and {rx,
tx}_req_alloc_buf_level for the
requested watermark of {inbound, outbound} buffer allocation. Indeed we have
other Tx path
buffer events which are not exported in this series.
>> +$ cat qos_tx_dp
>> +1
>> +$ echo 2 > qos_tx_dp
>> +$ cat qos_tx_dp
>> +2
>> +
>> +Current value (numerical value) of the event can be simply read
>> +f
Re: [PATCH v3 1/8] irqchip/mips-gic: Only register IPI domain when SMP is enabled
On Thu, Jul 07, 2022 at 09:22:26AM +0100, Marc Zyngier wrote:
> On Tue, 05 Jul 2022 14:52:43 +0100,
> Serge Semin wrote:
> >
> > Hi Samuel
> >
> > On Fri, Jul 01, 2022 at 03:00:49PM -0500, Samuel Holland wrote:
> > > The MIPS GIC irqchip driver may be selected in a uniprocessor
> > > configuration, but it unconditionally registers an IPI domain.
> > >
> > > Limit the part of the driver dealing with IPIs to only be compiled when
> > > GENERIC_IRQ_IPI is enabled, which corresponds to an SMP configuration.
> >
> > Thanks for the patch. Some comment is below.
> >
> > >
> > > Reported-by: kernel test robot
> > > Signed-off-by: Samuel Holland
> > > ---
> > >
> > > Changes in v3:
> > > - New patch to fix build errors in uniprocessor MIPS configs
> > >
> > > drivers/irqchip/Kconfig| 3 +-
> > > drivers/irqchip/irq-mips-gic.c | 80 +++---
> > > 2 files changed, 56 insertions(+), 27 deletions(-)
> > >
> > > diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
> > > index 1f23a6be7d88..d26a4ff7c99f 100644
> > > --- a/drivers/irqchip/Kconfig
> > > +++ b/drivers/irqchip/Kconfig
> > > @@ -322,7 +322,8 @@ config KEYSTONE_IRQ
> > >
> > > config MIPS_GIC
> > > bool
> > > - select GENERIC_IRQ_IPI
> > > + select GENERIC_IRQ_IPI if SMP
> >
> > > + select IRQ_DOMAIN_HIERARCHY
> >
> > It seems to me that the IRQ domains hierarchy is supposed to be
> > created only if IPI is required. At least that's what the MIPS GIC
> > driver implies. Thus we can go further and CONFIG_IRQ_DOMAIN_HIERARCHY
> > ifdef-out the gic_irq_domain_alloc() and gic_irq_domain_free()
> > methods definition together with the initialization:
> >
> > static const struct irq_domain_ops gic_irq_domain_ops = {
> > .xlate = gic_irq_domain_xlate,
> > +#ifdef CONFIG_IRQ_DOMAIN_HIERARCHY
> > .alloc = gic_irq_domain_alloc,
> > .free = gic_irq_domain_free,
> > +#endif
> > .map = gic_irq_domain_map,
> > };
> >
> > If the GENERIC_IRQ_IPI config is enabled, CONFIG_IRQ_DOMAIN_HIERARCHY
> > will be automatically selected (see the config definition in
> > kernel/irq/Kconfig). If the IRQs hierarchy is needed for some another
> > functionality like GENERIC_MSI_IRQ_DOMAIN or GPIOs then they will
> > explicitly enable the IRQ_DOMAIN_HIERARCHY config thus activating the
> > denoted .alloc and .free methods definitions.
> >
> > To sum up you can get rid of the IRQ_DOMAIN_HIERARCHY config
> > force-select from this patch and make the MIPS GIC driver code a bit
> > more coherent.
> >
> > @Marc, please correct me if were wrong.
>
> Either way probably works correctly, but Samuel's approach is more
> readable IMO. It is far easier to reason about a high-level feature
> (GENERIC_IRQ_IPI) than an implementation detail (IRQ_DOMAIN_HIERARCHY).
>
The main idea of my comment was to get rid of the forcible
IRQ_DOMAIN_HIERARCHY config selection, because the basic part of the
driver doesn't depends on the hierarchical IRQ-domains functionality.
It's needed only for IPIs and implicitly for the lower level IRQ
device drivers like GPIO or PCIe-controllers, which explicitly enable
the IRQ_DOMAIN_HIERARCHY config anyway. That's why instead of forcible
IRQ_DOMAIN_HIERARCHY config selection (see Samuel patch) I suggested
to make the corresponding functionality defined under the
IRQ_DOMAIN_HIERARCHY config ifdefs, thus having the driver capable of
creating the hierarchical IRQs domains only if it's required.
> If you really want to save a handful of bytes, you can make the
> callbacks conditional on GENERIC_IRQ_IPI, and be done with it.
AFAIU I can't in this case. It must be either IRQ_DOMAIN_HIERARCHY
ifdefs or explicit IRQ_DOMAIN_HIERARCHY select. There can be non-SMP
(UP) systems with no need in IPIs but for instance having a GPIO or
PCIe controller which require the hierarchical IRQ-domains support of
the parental IRQ controller. So making the callbacks definition
depended on the GENERIC_IRQ_IPI config state will break the driver for
these systems. That's why I suggested to use
CONFIG_IRQ_DOMAIN_HIERARCHY which activates the hierarchical IRQ
domains support in the IRQ-chip system (see the irq_domain_ops
structure conditional fields definition) and shall we have the
suggested approach implemented in the MIPS GIC driver.
-Sergey
> But this can come as an additional patch.
>
> Thanks,
>
> M.
>
> --
> Without deviation from the norm, progress is not possible.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v4 01/11] iommu/vt-d: debugfs: Remove device_domain_lock usage
On 2022/7/7 16:30, Ethan Zhao wrote:
-static int show_device_domain_translation(struct device *dev, void *data)
+static int __show_device_domain_translation(struct device *dev, void *data)
{
- struct device_domain_info *info = dev_iommu_priv_get(dev);
- struct dmar_domain *domain = info->domain;
+ struct dmar_domain *domain;
struct seq_file *m = data;
u64 path[6] = { 0 };
+ domain = to_dmar_domain(iommu_get_domain_for_dev(dev));
if (!domain)
return 0;
@@ -359,20 +359,39 @@ static int show_device_domain_translation(struct device *dev, void *data)
pgtable_walk_level(m, domain->pgd, domain->agaw + 2, 0, path);
seq_putc(m, '\n');
- return 0;
+ /* Don't iterate */
+ return 1;
}
Using this return value trick to change the caller behaviour, seems not
saving
anything, but really cost me a few seconds more to know the
*incantation* --
'Don't iterate' :) .
This is defined by iommu_group_for_each_dev(). Return value 0 means
continuing to next one, while non-zero means stopping iteration.
Best regards,
baolu
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [linux-next:master] BUILD REGRESSION 088b9c375534d905a4d337c78db3b3bfbb52c4a0
On 7/7/2022 4:08 PM, Greg KH wrote: On Thu, Jul 07, 2022 at 02:56:34PM +0800, kernel test robot wrote: tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 088b9c375534d905a4d337c78db3b3bfbb52c4a0 Add linux-next specific files for 20220706 Error/Warning reports: https://lore.kernel.org/linux-doc/202207070644.x48xoovs-...@intel.com Error/Warning: (recently discovered and may have been fixed) Documentation/arm/google/chromebook-boot-flow.rst: WARNING: document isn't included in any toctree arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x1108): undefined reference to `__aeabi_ddiv' arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x1124): undefined reference to `__aeabi_ui2d' arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x1164): undefined reference to `__aeabi_dmul' arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x1170): undefined reference to `__aeabi_dadd' arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x1180): undefined reference to `__aeabi_dsub' arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x1190): undefined reference to `__aeabi_d2uiz' arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x162c): undefined reference to `__aeabi_d2iz' arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x16b0): undefined reference to `__aeabi_i2d' dc_dmub_srv.c:(.text+0x10f8): undefined reference to `__aeabi_ui2d' dc_dmub_srv.c:(.text+0x464): undefined reference to `__floatunsidf' dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x33c): undefined reference to `__floatunsidf' drivers/pci/endpoint/functions/pci-epf-vntb.c:975:5: warning: no previous prototype for 'pci_read' [-Wmissing-prototypes] drivers/pci/endpoint/functions/pci-epf-vntb.c:984:5: warning: no previous prototype for 'pci_write' [-Wmissing-prototypes] drivers/vfio/vfio_iommu_type1.c:2141:35: warning: cast to smaller integer type 'enum iommu_cap' from 'void *' [-Wvoid-pointer-to-enum-cast] mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x34c): undefined reference to `__floatunsidf' mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x378): undefined reference to `__divdf3' mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x38c): undefined reference to `__muldf3' mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x3a0): undefined reference to `__adddf3' mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x3b4): undefined reference to `__subdf3' mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x3d4): undefined reference to `__fixunsdfsi' mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x750): undefined reference to `__fixdfsi' mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x7c0): undefined reference to `__floatsidf' powerpc-linux-ld: drivers/pci/endpoint/functions/pci-epf-vntb.c:174: undefined reference to `ntb_link_event' xtensa-linux-ld: dc_dmub_srv.c:(.text+0x468): undefined reference to `__divdf3' xtensa-linux-ld: dc_dmub_srv.c:(.text+0x46c): undefined reference to `__muldf3' xtensa-linux-ld: dc_dmub_srv.c:(.text+0x470): undefined reference to `__adddf3' xtensa-linux-ld: dc_dmub_srv.c:(.text+0x474): undefined reference to `__subdf3' xtensa-linux-ld: dc_dmub_srv.c:(.text+0x478): undefined reference to `__fixunsdfsi' xtensa-linux-ld: dc_dmub_srv.c:(.text+0x47c): undefined reference to `__fixdfsi' xtensa-linux-ld: dc_dmub_srv.c:(.text+0x480): undefined reference to `__floatsidf' xtensa-linux-ld: dc_dmub_srv.c:(.text+0x60c): undefined reference to `__floatunsidf' Unverified Error/Warning (likely false positive, please contact us if interested): arch/x86/events/core.c:2114 init_hw_perf_events() warn: missing error code 'err' drivers/android/binder.c:1481:19-23: ERROR: from is NULL but dereferenced. drivers/android/binder.c:2920:29-33: ERROR: target_thread is NULL but dereferenced. drivers/android/binder.c:353:25-35: ERROR: node -> proc is NULL but dereferenced. drivers/android/binder.c:4888:16-20: ERROR: t is NULL but dereferenced. drivers/base/regmap/regmap.c:1996:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/char/random.c:869:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/firmware/arm_scmi/clock.c:394:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/firmware/arm_scmi/powercap.c:376:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_powertune.c:1214:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/gpu/drm/amd/display/dc/os_types.h: drm/drm_print.h is included more than once. drivers/gpu/drm/bridge/ite-it66121.c:1398:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 drivers/greybus/operation.c:617:1: internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 When the compiler crashes, why are you blaming all of these different mailing l
Re: [PATCH v3 6/8] genirq: Add and use an irq_data_update_affinity helper
On Sun, 03 Jul 2022 16:22:03 +0100,
Oleksandr wrote:
>
>
> On 01.07.22 23:00, Samuel Holland wrote:
>
>
> Hello Samuel
>
> > Some architectures and irqchip drivers modify the cpumask returned by
> > irq_data_get_affinity_mask, usually by copying in to it. This is
> > problematic for uniprocessor configurations, where the affinity mask
> > should be constant, as it is known at compile time.
> >
> > Add and use a setter for the affinity mask, following the pattern of
> > irq_data_update_effective_affinity. This allows the getter function to
> > return a const cpumask pointer.
> >
> > Signed-off-by: Samuel Holland
> > ---
> >
> > Changes in v3:
> > - New patch to introduce irq_data_update_affinity
> >
> > arch/alpha/kernel/irq.c | 2 +-
> > arch/ia64/kernel/iosapic.c | 2 +-
> > arch/ia64/kernel/irq.c | 4 ++--
> > arch/ia64/kernel/msi_ia64.c | 4 ++--
> > arch/parisc/kernel/irq.c | 2 +-
> > drivers/irqchip/irq-bcm6345-l1.c | 4 ++--
> > drivers/parisc/iosapic.c | 2 +-
> > drivers/sh/intc/chip.c | 2 +-
> > drivers/xen/events/events_base.c | 7 ---
> > include/linux/irq.h | 6 ++
> > 10 files changed, 21 insertions(+), 14 deletions(-)
> >
> > diff --git a/arch/alpha/kernel/irq.c b/arch/alpha/kernel/irq.c
> > index f6d2946edbd2..15f2effd6baf 100644
> > --- a/arch/alpha/kernel/irq.c
> > +++ b/arch/alpha/kernel/irq.c
> > @@ -60,7 +60,7 @@ int irq_select_affinity(unsigned int irq)
> > cpu = (cpu < (NR_CPUS-1) ? cpu + 1 : 0);
> > last_cpu = cpu;
> > - cpumask_copy(irq_data_get_affinity_mask(data),
> > cpumask_of(cpu));
> > + irq_data_update_affinity(data, cpumask_of(cpu));
> > chip->irq_set_affinity(data, cpumask_of(cpu), false);
> > return 0;
> > }
> > diff --git a/arch/ia64/kernel/iosapic.c b/arch/ia64/kernel/iosapic.c
> > index 35adcf89035a..99300850abc1 100644
> > --- a/arch/ia64/kernel/iosapic.c
> > +++ b/arch/ia64/kernel/iosapic.c
> > @@ -834,7 +834,7 @@ iosapic_unregister_intr (unsigned int gsi)
> > if (iosapic_intr_info[irq].count == 0) {
> > #ifdef CONFIG_SMP
> > /* Clear affinity */
> > - cpumask_setall(irq_get_affinity_mask(irq));
> > + irq_data_update_affinity(irq_get_irq_data(irq), cpu_all_mask);
> > #endif
> > /* Clear the interrupt information */
> > iosapic_intr_info[irq].dest = 0;
> > diff --git a/arch/ia64/kernel/irq.c b/arch/ia64/kernel/irq.c
> > index ecef17c7c35b..275b9ea58c64 100644
> > --- a/arch/ia64/kernel/irq.c
> > +++ b/arch/ia64/kernel/irq.c
> > @@ -57,8 +57,8 @@ static char irq_redir [NR_IRQS]; // = { [0 ... NR_IRQS-1]
> > = 1 };
> > void set_irq_affinity_info (unsigned int irq, int hwid, int redir)
> > {
> > if (irq < NR_IRQS) {
> > - cpumask_copy(irq_get_affinity_mask(irq),
> > -cpumask_of(cpu_logical_id(hwid)));
> > + irq_data_update_affinity(irq_get_irq_data(irq),
> > +cpumask_of(cpu_logical_id(hwid)));
> > irq_redir[irq] = (char) (redir & 0xff);
> > }
> > }
> > diff --git a/arch/ia64/kernel/msi_ia64.c b/arch/ia64/kernel/msi_ia64.c
> > index df5c28f252e3..025e5133c860 100644
> > --- a/arch/ia64/kernel/msi_ia64.c
> > +++ b/arch/ia64/kernel/msi_ia64.c
> > @@ -37,7 +37,7 @@ static int ia64_set_msi_irq_affinity(struct irq_data
> > *idata,
> > msg.data = data;
> > pci_write_msi_msg(irq, &msg);
> > - cpumask_copy(irq_data_get_affinity_mask(idata), cpumask_of(cpu));
> > + irq_data_update_affinity(idata, cpumask_of(cpu));
> > return 0;
> > }
> > @@ -132,7 +132,7 @@ static int dmar_msi_set_affinity(struct irq_data *data,
> > msg.address_lo |= MSI_ADDR_DEST_ID_CPU(cpu_physical_id(cpu));
> > dmar_msi_write(irq, &msg);
> > - cpumask_copy(irq_data_get_affinity_mask(data), mask);
> > + irq_data_update_affinity(data, mask);
> > return 0;
> > }
> > diff --git a/arch/parisc/kernel/irq.c b/arch/parisc/kernel/irq.c
> > index 0fe2d79fb123..5ebb1771b4ab 100644
> > --- a/arch/parisc/kernel/irq.c
> > +++ b/arch/parisc/kernel/irq.c
> > @@ -315,7 +315,7 @@ unsigned long txn_affinity_addr(unsigned int irq, int
> > cpu)
> > {
> > #ifdef CONFIG_SMP
> > struct irq_data *d = irq_get_irq_data(irq);
> > - cpumask_copy(irq_data_get_affinity_mask(d), cpumask_of(cpu));
> > + irq_data_update_affinity(d, cpumask_of(cpu));
> > #endif
> > return per_cpu(cpu_data, cpu).txn_addr;
> > diff --git a/drivers/irqchip/irq-bcm6345-l1.c
> > b/drivers/irqchip/irq-bcm6345-l1.c
> > index 142a7431745f..6899e37810a8 100644
> > --- a/drivers/irqchip/irq-bcm6345-l1.c
> > +++ b/drivers/irqchip/irq-bcm6345-l1.c
> > @@ -216,11 +216,11 @@ static int bcm6345_l1_set_affinity(struct irq_data *d,
> > enabled = intc->cpus[old_cpu]->enable_cache[word] & mask;
> > if (enabled)
> > __bcm6345_l1_mask(d);
> > -
Re: [PATCH v4 01/11] iommu/vt-d: debugfs: Remove device_domain_lock usage
Baolu，
在 2022/7/6 10:55, Lu Baolu 写道:
The domain_translation_struct debugfs node is used to dump the DMAR page
tables for the PCI devices. It potentially races with setting domains to
devices. The existing code uses the global spinlock device_domain_lock to
avoid the races.
This removes the use of device_domain_lock outside of iommu.c by replacing
it with the group mutex lock. Using the group mutex lock is cleaner and
more compatible to following cleanups.
Signed-off-by: Lu Baolu
Reviewed-by: Kevin Tian
---
drivers/iommu/intel/iommu.h | 1 -
drivers/iommu/intel/debugfs.c | 43 +--
drivers/iommu/intel/iommu.c | 2 +-
3 files changed, 32 insertions(+), 14 deletions(-)
diff --git a/drivers/iommu/intel/iommu.h b/drivers/iommu/intel/iommu.h
index 8285fcfa5fea..8deb745d8b36 100644
--- a/drivers/iommu/intel/iommu.h
+++ b/drivers/iommu/intel/iommu.h
@@ -480,7 +480,6 @@ enum {
#define VTD_FLAG_SVM_CAPABLE (1 << 2)
extern int intel_iommu_sm;
-extern spinlock_t device_domain_lock;
#define sm_supported(iommu) (intel_iommu_sm && ecap_smts((iommu)->ecap))
#define pasid_supported(iommu)(sm_supported(iommu) &&
\
diff --git a/drivers/iommu/intel/debugfs.c b/drivers/iommu/intel/debugfs.c
index d927ef10641b..6e1a3f88abc8 100644
--- a/drivers/iommu/intel/debugfs.c
+++ b/drivers/iommu/intel/debugfs.c
@@ -342,13 +342,13 @@ static void pgtable_walk_level(struct seq_file *m, struct
dma_pte *pde,
}
}
-static int show_device_domain_translation(struct device *dev, void *data)
+static int __show_device_domain_translation(struct device *dev, void *data)
{
- struct device_domain_info *info = dev_iommu_priv_get(dev);
- struct dmar_domain *domain = info->domain;
+ struct dmar_domain *domain;
struct seq_file *m = data;
u64 path[6] = { 0 };
+ domain = to_dmar_domain(iommu_get_domain_for_dev(dev));
if (!domain)
return 0;
@@ -359,20 +359,39 @@ static int show_device_domain_translation(struct device *dev, void *data)
pgtable_walk_level(m, domain->pgd, domain->agaw + 2, 0, path);
seq_putc(m, '\n');
- return 0;
+ /* Don't iterate */
+ return 1;
}
Using this return value trick to change the caller behaviour, seems not
saving
anything, but really cost me a few seconds more to know the
*incantation* --
'Don't iterate' :) .
Thanks,
Ethan
-static int domain_translation_struct_show(struct seq_file *m, void *unused)
+static int show_device_domain_translation(struct device *dev, void *data)
{
- unsigned long flags;
- int ret;
+ struct iommu_group *group;
- spin_lock_irqsave(&device_domain_lock, flags);
- ret = bus_for_each_dev(&pci_bus_type, NULL, m,
- show_device_domain_translation);
- spin_unlock_irqrestore(&device_domain_lock, flags);
+ group = iommu_group_get(dev);
+ if (group) {
+ /*
+* The group->mutex is held across the callback, which will
+* block calls to iommu_attach/detach_group/device. Hence,
+* the domain of the device will not change during traversal.
+*
+* All devices in an iommu group share a single domain, hence
+* we only dump the domain of the first device. Even though,
+* this code still possibly races with the iommu_unmap()
+* interface. This could be solved by RCU-freeing the page
+* table pages in the iommu_unmap() path.
+*/
+ iommu_group_for_each_dev(group, data,
+__show_device_domain_translation);
+ iommu_group_put(group);
+ }
- return ret;
+ return 0;
+}
+
+static int domain_translation_struct_show(struct seq_file *m, void *unused)
+{
+ return bus_for_each_dev(&pci_bus_type, NULL, m,
+ show_device_domain_translation);
}
DEFINE_SHOW_ATTRIBUTE(domain_translation_struct);
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 10bda4bec8fe..3b6571681bdd 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -314,7 +314,7 @@ static int iommu_skip_te_disable;
#define IDENTMAP_GFX 2
#define IDENTMAP_AZALIA 4
-DEFINE_SPINLOCK(device_domain_lock);
+static DEFINE_SPINLOCK(device_domain_lock);
static LIST_HEAD(device_domain_list);
const struct iommu_ops intel_iommu_ops;
--
"firm, enduring, strong, and long-lived"
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
[PATCH V3] swiotlb: Split up single swiotlb lock
From: Tianyu Lan
Traditionally swiotlb was not performance critical because it was only
used for slow devices. But in some setups, like TDX/SEV confidential
guests, all IO has to go through swiotlb. Currently swiotlb only has a
single lock. Under high IO load with multiple CPUs this can lead to
significat lock contention on the swiotlb lock.
This patch splits the swiotlb bounce buffer pool into individual areas
which have their own lock. Each CPU tries to allocate in its own area
first. Only if that fails does it search other areas. On freeing the
allocation is freed into the area where the memory was originally
allocated from.
Area number can be set via swiotlb kernel parameter and is default
to be possible cpu number. If possible cpu number is not power of
2, area number will be round up to the next power of 2.
This idea from Andi Kleen patch(https://github.com/intel/tdx/commit/
4529b5784c141782c72ec9bd9a92df2b68cb7d45).
Based-on-idea-by: Andi Kleen
Signed-off-by: Tianyu Lan
---
Change since v2:
* Use possible cpu number to adjust iotlb area number
Change since v1:
* Move struct io_tlb_area to swiotlb.c
* Fix some coding style issue.
---
.../admin-guide/kernel-parameters.txt | 4 +-
include/linux/swiotlb.h | 5 +
kernel/dma/swiotlb.c | 222 +++---
3 files changed, 191 insertions(+), 40 deletions(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 2522b11e593f..4a6ad177d4b8 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -5904,8 +5904,10 @@
it if 0 is given (See
Documentation/admin-guide/cgroup-v1/memory.rst)
swiotlb=[ARM,IA-64,PPC,MIPS,X86]
- Format: { | force | noforce }
+ Format: { [,] | force | noforce }
-- Number of I/O TLB slabs
+-- Second integer after comma. Number of swiotlb
+areas with their own lock. Must be power of 2.
force -- force using of bounce buffers even if they
wouldn't be automatically used by the kernel
noforce -- Never use bounce buffers (for debugging)
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 7ed35dd3de6e..5f898c5e9f19 100644
--- a/include/linux/swiotlb.h
+++ b/include/linux/swiotlb.h
@@ -89,6 +89,8 @@ extern enum swiotlb_force swiotlb_force;
* @late_alloc:%true if allocated using the page allocator
* @force_bounce: %true if swiotlb bouncing is forced
* @for_alloc: %true if the pool is used for memory allocation
+ * @nareas: The area number in the pool.
+ * @area_nslabs: The slot number in the area.
*/
struct io_tlb_mem {
phys_addr_t start;
@@ -102,6 +104,9 @@ struct io_tlb_mem {
bool late_alloc;
bool force_bounce;
bool for_alloc;
+ unsigned int nareas;
+ unsigned int area_nslabs;
+ struct io_tlb_area *areas;
struct io_tlb_slot {
phys_addr_t orig_addr;
size_t alloc_size;
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index cb50f8d38360..9e7aeca8faf4 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -70,6 +70,43 @@ struct io_tlb_mem io_tlb_default_mem;
phys_addr_t swiotlb_unencrypted_base;
static unsigned long default_nslabs = IO_TLB_DEFAULT_SIZE >> IO_TLB_SHIFT;
+static unsigned long default_nareas = 1;
+
+/**
+ * struct io_tlb_area - IO TLB memory area descriptor
+ *
+ * This is a single area with a single lock.
+ *
+ * @used: The number of used IO TLB block.
+ * @index: The slot index to start searching in this area for next round.
+ * @lock: The lock to protect the above data structures in the map and
+ * unmap calls.
+ */
+struct io_tlb_area {
+ unsigned long used;
+ unsigned int index;
+ spinlock_t lock;
+};
+
+static void swiotlb_adjust_nareas(unsigned int nareas)
+{
+ if (!is_power_of_2(nareas))
+ nareas = roundup_pow_of_two(nareas);
+
+ default_nareas = nareas;
+
+ pr_info("area num %d.\n", nareas);
+ /*
+* Round up number of slabs to the next power of 2.
+* The last area is going be smaller than the rest if
+* default_nslabs is not power of two.
+*/
+ if (nareas > 1) {
+ default_nslabs = roundup_pow_of_two(default_nslabs);
+ pr_info("SWIOTLB bounce buffer size roundup to %luMB",
+ (default_nslabs << IO_TLB_SHIFT) >> 20);
+ }
+}
static int __init
setup_io_tlb_npages(char *str)
@@ -79,6 +116,10 @@ setup_io_tlb_npages(char *str)
default_nslabs =
ALIGN(simple_strtoul(str, &str, 0), IO_TLB_SEGSIZE);
}
+
Re: [PATCH v3 1/8] irqchip/mips-gic: Only register IPI domain when SMP is enabled
On Tue, 05 Jul 2022 14:52:43 +0100,
Serge Semin wrote:
>
> Hi Samuel
>
> On Fri, Jul 01, 2022 at 03:00:49PM -0500, Samuel Holland wrote:
> > The MIPS GIC irqchip driver may be selected in a uniprocessor
> > configuration, but it unconditionally registers an IPI domain.
> >
> > Limit the part of the driver dealing with IPIs to only be compiled when
> > GENERIC_IRQ_IPI is enabled, which corresponds to an SMP configuration.
>
> Thanks for the patch. Some comment is below.
>
> >
> > Reported-by: kernel test robot
> > Signed-off-by: Samuel Holland
> > ---
> >
> > Changes in v3:
> > - New patch to fix build errors in uniprocessor MIPS configs
> >
> > drivers/irqchip/Kconfig| 3 +-
> > drivers/irqchip/irq-mips-gic.c | 80 +++---
> > 2 files changed, 56 insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
> > index 1f23a6be7d88..d26a4ff7c99f 100644
> > --- a/drivers/irqchip/Kconfig
> > +++ b/drivers/irqchip/Kconfig
> > @@ -322,7 +322,8 @@ config KEYSTONE_IRQ
> >
> > config MIPS_GIC
> > bool
> > - select GENERIC_IRQ_IPI
> > + select GENERIC_IRQ_IPI if SMP
>
> > + select IRQ_DOMAIN_HIERARCHY
>
> It seems to me that the IRQ domains hierarchy is supposed to be
> created only if IPI is required. At least that's what the MIPS GIC
> driver implies. Thus we can go further and CONFIG_IRQ_DOMAIN_HIERARCHY
> ifdef-out the gic_irq_domain_alloc() and gic_irq_domain_free()
> methods definition together with the initialization:
>
> static const struct irq_domain_ops gic_irq_domain_ops = {
> .xlate = gic_irq_domain_xlate,
> +#ifdef CONFIG_IRQ_DOMAIN_HIERARCHY
> .alloc = gic_irq_domain_alloc,
> .free = gic_irq_domain_free,
> +#endif
> .map = gic_irq_domain_map,
> };
>
> If the GENERIC_IRQ_IPI config is enabled, CONFIG_IRQ_DOMAIN_HIERARCHY
> will be automatically selected (see the config definition in
> kernel/irq/Kconfig). If the IRQs hierarchy is needed for some another
> functionality like GENERIC_MSI_IRQ_DOMAIN or GPIOs then they will
> explicitly enable the IRQ_DOMAIN_HIERARCHY config thus activating the
> denoted .alloc and .free methods definitions.
>
> To sum up you can get rid of the IRQ_DOMAIN_HIERARCHY config
> force-select from this patch and make the MIPS GIC driver code a bit
> more coherent.
>
> @Marc, please correct me if were wrong.
Either way probably works correctly, but Samuel's approach is more
readable IMO. It is far easier to reason about a high-level feature
(GENERIC_IRQ_IPI) than an implementation detail (IRQ_DOMAIN_HIERARCHY).
If you really want to save a handful of bytes, you can make the
callbacks conditional on GENERIC_IRQ_IPI, and be done with it. But
this can come as an additional patch.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: fully convert arm to use dma-direct v3
On Thu, Jul 07, 2022 at 06:58:40AM +0200, Christoph Hellwig wrote: > On Wed, Jun 29, 2022 at 08:41:32AM +0200, Greg Kroah-Hartman wrote: > > On Wed, Jun 29, 2022 at 08:28:37AM +0200, Christoph Hellwig wrote: > > > Any comments or additional testing? It would be really great to get > > > this off the table. > > > > For the USB bits: > > > > Acked-by: Greg Kroah-Hartman > > So given that we're not making any progress on getting anyone interested > on the series, I'm tempted to just pull it into the dma-mapping tree > this weekend so that we'll finally have all architectures using the > common code. > > Anyone who has real concerns, please scream now. Sounds like a good plan to me, pull it in and let's see if anyone even notices. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [linux-next:master] BUILD REGRESSION 088b9c375534d905a4d337c78db3b3bfbb52c4a0
On Thu, Jul 07, 2022 at 02:56:34PM +0800, kernel test robot wrote: > tree/branch: > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master > branch HEAD: 088b9c375534d905a4d337c78db3b3bfbb52c4a0 Add linux-next > specific files for 20220706 > > Error/Warning reports: > > https://lore.kernel.org/linux-doc/202207070644.x48xoovs-...@intel.com > > Error/Warning: (recently discovered and may have been fixed) > > Documentation/arm/google/chromebook-boot-flow.rst: WARNING: document isn't > included in any toctree > arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x1108): undefined reference to > `__aeabi_ddiv' > arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x1124): undefined reference to > `__aeabi_ui2d' > arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x1164): undefined reference to > `__aeabi_dmul' > arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x1170): undefined reference to > `__aeabi_dadd' > arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x1180): undefined reference to > `__aeabi_dsub' > arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x1190): undefined reference to > `__aeabi_d2uiz' > arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x162c): undefined reference to > `__aeabi_d2iz' > arm-linux-gnueabi-ld: dc_dmub_srv.c:(.text+0x16b0): undefined reference to > `__aeabi_i2d' > dc_dmub_srv.c:(.text+0x10f8): undefined reference to `__aeabi_ui2d' > dc_dmub_srv.c:(.text+0x464): undefined reference to `__floatunsidf' > dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x33c): undefined > reference to `__floatunsidf' > drivers/pci/endpoint/functions/pci-epf-vntb.c:975:5: warning: no previous > prototype for 'pci_read' [-Wmissing-prototypes] > drivers/pci/endpoint/functions/pci-epf-vntb.c:984:5: warning: no previous > prototype for 'pci_write' [-Wmissing-prototypes] > drivers/vfio/vfio_iommu_type1.c:2141:35: warning: cast to smaller integer > type 'enum iommu_cap' from 'void *' [-Wvoid-pointer-to-enum-cast] > mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x34c): > undefined reference to `__floatunsidf' > mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x378): > undefined reference to `__divdf3' > mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x38c): > undefined reference to `__muldf3' > mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x3a0): > undefined reference to `__adddf3' > mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x3b4): > undefined reference to `__subdf3' > mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x3d4): > undefined reference to `__fixunsdfsi' > mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x750): > undefined reference to `__fixdfsi' > mips-linux-ld: dc_dmub_srv.c:(.text.dc_dmub_setup_subvp_dmub_command+0x7c0): > undefined reference to `__floatsidf' > powerpc-linux-ld: drivers/pci/endpoint/functions/pci-epf-vntb.c:174: > undefined reference to `ntb_link_event' > xtensa-linux-ld: dc_dmub_srv.c:(.text+0x468): undefined reference to > `__divdf3' > xtensa-linux-ld: dc_dmub_srv.c:(.text+0x46c): undefined reference to > `__muldf3' > xtensa-linux-ld: dc_dmub_srv.c:(.text+0x470): undefined reference to > `__adddf3' > xtensa-linux-ld: dc_dmub_srv.c:(.text+0x474): undefined reference to > `__subdf3' > xtensa-linux-ld: dc_dmub_srv.c:(.text+0x478): undefined reference to > `__fixunsdfsi' > xtensa-linux-ld: dc_dmub_srv.c:(.text+0x47c): undefined reference to > `__fixdfsi' > xtensa-linux-ld: dc_dmub_srv.c:(.text+0x480): undefined reference to > `__floatsidf' > xtensa-linux-ld: dc_dmub_srv.c:(.text+0x60c): undefined reference to > `__floatunsidf' > > Unverified Error/Warning (likely false positive, please contact us if > interested): > > arch/x86/events/core.c:2114 init_hw_perf_events() warn: missing error code > 'err' > drivers/android/binder.c:1481:19-23: ERROR: from is NULL but dereferenced. > drivers/android/binder.c:2920:29-33: ERROR: target_thread is NULL but > dereferenced. > drivers/android/binder.c:353:25-35: ERROR: node -> proc is NULL but > dereferenced. > drivers/android/binder.c:4888:16-20: ERROR: t is NULL but dereferenced. > drivers/base/regmap/regmap.c:1996:1: internal compiler error: in arc_ifcvt, > at config/arc/arc.c:9637 > drivers/char/random.c:869:1: internal compiler error: in arc_ifcvt, at > config/arc/arc.c:9637 > drivers/firmware/arm_scmi/clock.c:394:1: internal compiler error: in > arc_ifcvt, at config/arc/arc.c:9637 > drivers/firmware/arm_scmi/powercap.c:376:1: internal compiler error: in > arc_ifcvt, at config/arc/arc.c:9637 > drivers/gpu/drm/amd/amdgpu/../pm/powerplay/hwmgr/vega10_powertune.c:1214:1: > internal compiler error: in arc_ifcvt, at config/arc/arc.c:9637 > drivers/gpu/drm/amd/display/dc/os_types.h: drm/drm_print.h is included more > than once. > drivers/gpu/drm/bridge/ite-it66121.c:1398:1: internal compiler error: in > arc_ifcvt, at config/arc/arc.c:9637 > drivers/greybus/ope
Re: fully convert arm to use dma-direct v3
On Thu, Jul 7, 2022 at 6:58 AM Christoph Hellwig wrote: > On Wed, Jun 29, 2022 at 08:41:32AM +0200, Greg Kroah-Hartman wrote: > > On Wed, Jun 29, 2022 at 08:28:37AM +0200, Christoph Hellwig wrote: > > > Any comments or additional testing? It would be really great to get > > > this off the table. > > > > For the USB bits: > > > > Acked-by: Greg Kroah-Hartman > > So given that we're not making any progress on getting anyone interested > on the series, I'm tempted to just pull it into the dma-mapping tree > this weekend so that we'll finally have all architectures using the > common code. Yes, please do! Getting it into linux-next now should give plenty of time to test it with the automated kernelci and lkft systems, as well as Russell's Assabet. I'm sure we can fix up any regressions before this actually hits the 5.20 release. Arnd ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCHv2] iommu/arm-smmu-qcom: Add debug support for TLB sync timeouts
Hi Robin,
On 7/6/2022 10:15 PM, Robin Murphy wrote:
On 2022-05-26 05:14, Sai Prakash Ranjan wrote:
TLB sync timeouts can be due to various reasons such as TBU power down
or pending TCU/TBU invalidation/sync and so on. Debugging these often
require dumping of some implementation defined registers to know the
status of TBU/TCU operations and some of these registers are not
accessible in non-secure world such as from kernel and requires SMC
calls to read them in the secure world. So, add this debug support
to dump implementation defined registers for TLB sync timeout issues.
Signed-off-by: Sai Prakash Ranjan
---
Changes in v2:
* Use scm call consistently so that it works on older chipsets where
some of these regs are secure registers.
* Add device specific data to get the implementation defined register
offsets.
---
drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c | 161 ++---
drivers/iommu/arm/arm-smmu/arm-smmu.c | 2 +
drivers/iommu/arm/arm-smmu/arm-smmu.h | 1 +
3 files changed, 146 insertions(+), 18 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
index 7820711c4560..bb68aa85b28b 100644
--- a/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm/arm-smmu/arm-smmu-qcom.c
@@ -5,13 +5,27 @@
#include
#include
+#include
#include
#include
#include "arm-smmu.h"
+#define QCOM_DUMMY_VAL -1
+
+enum qcom_smmu_impl_reg_offset {
+ QCOM_SMMU_TBU_PWR_STATUS,
+ QCOM_SMMU_STATS_SYNC_INV_TBU_ACK,
+ QCOM_SMMU_MMU2QSS_AND_SAFE_WAIT_CNTR,
+};
+
+struct qcom_smmu_config {
+ const u32 *reg_offset;
+};
+
struct qcom_smmu {
struct arm_smmu_device smmu;
+ const struct qcom_smmu_config *cfg;
bool bypass_quirk;
u8 bypass_cbndx;
u32 stall_enabled;
@@ -22,6 +36,56 @@ static struct qcom_smmu *to_qcom_smmu(struct arm_smmu_device
*smmu)
return container_of(smmu, struct qcom_smmu, smmu);
}
+static void qcom_smmu_tlb_sync(struct arm_smmu_device *smmu, int page,
+ int sync, int status)
+{
+ int ret;
+ unsigned int spin_cnt, delay;
+ u32 reg, tbu_pwr_status, sync_inv_ack, sync_inv_progress;
+ struct qcom_smmu *qsmmu = to_qcom_smmu(smmu);
+ const struct qcom_smmu_config *cfg;
+
+ arm_smmu_writel(smmu, page, sync, QCOM_DUMMY_VAL);
+ for (delay = 1; delay < TLB_LOOP_TIMEOUT; delay *= 2) {
+ for (spin_cnt = TLB_SPIN_COUNT; spin_cnt > 0; spin_cnt--) {
+ reg = arm_smmu_readl(smmu, page, status);
+ if (!(reg & ARM_SMMU_sTLBGSTATUS_GSACTIVE))
+ return;
+ cpu_relax();
+ }
+ udelay(delay);
+ }
+
+ dev_err_ratelimited(smmu->dev,
+ "TLB sync timed out -- SMMU may be deadlocked\n");
Maybe consider a single ratelimit state for the whole function so all the
output stays together. If things go sufficiently wrong, mixed up bits of
partial output from different events may be misleadingly unhelpful (and at the
very least it'll be up to 5x more effective at the intent of limiting log spam).
Right, makes sense. Will change it.
+ cfg = qsmmu->cfg;
+ if (!cfg)
+ return;
+
+ ret = qcom_scm_io_readl(smmu->ioaddr +
cfg->reg_offset[QCOM_SMMU_TBU_PWR_STATUS],
+ &tbu_pwr_status);
+ if (ret)
+ dev_err_ratelimited(smmu->dev,
+ "Failed to read TBU power status: %d\n", ret);
+
+ ret = qcom_scm_io_readl(smmu->ioaddr +
cfg->reg_offset[QCOM_SMMU_STATS_SYNC_INV_TBU_ACK],
+ &sync_inv_ack);
+ if (ret)
+ dev_err_ratelimited(smmu->dev,
+ "Failed to read TBU sync/inv ack status: %d\n", ret);
+
+ ret = qcom_scm_io_readl(smmu->ioaddr +
cfg->reg_offset[QCOM_SMMU_MMU2QSS_AND_SAFE_WAIT_CNTR],
+ &sync_inv_progress);
+ if (ret)
+ dev_err_ratelimited(smmu->dev,
+ "Failed to read TCU syn/inv progress: %d\n", ret);
+
+ dev_err_ratelimited(smmu->dev,
+ "TBU: power_status %#x sync_inv_ack %#x sync_inv_progress
%#x\n",
+ tbu_pwr_status, sync_inv_ack, sync_inv_progress);
+}
+
static void qcom_adreno_smmu_write_sctlr(struct arm_smmu_device *smmu, int
idx,
u32 reg)
{
@@ -374,6 +438,7 @@ static const struct arm_smmu_impl qcom_smmu_impl = {
.def_domain_type = qcom_smmu_def_domain_type,
.reset = qcom_smmu500_reset,
.write_s2cr = qcom_smmu_write_s2cr,
+ .tlb_sync = qcom_smmu_tlb_sync,
};
static const struct arm_smmu_impl qcom_adreno_smmu_impl = {
@@ -382,12 +447,84 @@ static const struct arm_smmu_impl qcom_adreno_smmu_impl =
{
.reset = qcom_smmu500_reset,
.alloc_context_bank = qcom_adreno_smmu_alloc_context_bank,
.write_sctlr = qcom_adreno_smmu_write_sctlr,
+ .tlb_sync = qcom_smmu_tlb_sync,
+};
+
+/* Implementation Defined Register Space 0 register offsets */
+static const u32 qcom_smmu_impl0_reg_offset[] = {
+ [QC
Re: [PATCH v12 0/2] iommu/mediatek: TTBR up to 35bit support
On Wed, Jul 06, 2022 at 12:50:31PM +0100, Will Deacon wrote: > On Thu, Jun 30, 2022 at 05:29:24PM +0800, yf.w...@mediatek.com wrote: > > This patchset adds MediaTek TTBR up to 35bit support for single normal zone. > > > > Changes in v12: > > - Update [PATCH 1/2]: remove GENMASK(31, 7) > > - Update [PATCH 2/2]: remove MMU_PT_ADDR_MASK definition. > > For both patches: > > Acked-by: Will Deacon > > Joerg -- please can you pick these up for 5.20? Applied to arm/mediatek, thanks. ___ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
Re: [PATCH v3 RESEND 00/35] iommu/amd: Add multiple PCI segments support
On Wed, Jul 06, 2022 at 05:07:50PM +0530, Vasant Hegde wrote:
>As discussed in other thread, I have updated "From:" tag and
>resending patchset. No changes in the actual patch content.
>This patchset is based on top on "iommu/x86/amd" branch.
>Base commit : 0d10fe75911787 ("iommu/amd: Use try_cmpxchg64 in ")
Replaced it in my tree, thanks. I now also added a hook calling
checkpatch, which should catch such problems before I push the tree out.
Thanks,
Joerg
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
