Bug 109930 - I915_PARAM_HAS_ALIASING_PPGTT return value is changed with patch "drm/i915: Remove i915.enable_ppgtt override"
Summary: I915_PARAM_HAS_ALIASING_PPGTT return value is changed with patch "drm/i915: R...
Status: RESOLVED NOTABUG
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: x86-64 (AMD64) Linux (All)
: medium blocker
Assignee: Joonas Lahtinen
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard: Triaged, ReadyForDev
Keywords:
Depends on:
Blocks:
 
Reported: 2019-03-08 01:35 UTC by Tony Ye
Modified: 2019-04-11 10:06 UTC (History)
2 users (show)

See Also:
i915 platform: BDW, BSW/CHT, BXT, CFL, CNL, GLK, ICL, KBL, SKL
i915 features: GEM/Other, GEM/PPGTT


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tony Ye 2019-03-08 01:35:20 UTC
In libdrm, I915_PARAM_HAS_ALIASING_PPGTT is used to check if 48b_address_range can be used.
Before patch  "drm/i915: Remove i915.enable_ppgtt override" is merged, I915_PARAM_HAS_ALIASING_PPGTT returns 3 on IceLake.
After the patch is merged, I915_PARAM_HAS_ALIASING_PPGTT returns 2.
Comment 1 Tvrtko Ursulin 2019-03-08 06:30:33 UTC
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
Comment 2 Chris Wilson 2019-03-08 08:25:27 UTC
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.
Comment 3 Chris Wilson 2019-03-08 12:07:51 UTC
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 :|
Comment 4 Tony Ye 2019-03-11 03:53:18 UTC
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?
Comment 5 Chris Wilson 2019-03-11 09:10:08 UTC
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.
Comment 6 Tony Ye 2019-03-18 03:39:45 UTC
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.
Comment 7 Francesco Balestrieri 2019-03-19 07:52:40 UTC
Joonas, is that enough to close this bug?
Comment 8 Chris Wilson 2019-04-11 10:06:11 UTC
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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.