| Message ID | 20240411212651.540-1-ian.forbes@broadcom.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Fix memory limits for STDU | expand |
On Thu, Apr 11, 2024 at 5:27 PM Ian Forbes <ian.forbes@broadcom.com> wrote: > > Fixes a bug where modes that are too large for the device are exposed > and set causing a black screen on boot. > > Resending as Patchwork did not like my last submission. > > Ian Forbes (4): > drm/vmwgfx: Filter modes which exceed graphics memory > drm/vmwgfx: 3D disabled should not effect STDU memory limits > drm/vmwgfx: Remove STDU logic from generic mode_valid function > drm/vmwgfx: Standardize use of kibibytes when logging > > drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 19 ++++------- > drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 3 -- > drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 4 +-- > drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 26 ++++++--------- > drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 32 ++++++++++++++++++- > 5 files changed, 48 insertions(+), 36 deletions(-) > In general that looks great! Two questions: - with stdu what happens when the mode selected is close to our limits, the guest is using a hardware cursor and we allocate cursor mobs? - with legacy du, is general mode selection with modes close to vram size working? And one comment: in series like those, be careful with fixes tags if the patches depend on each other, i.e. the third one depends on the first but they have different fixes tags so they're disconnected. It's a good idea to keep distro kernel maintainers in mind with those and try to organize the patches in a way that makes it a bit more clearer that #3 depends on #1. It should be fine in this case though. z
On Thu, Apr 11, 2024 at 10:22 PM Zack Rusin <zack.rusin@broadcom.com> wrote: > > - with stdu what happens when the mode selected is close to our > limits, the guest is using a hardware cursor and we allocate cursor > mobs? With overcommit (cfdc3458db8a1620b1e307e3cb07480a161146ab) it won't be an issue. Before overcommit there may be issues. That's what the original code in patch 3 was trying to solve by increasing the guest memory limit but that variable is also the hard host limit which would invalidate fixes made by patch 1. Regardless it will be broken in one way or another. We'd have to backport overcommit or multiply by that constant factor from patch 3 when calling vmw_gmrid_man_init in vmwgfx_gmird_manager.c in a separate patch. The only distros that may be problematic would be debian 11 and ubuntu 22.04 without the HWE kernel. Graphical installs of Ubuntu 22.04 LTS will have HWE by default so only Ubuntu server users who installed a GUI and configured the graphics memory to be tiny will be affected but chances are it was already broken.