On Mon, 15 Jan 2018 17:11:58 +0100
Thomas Monjalon <tho...@monjalon.net> wrote:
15/01/2018 13:22, Jonas Pfefferle:
On Sat, 13 Jan 2018 23:49:30 +0100
Thomas Monjalon <tho...@monjalon.net> wrote:
> 13/01/2018 13:15, Burakov, Anatoly:
>> On 11-Jan-18 11:45 PM, Thomas Monjalon wrote:
>> > 07/11/2017 10:50, Jonas Pfefferle1:
>> >>> Is there something urgent for 17.11?
>> >>> Or can it be refined in 18.02?
>> >>
>> >> Nothing urgent. We can refine this for 18.02.
>> >>
>> >>> Anatoly, any thought?
>> >
>> > Anatoly, Jonas, how do you want to proceed with this patch?
>> >
>>
>> I don't see anything to be refined here, it's a simple bug fix -
>>code
>> assumes noiommu mode support is always available, when it might
not
>>be
>> the case on older kernels.
>
> As a bug fix, the title must start with "fix" and a tag "Fixes:"
> must be added to help with backport.
> At the same time, the explanation of the bug must be added in
> the commit log please.
>
> Thanks
It's not really a bug fix since it does not change the semantic of
the
function but just adds nicer error handling.
Regarding redefining the code: What I don't like is the special
cases
we have to check for when using the sPAPR iommu because it does not
support VA mappings yet. I think we should decide which iova mode to
use based on the iommu types available, i.e. each iommu type should
report which iova type it supports. Thoughts?
Have you looked at what Maxime did?
https://dpdk.org/dev/patchwork/patch/33650/
How does it affect this patch?
IMO it has the same problem. We shouldn't add more exception cases in
drivers/bus/pci/linux/pci.c but instead keep all the information about
what an IOMMU can do in lib/librte_eal/linuxapp/eal/eal_vfio.c
