Bug 1260751

Summary: [RFE] Spice: support for 4k resolutions and beyond
Product: Red Hat Enterprise Virtualization Manager Reporter: David Jaša <djasa>
Component: rhevm-spice-clientAssignee: Default Assignee for SPICE Bugs <rh-spice-bugs>
Status: CLOSED DEFERRED QA Contact: SPICE QE bug list <spice-qe-bugs>
Severity: medium Docs Contact:
Priority: high    
Version: 4.0.0CC: astepano, cfergeau, dblechte, fdelorey, fedoraproject, fjin, juzhou, lsurette, michal.skrivanek, michen, mtessun, mxie, mzamazal, rbalakri, srevivo, tzheng, xiaodwan, yafu
Target Milestone: ---Keywords: FutureFeature
Target Release: ---Flags: lsvaty: testing_plan_complete-
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-03-01 14:14:59 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Spice RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1194354, 1260749    
Bug Blocks: 1208335    

Description David Jaša 2015-09-07 15:28:32 UTC
Spice currently officially supports resolutions up to 2560x1600 or 2048x2048 per monitor. Larger monitors are however starting to hit the market but spice can scale somehow only to 4k (3840x2160) but it starts hitting hard design limits when trying to use 8k (7680x4320). This bug shoud track effort across the components to support 4k resolutions and larger properly. The areas affected are:


1. QXL driver

currently, various QXL drivers operates in different modes:
  * Windows: multiple devices with all data in QXL device BAR #0
  * Linux UMS: single device with all data in BAR #0
  * Linux KMS: single device with framebuffers in BAR #1 and other data in BAR #0
The problem is that the display data grows with square of linear size so we're quickly exceeding limits of memory that can be addressed in 32b-only BAR #0 (BAR #1 allows 64b addressing which is for our purposes effectively unlimited). In addition, Windows drivers using multiple devices result in the same image taking space and needing to be transferred by two or more channels in parallel so the target status should be:
  * Linux KMS driver: modify it so that only small data is stored in BAR #0
  * Linux UMS driver: UMS is being deprecated so let's exclude UMS from this RFE
  * Windows driver: should be refactored to the updated Linux KMS model


2. expose 64b BAR #1 size in libvirt

libvirt only supports setting of BAR #1 (ram), it's framebuffer region (vgamem <= ram/2) and 32b BAR #1 (vram). 64b BAR #1 parameter is missing -  bug 1260749


3. memory settings for VMs

As the video memory grows with square of screen dimensions and many VMs won't need 4k or larger screens, it's desirable to be able to set the maximum supported resolution per VM in similar way to maximum number of monitors. My take would be addition of another drop-down to Console tab of Add/Edit VM dialog.


4. transition from old settings to new settings for Windows VMs

We'll need some way how to update the configuration for guests which will start supporting the new config without breaking the ones that still use the old driver. Let's leave this question to be sorted out later.

Comment 2 David Blechter 2015-09-30 11:23:37 UTC
*** Bug 1208335 has been marked as a duplicate of this bug. ***

Comment 4 Yaniv Kaul 2015-11-26 16:21:07 UTC
*** Bug 1273106 has been marked as a duplicate of this bug. ***

Comment 7 Franta Kust 2019-05-16 12:55:09 UTC
BZ<2>Jira re-sync