linux-kernel - Re: [PATCH v1] iommu/s390: Declare s390 iommu reserved regions

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: <668fe734-e4bf-0342-ab8c-df54d9022db4@arm.com>
Date:   Fri, 18 Jan 2019 13:51:11 +0000
From:   Jean-Philippe Brucker <jean-philippe.brucker@....com>
To:     pmorel@...ux.ibm.com, Robin Murphy <robin.murphy@....com>,
        gerald.schaefer@...ibm.com
Cc:     linux-s390@...r.kernel.org, walling@...ux.ibm.com,
        iommu@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
        alex.williamson@...hat.com
Subject: Re: [PATCH v1] iommu/s390: Declare s390 iommu reserved regions

Hi Pierre,

On 18/01/2019 13:29, Pierre Morel wrote:
> On 17/01/2019 14:02, Robin Murphy wrote:
>> On 15/01/2019 17:37, Pierre Morel wrote:
>>> The s390 iommu can only allow DMA transactions between the zPCI device
>>> entries start_dma and end_dma.
>>>
>>> Let's declare the regions before start_dma and after end_dma as
>>> reserved regions using the appropriate callback in iommu_ops.
>>>
>>> The reserved region may later be retrieved from sysfs or from
>>> the vfio iommu internal interface.
>>
>> For this particular case, I think the best solution is to give VFIO
>> the ability to directly interrogate the domain geometry (which s390
>> appears to set correctly already). The idea of reserved regions was
>> really for 'unexpected' holes inside the usable address space - using
>> them to also describe places that are entirely outside that address
>> space rather confuses things IMO.
>>
>> Furthermore, even if we *did* end up going down the route of actively
>> reserving addresses beyond the usable aperture, it doesn't seem
>> sensible for individual drivers to do it themselves when the core API
>> already describes the relevant information generically.
>>
>> Robin.
> 
> Robin,
> 
> I already posted a patch retrieving the geometry through
> VFIO_IOMMU_GET_INFO using a specific capability for the geometry [1],
> and AFAIU, Alex did not agree with this.

On arm we also need to report the IOMMU geometry to userspace (max IOVA
size in particular). Shameer has been working on a solution [2] that
presents a unified view of both geometry and reserved regions into the
VFIO_IOMMU_GET_INFO call, and I think we should go with that. If I
understand correctly it's currently blocked on the RMRR problem and
we're waiting for Jacob or Ashok to take a look at it, as Kevin pinged
them on thread [1]?

[2] https://lkml.org/lkml/2018/4/18/293

Thanks,
Jean

> 
> What is different in what you propose?
> 
> @Alex: I was hoping that this patch goes in your direction. What do you
> think?
> 
> Thanks,
> Pierre
> 
> [1]: https://lore.kernel.org/patchwork/patch/1030369/
> 
>>
>>>
>>> This seems to me related with the work Shameer has started on
>>> vfio_iommu_type1 so I add Alex and Shameer to the CC list.
>>>
>>>
>>> Pierre Morel (1):
>>>    iommu/s390: Declare s390 iommu reserved regions
>>>
>>>   drivers/iommu/s390-iommu.c | 29 +++++++++++++++++++++++++++++
>>>   1 file changed, 29 insertions(+)
>>>
>>
> 
>