[dpdk-dev] [PATCH v2] vfio: noiommu check error handling

[Jonas Pfefferle]

  On Tue, 16 Jan 2018 18:01:32 +0100
  Maxime Coquelin <maxime.coquelin at redhat.com> wrote:
> Hi Jonas,
> 
> On 01/16/2018 05:08 PM, Jonas Pfefferle wrote:
>> 
>>   On Mon, 15 Jan 2018 17:11:58 +0100
>>   Thomas Monjalon <thomas at monjalon.net> wrote:
>>> 15/01/2018 13:22, Jonas Pfefferle:
>>>>
>>>>   On Sat, 13 Jan 2018 23:49:30 +0100
>>>>   Thomas Monjalon <thomas at 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
> 
> I agree adding an exception in drivers/bus/pci/linux/pci.c isn't 
>great,
> but we need first to fix a regression introduced in v17.11 LTS, and
> IMHO, we cannot do a big rework as the fix is to be backported.
> 
> Once fixed, I agree we should work on a refactoring. I don't know if
> eal_vfio is the right place though, as in my case for example I 
>cannot
> get the information needed through vfio ioctl().
> 
> Out of curiosity, what prevents sPAPR to use VA mode for now?
> 
> Maxime

Sounds good to me.

The current sPAPR Linux driver cannot use virtual addresses because 
the DMA window size is restricted to RAM size and always starts at 0. 
This is not a hardware restriction and we are working on allowing to 
create arbitrary size windows.

Jonas