| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <09873368-dacb-f2a2-ca93-9e164711a876@loongson.cn>
Date: Mon, 29 Aug 2022 21:00:30 +0800
From: Jianmin Lv <lvjianmin@...ngson.cn>
To: Lorenzo Pieralisi <lpieralisi@...nel.org>,
Robin Murphy <robin.murphy@....com>
Cc: guohanjun@...wei.com, sudeep.holla@....com, rafael@...nel.org,
lenb@...nel.org, robert.moore@...el.com,
linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org
Subject: Re: [PATCH V2 1/2] ACPI / scan: Support multiple dma windows with
different offsets
On 2022/8/12 下午3:52, Lorenzo Pieralisi wrote:
> On Fri, Aug 05, 2022 at 01:46:07PM +0100, Robin Murphy wrote:
>
> [...]
>
>>> -int acpi_dma_get_range(struct device *dev, u64 *dma_addr, u64 *offset,
>>> - u64 *size)
>>> +int acpi_dma_get_range(struct device *dev, const struct bus_dma_region **map)
>>> {
>>> struct acpi_device *adev;
>>> LIST_HEAD(list);
>>> struct resource_entry *rentry;
>>> int ret;
>>> struct device *dma_dev = dev;
>>> - u64 len, dma_start = U64_MAX, dma_end = 0, dma_offset = 0;
>>> + int num_ranges = 0;
>>> + struct bus_dma_region *r;
>>> /*
>>> * Walk the device tree chasing an ACPI companion with a _DMA
>>> @@ -1525,31 +1526,31 @@ int acpi_dma_get_range(struct device *dev, u64 *dma_addr, u64 *offset,
>>> ret = acpi_dev_get_dma_resources(adev, &list);
>>> if (ret > 0) {
>>> + list_for_each_entry(rentry, &list, node)
>>> + num_ranges++;
>>
>> We already have the number of resources in ret.
>>
>> Looking at this, I also now wonder if we're doing the right thing if the
>> object is present but contains no resources. The spec isn't clear whether
>> that's even really valid, but if it is, is it meaningful? It seems we'd
>> currently consider an empty object equivalent to no object, but if anything
>> it should perhaps be interpreted as the opposite, i.e. that no DMA is
>> possible because the bus does not decode any ranges. Is anyone more familiar
>> with the intent of the spec here?
>
> I think we are currently considering no object differently from an
> empty object, since for no object we would return -ENODEV in
> acpi_dma_get_range(), we would not even get to parsing the resources
> (and return 0) and we would fall back to checking IORT to gather the
> DMA address space size.
>
> I think you are right, we should change the behaviour if an object
> is present but it has no resources though, by reading the specs an
> empty _DMA object implies no DMA is possible and that's not what
> we are doing at the moment (hopefully there is no firmware out
> there with such a set-up but there is only one way to discover it).
>
> This behavioural change should be a separate patch obviously for
> bisectability (and a possible revert).
>
> Lorenzo
>
Hi, Robin and Lorenzo
For the issue of empty _DMA, I consulted ASWG(ACPI Spec Work Group), and
received an reply from some people that an _DMA object is allowed to
contain *no* resources, and indicates disabled DMA(some arm systems are
being used empty _DMA as an indicator to the OS that DMA is disabled for
specified device). ASWG has isssued an request to clarify it in spec
after approved.
I think we can submit a seperate patch for that after it is confirmed.
Thanks.
>> Thanks,
>> Robin.
>>
>>> +
>>> + r = kcalloc(num_ranges + 1, sizeof(*r), GFP_KERNEL);
>>> + if (!r) {
>>> + ret = -ENOMEM;
>>> + goto out;
>>> + }
>>> +
>>> + *map = r;
>>> +
>>> list_for_each_entry(rentry, &list, node) {
>>> - if (dma_offset && rentry->offset != dma_offset) {
>>> + if (rentry->res->start >= rentry->res->end) {
>>> ret = -EINVAL;
>>> - dev_warn(dma_dev, "Can't handle multiple windows with different offsets\n");
>>> + dev_dbg(dma_dev, "Invalid DMA regions configuration\n");
>>> goto out;
>>> }
>>> - dma_offset = rentry->offset;
>>> -
>>> - /* Take lower and upper limits */
>>> - if (rentry->res->start < dma_start)
>>> - dma_start = rentry->res->start;
>>> - if (rentry->res->end > dma_end)
>>> - dma_end = rentry->res->end;
>>> - }
>>> - if (dma_start >= dma_end) {
>>> - ret = -EINVAL;
>>> - dev_dbg(dma_dev, "Invalid DMA regions configuration\n");
>>> - goto out;
>>> + r->cpu_start = rentry->res->start;
>>> + r->dma_start = rentry->res->start - rentry->offset;
>>> + r->size = rentry->res->end - rentry->res->start + 1;
>>> + r->offset = rentry->offset;
>>> + r++;
>>> }
>>> - *dma_addr = dma_start - dma_offset;
>>> - len = dma_end - dma_start;
>>> - *size = max(len, len + 1);
>>> - *offset = dma_offset;
>>> }
>>> out:
>>> acpi_dev_free_resource_list(&list);
>>> @@ -1639,20 +1640,19 @@ int acpi_dma_configure_id(struct device *dev, enum dev_dma_attr attr,
>>> const u32 *input_id)
>>> {
>>> const struct iommu_ops *iommu;
>>> - u64 dma_addr = 0, size = 0;
>>> if (attr == DEV_DMA_NOT_SUPPORTED) {
>>> set_dma_ops(dev, &dma_dummy_ops);
>>> return 0;
>>> }
>>> - acpi_arch_dma_setup(dev, &dma_addr, &size);
>>> + acpi_arch_dma_setup(dev);
>>> iommu = acpi_iommu_configure_id(dev, input_id);
>>> if (PTR_ERR(iommu) == -EPROBE_DEFER)
>>> return -EPROBE_DEFER;
>>> - arch_setup_dma_ops(dev, dma_addr, size,
>>> + arch_setup_dma_ops(dev, 0, U64_MAX,
>>> iommu, attr == DEV_DMA_COHERENT);
>>> return 0;
>>> diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
>>> index 0dc1ea0b..e106073 100644
>>> --- a/include/acpi/acpi_bus.h
>>> +++ b/include/acpi/acpi_bus.h
>>> @@ -611,8 +611,7 @@ struct acpi_pci_root {
>>> int acpi_iommu_fwspec_init(struct device *dev, u32 id,
>>> struct fwnode_handle *fwnode,
>>> const struct iommu_ops *ops);
>>> -int acpi_dma_get_range(struct device *dev, u64 *dma_addr, u64 *offset,
>>> - u64 *size);
>>> +int acpi_dma_get_range(struct device *dev, const struct bus_dma_region **map);
>>> int acpi_dma_configure_id(struct device *dev, enum dev_dma_attr attr,
>>> const u32 *input_id);
>>> static inline int acpi_dma_configure(struct device *dev,
>>> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
>>> index 44975c1..34e0545 100644
>>> --- a/include/linux/acpi.h
>>> +++ b/include/linux/acpi.h
>>> @@ -280,12 +280,12 @@ int acpi_table_parse_madt(enum acpi_madt_type id,
>>> #ifdef CONFIG_ARM64
>>> void acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa);
>>> -void acpi_arch_dma_setup(struct device *dev, u64 *dma_addr, u64 *dma_size);
>>> +void acpi_arch_dma_setup(struct device *dev);
>>> #else
>>> static inline void
>>> acpi_numa_gicc_affinity_init(struct acpi_srat_gicc_affinity *pa) { }
>>> static inline void
>>> -acpi_arch_dma_setup(struct device *dev, u64 *dma_addr, u64 *dma_size) { }
>>> +acpi_arch_dma_setup(struct device *dev) { }
>>> #endif
>>> int acpi_numa_memory_affinity_init (struct acpi_srat_mem_affinity *ma);
>>> @@ -974,8 +974,7 @@ static inline enum dev_dma_attr acpi_get_dma_attr(struct acpi_device *adev)
>>> return DEV_DMA_NOT_SUPPORTED;
>>> }
>>> -static inline int acpi_dma_get_range(struct device *dev, u64 *dma_addr,
>>> - u64 *offset, u64 *size)
>>> +static inline int acpi_dma_get_range(struct device *dev, const struct bus_dma_region **map)
>>> {
>>> return -ENODEV;
>>> }
Powered by blists - more mailing lists