From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Thierry Laurion <thierry.laurion@gmail.com>,
xen-devel@lists.xen.org,
qubes-devel <qubes-devel@googlegroups.com>
Subject: Re: pre Sandy bridge IOMMU support (gm45)
Date: Mon, 25 Jan 2016 10:01:37 +0000 [thread overview]
Message-ID: <56A5F281.1080006@citrix.com> (raw)
In-Reply-To: <CAAzJznzd67WAk=GQQDCZWETxQO1BGS+-AWHuKpWkNVJCbCqpbw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1241 bytes --]
On 24/01/16 18:21, Thierry Laurion wrote:
> Hi devs!
>
> XEN devs:
> As per short discussion with ktemkin earlier in January in #xen:
>
> "ktemkin Jan 10, 2016 16:21:50
> This test patch did appear to make the system work, though:
> https://gist.github.com/ktemkin/0e81b93654ae800a5609
>
> ktemkin Jan 10, 2016 16:24:55
> Only real difference I see between that and the upstream behavior
> (besides limiting things to dom0 so things weren't accidentally passed
> through) is the call to disable_pmr on line 117 before aborting."
>
>
>
> Makes total sense to my early understanding, since it seems that it is
> said that vt-d engine gets disabled, but disable_pmr(iommu) function
> is not called to enforce.
>
> What do you think?
There is some confusion here.
"Unfortunately, quirks specific to the Clarkdale/Nehalem integrated
graphics device (IGD) do not function correctly with Xen's VT-d
implementation"
Either
1) There is a chipset errata which prevents it from functioning
correctly, or
2) Xen's VT-d code doesn't program the chip correctly.
Which is it?
If it is 1), then there is a very good case for quirking the affected
chipsets and unilaterally disabling them. If it is 2), then the VT-d
code should be corrected.
~Andrew
[-- Attachment #1.2: Type: text/html, Size: 2542 bytes --]
[-- Attachment #2: Type: text/plain, Size: 126 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
next prev parent reply other threads:[~2016-01-25 10:01 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-23 7:38 pre Sandy bridge IOMMU support (gm45) Thierry Laurion
2016-01-24 18:21 ` Thierry Laurion
2016-01-24 23:45 ` [qubes-devel] " Marek Marczykowski-Górecki
2016-01-26 21:10 ` Thierry Laurion
2016-01-27 5:08 ` Thierry Laurion
2016-01-29 17:52 ` Thierry Laurion
2016-01-25 10:01 ` Andrew Cooper [this message]
2016-01-25 14:30 ` Jan Beulich
2016-01-25 21:49 ` Thierry Laurion
2016-01-26 10:52 ` Jan Beulich
[not found] ` <CAAzJznxr4CT8J0fnx1kkWfQ+56J0PH+QBjgjH=6phtzbDd4dyw@mail.gmail.com>
2016-01-26 11:37 ` Jan Beulich
2016-01-26 11:57 ` Thierry Laurion
2016-01-26 12:27 ` Jan Beulich
2016-01-26 22:21 ` Tian, Kevin
2016-01-26 23:39 ` Thierry Laurion
2016-01-30 1:47 ` Marek Marczykowski-Górecki
2016-02-01 7:59 ` Jan Beulich
2016-02-01 12:28 ` Marek Marczykowski-Górecki
2016-02-01 12:35 ` Jan Beulich
2016-02-20 18:20 ` Thierry Laurion
2016-02-21 3:45 ` Thierry Laurion
2016-02-28 19:08 ` Thierry Laurion
2016-06-26 23:47 ` Thierry Laurion
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=56A5F281.1080006@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=qubes-devel@googlegroups.com \
--cc=thierry.laurion@gmail.com \
--cc=xen-devel@lists.xen.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.