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: <249e5876-f8c6-0236-16fa-a611a9f9e0b2@arm.com>
Date:   Fri, 18 Mar 2022 11:07:36 +0000
From:   Robin Murphy <robin.murphy@....com>
To:     "Michael Kelley (LINUX)" <mikelley@...rosoft.com>,
        Stephen Hemminger <sthemmin@...rosoft.com>,
        KY Srinivasan <kys@...rosoft.com>,
        Haiyang Zhang <haiyangz@...rosoft.com>,
        "wei.liu@...nel.org" <wei.liu@...nel.org>,
        Dexuan Cui <decui@...rosoft.com>,
        "rafael@...nel.org" <rafael@...nel.org>,
        "lenb@...nel.org" <lenb@...nel.org>,
        "lorenzo.pieralisi@....com" <lorenzo.pieralisi@....com>,
        "robh@...nel.org" <robh@...nel.org>, "kw@...ux.com" <kw@...ux.com>,
        "bhelgaas@...gle.com" <bhelgaas@...gle.com>,
        "hch@....de" <hch@....de>,
        "m.szyprowski@...sung.com" <m.szyprowski@...sung.com>,
        "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        "iommu@...ts.linux-foundation.org" <iommu@...ts.linux-foundation.org>
Subject: Re: [PATCH 2/4 RESEND] dma-mapping: Add wrapper function to set
 dma_coherent

On 2022-03-17 19:13, Michael Kelley (LINUX) wrote:
> From: Robin Murphy <robin.murphy@....com> Sent: Thursday, March 17, 2022 10:20 AM
>>
>> On 2022-03-17 16:25, Michael Kelley via iommu wrote:
>>> Add a wrapper function to set dma_coherent, avoiding the need for
>>> complex #ifdef's when setting it in architecture independent code.
>>
>> No. It might happen to work out on the architectures you're looking at,
>> but if Hyper-V were ever to support, say, AArch32 VMs you might see the
>> problem. arch_setup_dma_ops() is the tool for this job.
>>
> 
> OK.   There's currently no vIOMMU in a Hyper-V guest, so presumably the
> code would call arch_setup_dma_ops() with the dma_base, size, and iommu
> parameters set to 0 and NULL.  This call can then be used in Patch 3 instead
> of acpi_dma_configure(), and in the Patch 4 hv_dma_configure() function
> as you suggested.  arch_setup_dma_ops() is not exported, so I'd need to
> wrap it in a Hyper-V specific function in built-in code that is exported.
> 
> But at some point in the future if there's a vIOMMU in Hyper-V guests,
> this approach will need some rework.
> 
> Does that make sense?  Thanks for your input and suggestions ...

Yes, that's essentially what I had in mind. If you did present a vIOMMU 
to the guest, presumably you'd either have to construct a regular 
IORT/VIOT, and thus end up adding the root complex to the ACPI namespace 
too so it can be referenced, at which point it would all get picked up 
by the standard machinery, or come up with some magic VMBus mechanism 
that would need a whole load of work to wire up in all the relevant 
places anyway.

(But please lean extremely heavily towards the former option!)

Thanks,
Robin.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ