linux-kernel - Re: [PATCH 3/4 RESEND] Drivers: hv: vmbus: Propagate VMbus coherence to each VMbus device

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e2ceb902-6fe2-bcb9-259a-f120901672b6@arm.com>
Date:   Thu, 17 Mar 2022 16:52:37 +0000
From:   Robin Murphy <robin.murphy@....com>
To:     Michael Kelley <mikelley@...rosoft.com>, sthemmin@...rosoft.com,
        kys@...rosoft.com, haiyangz@...rosoft.com, wei.liu@...nel.org,
        decui@...rosoft.com, rafael@...nel.org, lenb@...nel.org,
        lorenzo.pieralisi@....com, robh@...nel.org, kw@...ux.com,
        bhelgaas@...gle.com, hch@....de, m.szyprowski@...sung.com,
        linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-hyperv@...r.kernel.org, linux-pci@...r.kernel.org,
        iommu@...ts.linux-foundation.org
Subject: Re: [PATCH 3/4 RESEND] Drivers: hv: vmbus: Propagate VMbus coherence
 to each VMbus device

On 2022-03-17 16:25, Michael Kelley via iommu wrote:
> VMbus synthetic devices are not represented in the ACPI DSDT -- only
> the top level VMbus device is represented. As a result, on ARM64
> coherence information in the _CCA method is not specified for
> synthetic devices, so they default to not hardware coherent.
> Drivers for some of these synthetic devices have been recently
> updated to use the standard DMA APIs, and they are incurring extra
> overhead of unneeded software coherence management.
> 
> Fix this by propagating coherence information from the VMbus node
> in ACPI to the individual synthetic devices. There's no effect on
> x86/x64 where devices are always hardware coherent.
> 
> Signed-off-by: Michael Kelley <mikelley@...rosoft.com>
> ---
>   drivers/hv/vmbus_drv.c | 15 +++++++++++++++
>   1 file changed, 15 insertions(+)
> 
> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> index 12a2b37..c0e993ad 100644
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c
> @@ -904,6 +904,21 @@ static int vmbus_probe(struct device *child_device)
>   			drv_to_hv_drv(child_device->driver);
>   	struct hv_device *dev = device_to_hv_device(child_device);
>   	const struct hv_vmbus_device_id *dev_id;
> +	enum dev_dma_attr coherent;
> +
> +	/*
> +	 * On ARM64, propagate the DMA coherence setting from the top level
> +	 * VMbus ACPI device to the child VMbus device being added here.
> +	 * Older Hyper-V ARM64 versions don't set the _CCA method on the
> +	 * top level VMbus ACPI device as they should.  Treat these cases
> +	 * as DMA coherent since that's the assumption made by Hyper-V.
> +	 *
> +	 * On x86/x64 these calls assume coherence and have no effect.
> +	 */
> +	coherent = acpi_get_dma_attr(hv_acpi_dev);
> +	if (coherent == DEV_DMA_NOT_SUPPORTED)
> +		coherent = DEV_DMA_COHERENT;
> +	acpi_dma_configure(child_device, coherent);

acpi_dma_configure is for devices represented in ACPI. The commit 
message implies that these VMBus devices aren't represented in ACPI. 
What gives?

Robin.

>   
>   	dev_id = hv_vmbus_get_id(drv, dev);
>   	if (drv->probe) {