DPDK patches and discussions
 help / color / mirror / Atom feed
From: Ravi Kerur <rkerur@gmail.com>
To: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] IXGBE, IOMMU DMAR DRHD handling fault issue
Date: Fri, 9 Feb 2018 09:41:33 -0800	[thread overview]
Message-ID: <CAFb4SLCTpk7eWe6WgybdfEbN9DtW5OTenyxLmtpZ0JxnO55s-w@mail.gmail.com> (raw)
In-Reply-To: <d4519395-b1fb-90fc-17c0-ac5cf1583d9a@intel.com>

On Thu, Feb 8, 2018 at 3:20 AM, Burakov, Anatoly <anatoly.burakov@intel.com>
wrote:

> On 06-Feb-18 5:55 PM, Ravi Kerur wrote:
>
>>
>> Hi Anatoly,
>>
>> I am actually confused with the state of vIOMMU + DPDK. Can you please
>> help me clarify?
>>
>> I tested following DPDK versions
>>
>> (1) DPDK 17.11, exhibits the issue (IOMMU width as reported by RedHat and
>> solution is to prevent using the patch)
>> (2) DPDK 17.05.02 (stable release) using 'testpmd' I was able to bind a
>> device in VM with VFIO driver and no DMAR error message on host
>> (3) DPDK 16.11.02 (stable release) using 'testpmd' I was able to bind a
>> device in VM with VFIO driver and no DMAR error message on host
>>
>> Clearly issue seen in 17.11 without the patch you mentioned is a
>> regression or the issue was masked in earlier DPDK version?  I did not test
>> traffic with any DPDK version because I wanted to first get DMAR errors on
>> host gone.
>>
>> Our application 'v1' is integrated with DPDK 16.11 and 'v2' is integrated
>> with DPDK 17.05.01. In both 'v1' and 'v2' cases I don't see IOMMU width
>> error messages on VM, however, DMAR error messages are seen host. I am not
>> able to relate what causes DMAR error messages on host?
>>
>>
>> Thanks.
>>
>>
> Hi Ravi,
>
> vIOMMU support is out of our hands, really - we can only make use of
> hardware (or emulation of it) that is available. 39-bit wide address *can*
> work, you just have to be lucky and get PA addresses that would fit into 39
> bits (so under 512G limit), because we set up IOVA addresses to be 1:1 to
> physical addresses. We could, in principle, set up IOVA addresses to go
> from zero instead of them being a 1:1 mapping to physical addresses, but
> that would introduce need to translate addresses between IOVA and physical
> in some cases (e.g. KNI).
>
> I'm not aware of any changes between 16.11 and 17.11 (and indeed 18.02)
> that would make or break support for 39-bit wide PA addresses for IOMMU. It
> is possible that VF/PF drivers do something differently which results in
> DMAR errors showing up sooner rather than later, but as far as VFIO support
> itself is concerned, there were no major changes in those releases.
>
>
Hi Anatoly,

Thank you for your explanation. I would like to ask one more thing as I
need to get v-iommu+ dpdk working in VM. Can you please tell me what
determines 'Host Address Width", I know my question has nothing to do with
dpdk and this is a dpdk list, but if you have any information please share
it? I googled and found couple of ways to influence 'Host Address Width =
46' in guest as well (since dpdk + iommu works fine on host and DMAR on
host reports address width as 46).

(1) Qemu has CPU param 'host-phys-bits' boolean, when set to true copies it
from host
(2) Qemu has 'phys-bits'  integer, when set to '46' should influence guest

Using above options when instantiating a VM doesn't help, Guest VM still
ends up with 'Host address width = 39'.

(3) There is another Qemu option 'x-aw-bits' which is for VT-d which can be
set to '39' or '48'. This doesn't help either.

Thanks.

-- 
> Thanks,
> Anatoly
>

  reply	other threads:[~2018-02-09 17:41 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-23 17:25 Ravi Kerur
2018-01-24 10:31 ` Burakov, Anatoly
2018-01-24 19:13   ` Ravi Kerur
2018-01-25 10:49     ` Burakov, Anatoly
2018-01-29 22:35       ` Ravi Kerur
2018-01-31  9:59         ` Burakov, Anatoly
2018-01-31 21:51           ` Ravi Kerur
2018-02-01 10:10             ` Burakov, Anatoly
2018-02-01 19:26               ` Ravi Kerur
2018-02-02 10:28                 ` Burakov, Anatoly
2018-02-02 20:21                   ` Ravi Kerur
2018-02-02 20:51                     ` Ravi Kerur
2018-02-05 10:01                       ` Burakov, Anatoly
2018-02-06 17:55                         ` Ravi Kerur
2018-02-08 11:20                           ` Burakov, Anatoly
2018-02-09 17:41                             ` Ravi Kerur [this message]
2018-02-10 10:11                               ` Burakov, Anatoly
2018-02-10 10:58         ` Burakov, Anatoly
2018-02-10 17:53           ` Ravi Kerur
2018-02-12 10:13             ` Burakov, Anatoly
2018-02-12 22:00               ` Ravi Kerur
2018-02-13 14:31                 ` Burakov, Anatoly
2018-02-14 20:00                   ` Ravi Kerur
2018-02-15 10:28                     ` Burakov, Anatoly
2018-02-15 18:27                       ` Ravi Kerur
2018-02-15 20:53                         ` Ravi Kerur
2018-02-16  9:41                           ` Burakov, Anatoly
2019-01-15  7:07                             ` Hu, Xuekun
2019-01-15 11:22                               ` Burakov, Anatoly
2019-01-15 13:07                                 ` Hu, Xuekun
2019-01-21 13:18                                 ` Hu, Xuekun
2019-01-21 13:39                                   ` Burakov, Anatoly
2019-01-21 14:44                                     ` Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAFb4SLCTpk7eWe6WgybdfEbN9DtW5OTenyxLmtpZ0JxnO55s-w@mail.gmail.com \
    --to=rkerur@gmail.com \
    --cc=anatoly.burakov@intel.com \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).