[vbox-dev] Synchronizing access to the framebuffer in VirtualBox 5

[Vitali Pelenjow]

Hi Rudolfs,

IFramebuffer::Lock() in 4.3 did not prevent the guest access to the 
guest VRAM (framebuffer).

Vitali.

Rūdolfs Bundulis wrote:
> Hi Vitali,
>
>     the guest may access the guest VRAM between NotifyUpdate calls.
>     Which means that in principle the guest can change the content
>     while the frontend thread is reading pixels.
>
> Yeah, it seems that this is what is happening. It can be easily 
> observed when looking at the mouse cursor in our video stream - you 
> can see some pixels of the previous ones. If there just was something 
> equivalent to the old
> IFramebuffer::Lock() then we could just prevent the guest from 
> accessing the pixels (I mean it would still be for a very short time - 
> only as long as it takes for the pixel conversion). I mean my plan Z 
> now is that I can recompile VirtualBox and put back additional methods 
> for locking - but I was wondering don't you guys ever experience the 
> same issues (however since you simply blit the pixels to the display I 
> guess not :D).
>
>     Actually I wonder why this worked for your in VBox 4.3 because if
>     the 4.3 framebuffer implementation
>     used the guest VRAM directly, then it was the same case as in 5.0.
>
> In VBox 4.3 we performed the RGB to NV12 conversion inside the notify 
> update callback and we also locked an internal critical section which 
> also was locked if IFramebuffer::Lock was called - so during the time 
> while our frontend was reading the pixels noone else could access 
> them. This was safe, but slow as hell. I mean the responsiveness of 
> the guest OS has become much much much better now with the normalized 
> fps encoding instead of reacting to every update.
>
>     Do you remember whether the 4.3 framebuffer implementation
>     allocated the memory and did not use VRAM directly?
>
> We always used VRAM. If the amount of memory wasn't so high we could 
> use our own pointer and copy, but in case of a full screen video or 
> OpenGL redirection where we won't be able to simply copy smaller 
> regions this will be a performance pitfall.
>
> Best Regards,
> Rudolfs Bundulis