From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: pre Sandy bridge IOMMU support (gm45) Date: Mon, 25 Jan 2016 10:01:37 +0000 Message-ID: <56A5F281.1080006@citrix.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7016414474635282005==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Thierry Laurion , xen-devel@lists.xen.org, qubes-devel List-Id: xen-devel@lists.xenproject.org --===============7016414474635282005== Content-Type: multipart/alternative; boundary="------------040202020602050902080201" --------------040202020602050902080201 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit 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 --------------040202020602050902080201 Content-Type: text/html; charset="windows-1252" Content-Length: 2584 Content-Transfer-Encoding: quoted-printable
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=3F

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=3F

If it is 1), then there is a very good case for quirking the affected chipsets and unilaterally disabling them.=A0 If it is 2), then the VT-d code should be corrected.

~Andrew
--------------040202020602050902080201-- --===============7016414474635282005== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============7016414474635282005==--