Screen resizing with VMSVGA produces artifacts if VM is started from a saved state => Fixed in SVN

[mskov]

Hello,

if a VM is started from a saved state (e.g., by restoring a live snapshot and resuming), then we observe frame buffer artifacts (colored lines) when screen auto-resizing kicks in (screenshot attached). Usually the artifacts are visible for less than a second and the resizing itself is working fine afterwards. This problem only happens if the VM is resumed from a saved state, on a fresh startup all works fine. And we don't have this problem with VBoxVGA/VBoxSVGA adapter i.e, when vboxvideo is used as a driver. So it looks to be a problem of the vmware driver

This problems is more noticeable if VirtualBox runs on top of Hyper-V, because the VM is slower in such mode and the artifacts during resize become more noticeable. And when running on top of Hyper-V, VMSVGA works much better than VBoxVGA in general (apart from resizing) so going back to VBoxVGA is not realy an option.

We tested this with a fresh Debian 9.13.0 installation with Openbox. Let me know if you need the logs (and which logs you need then).

[mskov]

Screen artifacts during resizing

[mgrzegor]

I am observing the same behaviour in 6.1.22 also in a slightly different scenario: if, after restoring a full-screen Linux VM from a saved state, I temporarily switch to a scaled or windowed mode (to work around #16547), the screen becomes garbled like in the original reporter’s screenshot. In this scenario the screen does not fix itself — I have to do a Ctrl+Alt+F1 followed by Ctrl+Alt+F7 to fix the problem (afterwards, everything works fine — until the next save&restore). BTW, “Auto-resize Guest Display” is turned off for that VM.

Additionally, during the machine save or restore process, usually the screen is shifted halfway down and the upper half is filled with the same kind of garbage. This does fix itself once the restore completes.

I cannot tell when the bug started because I went straight from 6.0.24 to 6.1.22 and earlier I avoided using VMSVGA because of other issues.

Due to the annoyance of this bug I went back to using VBoxSVGA — it works well enough for me.

[Dmitrii Grigorev]

Hello Mgrzegor.

Could you replay the problem and attach VBox.log here?

Replying to mgrzegor:

I am observing the same behaviour in 6.1.22 also in a slightly different scenario: if, after restoring a full-screen Linux VM from a saved state, I temporarily switch to a scaled or windowed mode (to work around #16547), the screen becomes garbled like in the original reporter’s screenshot. In this scenario the screen does not fix itself — I have to do a Ctrl+Alt+F1 followed by Ctrl+Alt+F7 to fix the problem (afterwards, everything works fine — until the next save&restore). BTW, “Auto-resize Guest Display” is turned off for that VM.

Additionally, during the machine save or restore process, usually the screen is shifted halfway down and the upper half is filled with the same kind of garbage. This does fix itself once the restore completes.

I cannot tell when the bug started because I went straight from 6.0.24 to 6.1.22 and earlier I avoided using VMSVGA because of other issues.

Due to the annoyance of this bug I went back to using VBoxSVGA — it works well enough for me.

[Klaus Espenlaub]

Please try with the latest Testbuilds. Should be fixed. Was an issue with incomplete initialization of the device when running from saved state. The saved state was correctly used and contains the right information. Just some some other parts were not done in this case.

[Mikhail Kovalev]

I've tried the latest testbuilds (one from yesterday and one from today). But I am still getting the same problems with both builds. I get the screen corruption in 100% of times when I revert to a live snapshot, start the VM and do a first resize (see 1.png). On subsequent resize attempts I can also see the screen corruption occurring for a fraction of a second. Depending on the hardware performance, this corruption might be almost unnoticeable or it may also stay until a next resize is performed. When I try to close the VM - the screen corruption is always there (see 3.png). I've also noticed that after I start a VM from a live snapshot and before I do the first resize, the screen stays black (see 2.png).

Let me know if I can somehow help with debugging the issue.

[Mikhail Kovalev]

I can confirm that the main issue is fixed with VirtualBox 6.1.26. The screen corruption does not occur any longer. However, one part of the problem is still there: when a VM is started from the live snapshot, I almost always get a black screen. The first resizing attempt also results in a black screen in most cases. Subsequent resizing attempts work fine. So it looks like it takes time for some framebuffer-related components to get initialized after the VM is restored from a live snapshot. Shall I create a separate ticket for this problem?

[galitsyn]

Hi MikhailK,

The following builds have a fix for back screen issue. Could you please give it a try?

• Linux hosts: https://www.virtualbox.org/download/testcase/VirtualBox-6.1.27-146314-Linux_amd64.run
• Windows hosts: https://www.virtualbox.org/download/testcase/VirtualBox-6.1.27-146314-Win.exe (not signed build).

[Mikhail Kovalev]

Hello,

I can confirm that the problem is fixed on 6.1.27-146314. Thank you! Could you also point us to an SVN commit (or a patch) which is fixing the issue?

[galitsyn]

Hi MikhailK,

Fixes will be available for VirtualBox releases starting from r146308. They are not yet ported to https://www.virtualbox.org/svn/vbox/trunk repository. So, I am attaching them in a patch form for now.

Index: src/VBox/Devices/Graphics/DevVGA-SVGA.cpp
===================================================================
--- a/src/VBox/Devices/Graphics/DevVGA-SVGA.cpp
+++ b/src/VBox/Devices/Graphics/DevVGA-SVGA.cpp
@@ -941,43 +941,43 @@
  *
  * Used to update screen offsets (positions) since appearently vmwgfx fails to
  * pass correct offsets thru FIFO.
  */
 DECLCALLBACK(void) vmsvgaR3PortReportMonitorPositions(PPDMIDISPLAYPORT pInterface, uint32_t cPositions, PCRTPOINT paPositions)
 {
     PVGASTATECC         pThisCC    = RT_FROM_MEMBER(pInterface, VGASTATECC, IPort);
     PVGASTATE           pThis      = PDMDEVINS_2_DATA(pThisCC->pDevIns, PVGASTATE);
     PVMSVGAR3STATE      pSVGAState = pThisCC->svga.pSvgaR3State;
 
     AssertReturnVoid(pSVGAState);
 
     /* We assume cPositions is the # of outputs Xserver reports and paPositions is (-1, -1) for disabled monitors. */
     cPositions = RT_MIN(cPositions, RT_ELEMENTS(pSVGAState->aScreens));
     for (uint32_t i = 0; i < cPositions; ++i)
     {
         if (   pSVGAState->aScreens[i].xOrigin == paPositions[i].x
             && pSVGAState->aScreens[i].yOrigin == paPositions[i].y)
             continue;
 
-        if (pSVGAState->aScreens[i].xOrigin == -1)
+        if (paPositions[i].x == -1)
             continue;
-        if (pSVGAState->aScreens[i].yOrigin == -1)
+        if (paPositions[i].y == -1)
             continue;
 
         pSVGAState->aScreens[i].xOrigin = paPositions[i].x;
         pSVGAState->aScreens[i].yOrigin = paPositions[i].y;
         pSVGAState->aScreens[i].fModified = true;
     }
 
     vmsvgaR3VBVAResize(pThis, pThisCC);
 }

Index: src/VBox/Devices/Graphics/DevVGA-SVGA.cpp
===================================================================
--- a/src/VBox/Devices/Graphics/DevVGA-SVGA.cpp
+++ b/src/VBox/Devices/Graphics/DevVGA-SVGA.cpp
@@ -5569,76 +5569,76 @@
 
     VMSVGA_STATE_LOAD LoadState;
     LoadState.pSSM     = pSSM;
     LoadState.uVersion = uVersion;
     LoadState.uPass    = uPass;
     rc = vmsvgaR3RunExtCmdOnFifoThread(pDevIns, pThis, pThisCC, VMSVGA_FIFO_EXTCMD_LOADSTATE, &LoadState, RT_INDEFINITE_WAIT);
     AssertLogRelRCReturn(rc, rc);
 
     return VINF_SUCCESS;
 }
 
 /**
  * Reinit the video mode after the state has been loaded.
  */
 int vmsvgaR3LoadDone(PPDMDEVINS pDevIns)
 {
     PVGASTATE       pThis      = PDMDEVINS_2_DATA(pDevIns, PVGASTATE);
     PVGASTATECC     pThisCC    = PDMDEVINS_2_DATA_CC(pDevIns, PVGASTATECC);
     PVMSVGAR3STATE  pSVGAState = pThisCC->svga.pSvgaR3State;
 
+    /* VMSVGA is working via VBVA interface, therefore it needs to be
+     * enabled on saved state restore. See @bugref{10071#c7}. */
+    if (pThis->svga.fEnabled)
+    {
+        for (uint32_t idScreen = 0; idScreen < pThis->cMonitors; ++idScreen)
+            pThisCC->pDrv->pfnVBVAEnable(pThisCC->pDrv, idScreen, NULL /*pHostFlags*/);
+    }
+
     /* Set the active cursor. */
     if (pSVGAState->Cursor.fActive)
     {
         /* We don't store the alpha flag, but we can take a guess that if
          * the old register interface was used, the cursor was B&W.
          */
         bool    fAlpha = pThis->svga.uCursorOn ? false : true;
 
         int rc = pThisCC->pDrv->pfnVBVAMousePointerShape(pThisCC->pDrv,
                                                          true /*fVisible*/,
                                                          fAlpha,
                                                          pSVGAState->Cursor.xHotspot,
                                                          pSVGAState->Cursor.yHotspot,
                                                          pSVGAState->Cursor.width,
                                                          pSVGAState->Cursor.height,
                                                          pSVGAState->Cursor.pData);
         AssertRC(rc);
 
         if (pThis->svga.uCursorOn)
             pThisCC->pDrv->pfnVBVAReportCursorPosition(pThisCC->pDrv, VBVA_CURSOR_VALID_DATA, SVGA_ID_INVALID, pThis->svga.uCursorX, pThis->svga.uCursorY);
     }

[Mikhail Kovalev]

Thnx a lot!

Replying to galitsyn:

Hi MikhailK,

Fixes will be available for VirtualBox releases starting from r146308. They are not yet ported to https://www.virtualbox.org/svn/vbox/trunk repository. So, I am attaching them in a patch form for now.

[galitsyn]

Both fixes now available in https://www.virtualbox.org/svn/vbox/trunk repository. Closing ticket.