<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    After reading up on some internal discussion with Marek and some
    other people I stumbled over another very important think to keep in
    mind:<br>
    <br>
    We have tons of hardware specific stuff in the VM subsystem!<br>
    <br>
    This ranges from specific permission flags (valid, executable, read,
    write are probably common enough, but "fetchable" ?), over things
    like cache control towards things like internal data routing flags.<br>
    <br>
    If this should be device independent we absolute need at least a
    64bit hardware flags value in the interface and then obviously ways
    how device independent code can figure out the flags to use for a
    specific use case.<br>
    <br>
    Even better would be an additional pointer to a hardware driver
    private data structure for the mapping.<br>
    <br>
    Regards,<br>
    Christian.<br>
    <br>
    <div class="moz-cite-prefix">Am 26.08.22 um 05:11 schrieb Brost,
      Matthew:<br>
    </div>
    <blockquote type="cite" cite="mid:PH7PR11MB652297FD3248646542EEF4C6EF759@PH7PR11MB6522.namprd11.prod.outlook.com">
      
      <meta name="Generator" content="Microsoft Word 15 (filtered
        medium)">
      <style>@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}div.WordSection1
        {page:WordSection1;}</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal">Sorry for the outlook reply, so in XE that
          works the opposite of AMDGPU. Mappings keep a reference to the
          BO and the mapping exist until they are explicitly destroyed
          or the VM is destroyed, so if a mapping exists the BO exists.
          Quickly implemented a prototype extension to the VM bind IOCTL
          that blows away all mappings on a BO per Jason’s suggestion,
          for XE it was really straight forward.
          <o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">I’d have to double check the i915 reference
          counting wrt to BO and mappings but I suspect it works like
          XE.<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">IMO this paradigm is the way to go as it
          does match open / mmap / close semantics.<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">Matt<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <div>
          <div style="border:none;border-top:solid #E1E1E1
            1.0pt;padding:3.0pt 0in 0in 0in">
            <p class="MsoNormal"><b>From:</b> Christian König
              <a class="moz-txt-link-rfc2396E" href="mailto:christian.koenig@amd.com"><christian.koenig@amd.com></a> <br>
              <b>Sent:</b> Thursday, August 25, 2022 6:37 AM<br>
              <b>To:</b> Jason Ekstrand <a class="moz-txt-link-rfc2396E" href="mailto:jason@jlekstrand.net"><jason@jlekstrand.net></a><br>
              <b>Cc:</b> Bas Nieuwenhuizen
              <a class="moz-txt-link-rfc2396E" href="mailto:bas@basnieuwenhuizen.nl"><bas@basnieuwenhuizen.nl></a>; Dave Airlie
              <a class="moz-txt-link-rfc2396E" href="mailto:airlied@gmail.com"><airlied@gmail.com></a>; dri-devel
              <a class="moz-txt-link-rfc2396E" href="mailto:dri-devel@lists.freedesktop.org"><dri-devel@lists.freedesktop.org></a>; Daniel Vetter
              <a class="moz-txt-link-rfc2396E" href="mailto:daniel.vetter@ffwll.ch"><daniel.vetter@ffwll.ch></a>; Brost, Matthew
              <a class="moz-txt-link-rfc2396E" href="mailto:matthew.brost@intel.com"><matthew.brost@intel.com></a>; Ben Skeggs
              <a class="moz-txt-link-rfc2396E" href="mailto:skeggsb@gmail.com"><skeggsb@gmail.com></a><br>
              <b>Subject:</b> Re: vm binding interfaces and parallel
              with mmap<o:p></o:p></p>
          </div>
        </div>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">Am 24.08.22 um 18:14 schrieb Jason
          Ekstrand:<br>
          <br>
          <o:p></o:p></p>
        <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
          <div>
            <div>
              <div>
                <p class="MsoNormal">On Mon, Aug 22, 2022 at 8:27 AM
                  Christian König <<a href="mailto:christian.koenig@amd.com" moz-do-not-send="true" class="moz-txt-link-freetext">christian.koenig@amd.com</a>>
                  wrote:<o:p></o:p></p>
              </div>
              <p class="MsoNormal">[SNIP]<o:p></o:p></p>
              <blockquote style="border:none;border-left:solid #CCCCCC
                1.0pt;padding:0in 0in 0in
                6.0pt;margin-left:4.8pt;margin-right:0in">
                <p class="MsoNormal">>> I suppose it also asks the
                  question around paralleling<br>
                  >><br>
                  >> fd = open()<br>
                  >> ptr = mmap(fd,)<br>
                  >> close(fd)<br>
                  >> the mapping is still valid.<br>
                  >><br>
                  >> I suppose our equiv is<br>
                  >> handle = bo_alloc()<br>
                  >> gpu_addr = vm_bind(handle,)<br>
                  >> gem_close(handle)<br>
                  >> is the gpu_addr still valid does the VM hold
                  a reference on the kernel<br>
                  >> bo internally.<br>
                  > For Vulkan it looks like this is undefined and
                  the above is not necessary:<br>
                  ><br>
                  > "It is important to note that freeing a
                  VkDeviceMemory object with<br>
                  > vkFreeMemory will not cause resources (or
                  resource regions) bound to<br>
                  > the memory object to become unbound. Applications
                  must not access<br>
                  > resources bound to memory that has been freed."<br>
                  > (32.7.6)<o:p></o:p></p>
              </blockquote>
              <div>
                <p class="MsoNormal"><o:p> </o:p></p>
              </div>
              <div>
                <p class="MsoNormal">I'm not sure about this particular
                  question.  We need to be sure that maps get cleaned up
                  eventually.  On the one hand, I think it's probably a
                  valid API implementation to have each mapped page hold
                  a reference similar to mmap and have vkDestroyImage or
                  vkDestroyBuffer do an unmap to clean up the range. 
                  However, clients may be surprised when they destroy a
                  large memory object and can't reap the memory because
                  of extra BO references they don't know about.  If BOs
                  unmap themselves on close or if we had a way to take a
                  VM+BO and say "unmap this BO from everywhere, please",
                  we can clean up the memory pretty easily.  Without
                  that, it's a giant PITA to do entirely inside the
                  userspace driver because it requires us to globally
                  track every mapping and that means data structures and
                  locks.  Yes, such an ioctl would require the kernel to
                  track things but the kernel is already tracking
                  everything that's bound, so hopefully it doesn't add
                  much.<o:p></o:p></p>
              </div>
            </div>
          </div>
        </blockquote>
        <p class="MsoNormal"><br>
          For both amdgpu as well as the older radeon mapping a BO does
          *not* grab a reference to it. Whenever a BO is released all
          it's mappings just disappear.<br>
          <br>
          We need to keep track of the mappings anyway to recreate page
          tables after (for example) suspend and resume, so that isn't
          any overhead.<br>
          <br>
          Regards,<br>
          Christian.<br>
          <br>
          <br>
          <o:p></o:p></p>
        <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
          <div>
            <div>
              <div>
                <p class="MsoNormal"><o:p> </o:p></p>
              </div>
              <div>
                <p class="MsoNormal">--Jason<o:p></o:p></p>
              </div>
              <div>
                <p class="MsoNormal"> <o:p></o:p></p>
              </div>
              <blockquote style="border:none;border-left:solid #CCCCCC
                1.0pt;padding:0in 0in 0in
                6.0pt;margin-left:4.8pt;margin-right:0in">
                <p class="MsoNormal" style="margin-bottom:12.0pt">Additional
                  to what was discussed here so far we need an array on
                  in and
                  <br>
                  out drm_syncobj for both map as well as unmap.<br>
                  <br>
                  E.g. when the mapping/unmapping should happen and when
                  it is completed <br>
                  etc...<br>
                  <br>
                  Christian.<br>
                  <br>
                  ><br>
                  ><br>
                  >> Dave.<br>
                  >>> Dave.<o:p></o:p></p>
              </blockquote>
            </div>
          </div>
        </blockquote>
        <p class="MsoNormal"><o:p> </o:p></p>
      </div>
    </blockquote>
    <br>
  </body>
</html>