Patch SHA:

commit 4bdafb9ddfa4b3d970e2194d00e1c6d5002f513f
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Wed Sep 26 21:12:22 2018 +0100

    drm/i915: Remove i915.enable_ppgtt override
    
    Now that we are confident in providing full-ppgtt where supported,
    remove the ability to override the context isolation.
    
    v2: Remove faked aliasing-ppgtt for testing as it no longer is accepted.
    v3: s/USES/HAS/ to match usage and reject attempts to load the module on
    old GVT-g setups that do not provide support for full-ppgtt.
    v4: Insulate ABI ppGTT values from our internal enum (later plans
    involve moving ppGTT depth out of the enum, thus potentially breaking
    ABI unless we document the current values).
    
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
    Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
    Cc: Matthew Auld <matthew.auld@intel.com>
    Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
    Acked-by: Zhi Wang <zhi.a.wang@intel.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20180926201222.5643-1-chris@chris-wilson.co.uk

I915_PARAM_HAS_ALIASING_PPGTT cannot be simply used for that going forward with the increasing number of different GTT configurations. It should never have been used in the first place for that purpose as GTT_SIZE landed in the same kernel as 48b support precisely for this reason.

I consider this to a bug in libdrm; the major users stop using libdrm before their transition to 48b and we should just delete libdrm.

The bug in question is:

        if (bufmgr_gem->gen >= 8) {
                gp.param = I915_PARAM_HAS_ALIASING_PPGTT;
                ret = drmIoctl(bufmgr_gem->fd, DRM_IOCTL_I915_GETPARAM, &gp);
                if (ret == 0 && *gp.value == 3)
                        bufmgr_gem->bufmgr.bo_use_48b_address_range = drm_intel_gem_bo_use_48b_address_range;

which can not work going forward :|

So the correct method is to check if (gen >= 8 && GTT_SIZE > 4G) to decide if EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag can be used?

It can be used on any kernel after 48B support landed, i.e. any kernel that supports I915_CONTEXT_PARAM_GTT_SIZE. If you specify it on a GTT that doesn't have more than 4G, nothing happens.

Thank you for the clarification, Chris and Tvrtko. The media driver derived this piece of code from libdrm. We will fix it in media driver.

Joonas, is that enough to close this bug?

If everyone is happy to look the other way and pretend we never exposed anything but (none, aliasing, full), then it seems like we can get away with the loop hole being closed.