Bug 1260751 - [RFE] Spice: support for 4k resolutions and beyond
[RFE] Spice: support for 4k resolutions and beyond
Status: CLOSED DEFERRED
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: rhevm-spice-client (Show other bugs)
4.0.0
Unspecified Unspecified
high Severity medium
: ovirt-4.3.0
: ---
Assigned To: Default Assignee for SPICE Bugs
SPICE QE bug list
: FutureFeature
: 1208335 spice_4k_res (view as bug list)
Depends On: 1194354 1260749
Blocks: 1208335
  Show dependency treegraph
 
Reported: 2015-09-07 11:28 EDT by David Jaša
Modified: 2018-03-01 09:14 EST (History)
19 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2018-03-01 09:14:59 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Spice
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Jaša 2015-09-07 11:28:32 EDT
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 07:23:37 EDT
*** Bug 1208335 has been marked as a duplicate of this bug. ***
Comment 4 Yaniv Kaul 2015-11-26 11:21:07 EST
*** Bug 1273106 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.