From: bugzilla-daemon@bugzilla.kernel.org
To: kvm@vger.kernel.org
Subject: [Bug 82761] DMAR:[fault reason 06] PTE Read access is not set
Date: Wed, 20 Aug 2014 07:50:01 +0000 [thread overview]
Message-ID: <bug-82761-28872-itXqBANW2q@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-82761-28872@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=82761
--- Comment #8 from Ansa89 <ansalonistefano@gmail.com> ---
(In reply to Alex Williamson from comment #6)
> Are these 3 separate NICs plugged into PCI slots on the motherboard or is
> this a single triple-port card with embedded PCIe-to-PCI bridge?
They are 3 separate NICs plugged into 3 separate PCI slots.
> You might be able to run the IOMMU in passthrough mode with iommu=pt
> r8169.use_dac=1, but note the warning in modinfo "use_dac:Enable PCI DAC.
> Unsafe on 32 bit PCI slot." Unfortunately if you don't enable use_dac, then
> intel_iommu will ignore the passthrough option for these devices.
I tried using "intel_iommu=pt", but it didn't work (resulted in vt-d disabled).
However with "intel_iommu=on iommu=pt" the errors remain (probably because I
didn't add "r8169.use_dac=1").
I'm on a 64 bit system, but I think it has nothing to with "32 bit PCI slot".
> Also note that this problem has nothing to do with Virtualization/KVM.
> Drivers/Network or perhaps Drivers/PCI would be a more appropriate
> classification.
I searched for "IOMMU" section but it doesn't exist.
I will probably change classification to "Drivers/PCI".
(In reply to Alex Williamson from comment #7)
> I'm guessing this might be the motherboard here: MSI ZH77A-G43
Yes, that is my motherboard.
> Since you're apparently trying to use VT-d on this system for KVM and
> therefore presumably device assignment, I'll note that you will never be
> able to successfully assign the conventional PCI devices separately between
> guests or between host and guests. The IOMMU does not have the granularity
> to create separate IOMMU domains per PCI slot in this topology. Also, some
> (all?) Realtek NICs have some strange backdoors to PCI configuration space
> that make them poor targets for PCI device assignment:
Yes, I'm trying to do device assignment, but not with those NICs: I want to
pass only the nVidia PCIe VGA card to guest; while all NICs (and the integrated
VGA card) will remain available to host.
It would be nice if there would be a way to prevent IOMMU on these NICs (or
something like that).
SIDE NOTE: in the qemu commit they talk about RTL8168, but I have real RTL8169
devices (the only RTL8168 device is the integrated NIC and for that device I'm
using r8168 driver from realtek compiled by hand).
--
You are receiving this mail because:
You are watching the assignee of the bug.
next prev parent reply other threads:[~2014-08-20 7:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-19 12:18 [Bug 82761] New: DMAR:[fault reason 06] PTE Read access is not set bugzilla-daemon
2014-08-19 12:58 ` [Bug 82761] " bugzilla-daemon
2014-08-19 16:37 ` bugzilla-daemon
2014-08-19 16:51 ` bugzilla-daemon
2014-08-19 17:28 ` bugzilla-daemon
2014-08-19 21:24 ` bugzilla-daemon
2014-08-19 21:55 ` bugzilla-daemon
2014-08-19 22:18 ` bugzilla-daemon
2014-08-20 7:50 ` bugzilla-daemon [this message]
2014-08-21 15:28 ` bugzilla-daemon
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=bug-82761-28872-itXqBANW2q@https.bugzilla.kernel.org/ \
--to=bugzilla-daemon@bugzilla.kernel.org \
--cc=kvm@vger.kernel.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