OpenXT uses Xenfb2 which is handling guest PV display using tricks at various levels. The gaps to use the upstream Xenfb instead of Xenfb2 are not that wide considering that some of the features of Xenfb2 are no longer exercises by the Xenfb2 backend in Surfman.
Adds Backend to Frontend message: XENFB2_TYPE_MODE_REPLY to return a mode that the backend can actually handle. This is bound to surfman passing the framebuffer to be scanned by the GPU.
Xenfb2 (frontend) changes the cache-policy of the framebuffer. Since the GPU will scan the framebuffer, whatever is in it has to be consistent with whatever has been written to it. The default Write-back policy does not provide that (Xenfb2 uses Write-combine, Write-through would be acceptable also).
Xenfb2 handles framebuffer refresh using a dirty-bitmap tracking page-tables accessed in the guest. This is done registering a vm_fault handler. This is then accessible in the backend (see frontend-to/for-backend exchanges) to figure out what should be copied from the framebuffer of the guest to framebuffer scanned by the GPU. This is only used in copy-mode.
To do so, Xenfb2 relies on patches in Xen to let it manipulate the caching policy applied to the framebuffer.
Handles the framebuffer using Linux fb_read/fb_write operations, which lets it create dirty-rectangle events.
Send dirty-rectangles to the backend for refresh operations.
Exposes a larger set of framebuffer pages to the backend (greater resolutions).
Adding Xenfb support in Surfman will allow both UIVM to loose some custom code, but also the Xen patch-queue to be reduced. It would also let PV-capable guests use Xenfb upstream PV driver.
UIVM display supported.
PV guests display supported through Xenfb (direct-mapping not required).
Surfman (or graphic stack backend) regressions.