[prev in list] [next in list] [prev in thread] [next in thread] 

List:       qubes-devel
Subject:    [qubes-devel] Re: [Xen-devel] pre Sandy bridge IOMMU support (gm45)
From:       Andrew Cooper <andrew.cooper3 () citrix ! com>
Date:       2016-01-25 10:01:37
Message-ID: 56A5F281.1080006 () citrix ! com
[Download RAW message or body]

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

-- 
You received this message because you are subscribed to the Google Groups \
"qubes-devel" group. To unsubscribe from this group and stop receiving emails from \
it, send an email to qubes-devel+unsubscribe@googlegroups.com. To post to this group, \
send email to qubes-devel@googlegroups.com. To view this discussion on the web visit \
https://groups.google.com/d/msgid/qubes-devel/56A5F281.1080006%40citrix.com. For more \
options, visit https://groups.google.com/d/optout.


[Attachment #3 (text/html)]

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 24/01/16 18:21, Thierry Laurion
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAAzJznzd67WAk=GQQDCZWETxQO1BGS+-AWHuKpWkNVJCbCqpbw@mail.gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=windows-1252">
      <div dir="ltr">
        <div>
          <div>
            <div>
              <div>Hi devs!<br>
                <br>
              </div>
              XEN devs:<br>
              As per short discussion with ktemkin earlier in January in
              #xen:<br>
              <br>
              "ktemkin Jan 10, 2016 16:21:50<br>
              This test patch did appear to make the system work,
              though: <a moz-do-not-send="true" rel="nofollow"
                target="_blank"
                href="https://gist.github.com/ktemkin/0e81b93654ae800a5609">https://gist.github.com/ktemkin/0e81b93654ae800a5609</a><br>
  <br>
              ktemkin Jan 10, 2016 16:24:55<br>
              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."<br>
              <br>
              <br>
              <br>
            </div>
            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.<br>
            <br>
          </div>
          What do you think?<br>
        </div>
      </div>
    </blockquote>
    <br>
    There is some confusion here.<br>
    <br>
    "Unfortunately, quirks specific to the Clarkdale/Nehalem integrated
    graphics device (IGD) do not function correctly with Xen's VT-d
    implementation"<br>
    <br>
    Either<br>
    1) There is a chipset errata which prevents it from functioning
    correctly, or<br>
    2) Xen's VT-d code doesn't program the chip correctly.<br>
    <br>
    Which is it?<br>
    <br>
    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.<br>
    <br>
    ~Andrew<br>
  </body>
</html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups \
&quot;qubes-devel&quot; group.<br /> To unsubscribe from this group and stop \
receiving emails from it, send an email to <a \
href="mailto:qubes-devel+unsubscribe@googlegroups.com">qubes-devel+unsubscribe@googlegroups.com</a>.<br \
/> To post to this group, send email to <a \
href="mailto:qubes-devel@googlegroups.com">qubes-devel@googlegroups.com</a>.<br /> To \
view this discussion on the web visit <a \
href="https://groups.google.com/d/msgid/qubes-devel/56A5F281.1080006%40citrix.com?utm_ \
medium=email&utm_source=footer">https://groups.google.com/d/msgid/qubes-devel/56A5F281.1080006%40citrix.com</a>.<br \
/> For more options, visit <a \
href="https://groups.google.com/d/optout">https://groups.google.com/d/optout</a>.<br \
/>



[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic