<html>
    <head>
      <base href="https://bugs.freedesktop.org/">
    </head>
    <body><table border="1" cellspacing="0" cellpadding="8">
        <tr>
          <th>Bug ID</th>
          <td><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - KVM VFIO guest X hang with guest kernel > 4.15"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=109456">109456</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>KVM VFIO guest X hang with guest kernel > 4.15
          </td>
        </tr>

        <tr>
          <th>Product</th>
          <td>DRI
          </td>
        </tr>

        <tr>
          <th>Version</th>
          <td>XOrg git
          </td>
        </tr>

        <tr>
          <th>Hardware</th>
          <td>x86-64 (AMD64)
          </td>
        </tr>

        <tr>
          <th>OS</th>
          <td>Linux (All)
          </td>
        </tr>

        <tr>
          <th>Status</th>
          <td>NEW
          </td>
        </tr>

        <tr>
          <th>Severity</th>
          <td>normal
          </td>
        </tr>

        <tr>
          <th>Priority</th>
          <td>medium
          </td>
        </tr>

        <tr>
          <th>Component</th>
          <td>DRM/AMDgpu
          </td>
        </tr>

        <tr>
          <th>Assignee</th>
          <td>dri-devel@lists.freedesktop.org
          </td>
        </tr>

        <tr>
          <th>Reporter</th>
          <td>libgradev@gmail.com
          </td>
        </tr></table>
      <p>
        <div>
        <pre>Hi

Host: Arch running kernel 4.20.3 / Qemu 3.1
Guest: Ubuntu 18.04.1 (tried Ubuntu 18.10 also) with any kernel after 4.15
Driver: Happens with current stable, git from Padoka PPA and amdgpu-pro 18.50

Issue: Vega 64 passed through to guest causes X to hang on boot using 100% CPU
for one of the passed through cores for the Xorg process. X never starts with
the stopping point being 'LoadModule: "dri2"'. I cannot see any relevant errors
in Xorg.log or the KRB - though it's easily reproducible. The system is still
alive and can be ssh'd into.

Adding the nomodeset kernel option allows the guest to boot to GUI (albeit
without acceleration).

Details: With Qemu 3.0 having more than ~12GB RAM assigned to the guest causes
this behaviour. With Qemu 3.1 the amount of RAM is irrelevant - the hang always
occurs.

Believe this is related to one of the GPU reset patches added to the 4.16
kernel as the guest boots fine with Qemu 3.0/3.1 and guest kernel 4.15 (tested
up to 16GB guest RAM).</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>