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: Thu, 1 Feb 2018 11:26:29 -0800 [thread overview]
Message-ID: <CAFb4SLDGoQTW0Xnhz-H7eEOii54Uyo-Rfz9p5B309xAjkFfaLQ@mail.gmail.com> (raw)
In-Reply-To: <3464b900-8648-c128-e959-dc60a8883a2d@intel.com>
On Thu, Feb 1, 2018 at 2:10 AM, Burakov, Anatoly <anatoly.burakov@intel.com>
wrote:
> On 31-Jan-18 9:51 PM, Ravi Kerur wrote:
>
>>
>> Hi Anatoly,
>>
>> Thanks. I am following wiki link below which uses vIOMMU with DPDK as a
>> use-case and instantiate VM as specified with Q35 chipset in Qemu.
>>
>> https://wiki.qemu.org/Features/VT-d
>>
>> Qemu-version is 2.11
>> Host kernel 4.9
>> Guest kernel 4.4
>>
>> I can only guess that guest kernel needs an upgrade in my setup to work
>> correctly, if versions on my setup rings a bell on not having support
>> kindly let me know.
>>
>> When 'modprobe vfio enable_unsafe_noiommu_node=Y' is executed on guest I
>> get following error
>> ...
>> vfio: unknown parameter 'enable_unsafe_noiommu_node' ignored
>> ...
>>
>> in guest.
>>
>> Thanks.
>>
>
>
AFAIK kernel 4.4 should have noiommu mode - it was introduced in 3.1x days.
> However, in order for that to work, kernel also has to be built with this
> mode enabled. My guess is, whoever is the supplier of your kernel, did not
> do that. You should double-check the kernel configuration of your
> distribution.
>
> However, if you have vIOMMU in QEMU, you shouldn't need noiommu mode -
> "regular" vfio should work fine. noiommu mode should only be needed if you
> know you don't have IOMMU enabled in your kernel, and even if you can't
> enable it, you can still use igb_uio.
>
> Hi Anatoly,
Do you suggest I take this discussion to kvm/qemu mailing list as I am not
sure which component has the issue? I check dmesg for BIOS physical memory
map and address reported as fault by DMAR is reported by BIOS as usable on
both host and vm.
[ 4539.597737] DMAR: [DMA Read] Request device [04:10.0] fault addr *33a128000
*[fault reason 06] PTE Read access is not set
dmesg | grep BIOS
[ 0.000000] e820: BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009afff] usable
[ 0.000000] BIOS-e820: [mem 0x000000000009b000-0x000000000009ffff]
reserved
[ 0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff]
reserved
[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x000000007938afff] usable
[ 0.000000] BIOS-e820: [mem 0x000000007938b000-0x000000007994bfff]
reserved
[ 0.000000] BIOS-e820: [mem 0x000000007994c000-0x000000007999cfff] ACPI
data
[ 0.000000] BIOS-e820: [mem 0x000000007999d000-0x0000000079f7dfff] ACPI
NVS
[ 0.000000] BIOS-e820: [mem 0x0000000079f7e000-0x000000007bd37fff]
reserved
[ 0.000000] BIOS-e820: [mem 0x000000007bd38000-0x000000007bd38fff] usable
[ 0.000000] BIOS-e820: [mem 0x000000007bd39000-0x000000007bdbefff]
reserved
[ 0.000000] BIOS-e820: [mem 0x000000007bdbf000-0x000000007bffffff] usable
[ 0.000000] BIOS-e820: [mem 0x000000007c000000-0x000000008fffffff]
reserved
[ 0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed44fff]
reserved
[ 0.000000] BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff]
reserved
[* 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000407fffffff]
usable*
Kindly let me know your inputs.
Thanks.
--
> Thanks,
> Anatoly
>
next prev parent reply other threads:[~2018-02-01 19:26 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 [this message]
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
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=CAFb4SLDGoQTW0Xnhz-H7eEOii54Uyo-Rfz9p5B309xAjkFfaLQ@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).