Local Display Direct Flip Feature Discussion

[Tina Zhang]

On Thu, Dec 13, 2018 at 01:33:50PM +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> > The proposed userspace interface:
> 
> > Each plane of the vGPU is exposed as a DRM framebuffer object in the
> > host-side during the vGPU creation. So host userspace can assign the
> > HW display planes to vGPU's planes by using existing DRM/KMS APIs.
> 
> --verbose please.
Sorry for this late reply.

Mostly, we want to use a DRM framebuffer object in host-side to record
the info of a guest framebffuer attached on a vGPU's plane. 

So, when a guest does fb flip through programing vGPU's plane registers,
GVT-g trap everything. Then during that trapped fb flip operation, GVT-g
does the following things:
1) GVT-g decodes guest fb info through plane related registers and save
   the info to the DRM framebuffer instance.
2) With the help of i915, GVT-g invokes the drm interface to set the DRM
   framebuffer to the assigned HW plane.
All these things are happened in the kernel space.

Host userspace is in charge of the plane assignment. That means, the
2) step won't be taken if GVT-g finds this vGPU's has no assigned HW
plane.

How does userspace do the plane assignment?
Since a DRM framebuffer is used to stand for a vGPU's plane in host-side,
this can be achieved through existing KMS APIs (e.g. drmModeSetPlane).
And in i915, this DRM framebuffer will be recognized and treat specially
(mostly just update the plane assignment table in memory).

> 
> Isn't a framebuffer just a gem object with metadata (fourcc, width,
> height, stride, ...) attached?  So I'm wondering how that works in
> detail.  What happens on page-flip?  Do you make the framebuffer
> reference another gem object then?  Or do you blit the guest display
> to the framebuffer?
The special DRM framebuffer is transparent to the guest display driver.
We just want to use this object to save the guest framebuffer info in
host-side.

The truth is the HW plane resources can be partitioned among VMs. Plane
registers can be directly programmed with the values of guest framebuffer
including framebuffer base address, format and so on, if these planes are
considered to be assigned to a guest. However, guest cannot touch these
registers as they are in the virtualized environment. Host i915 driver
needs to give the help to program those plane registers. That's why we
need expose guest framebuffer info to host. And we use drm framebuffer to
save them. Because we want to follow the DRM framework to commit these
values to the HW plane registers.

> 
> What happens when the guest switches the display resolution?
GVT-g can trap this mode-setting operation and ask i915's help to do
it through the host DRM framework.


BR,
Tina
> 
> thanks,
>   Gerd
> 
> _______________________________________________
> intel-gvt-dev mailing list
> intel-gvt-dev at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev