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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.