Re: [RFC] Dynamic modes support for PV xenfb (included)

[Gerd Hoffmann <kraxel@redhat.com>]

Pat Campbell wrote:
>> I took a quite look through the code and was impressed by how small a patch 
>> was actually required.

The linux framebuffer has resize support, so this is easy ;)

Resizing the framebuffer text console using the "fbset" utility should
work too btw.

>> A few general comments:
>> 1) I think it would be preferable to be able to dynamically size the memory 
>> allocated to the framebuffer according to the resolution, rather than 
>> statically allocating it and then potentially not using all of it.  
>> Presumably this would require more extensive changes to the backend, since 
>> it 
>> would need to map and unmap the framebuffer memory during a resize 
>> operation.  
>> How complicated do you think this would be?
> 
> I am not familiar enough with the Linux frame buffer code to even hazard 
> a guess.  Once the frame buffer is registered in the probe function can the
> memory be changed without crashing the app that has mmaped it in?

Easy.  You can zap the mapping, then fill it with other pages in the
page fault handler.  I think the driver already does that anyway to
track framebuffer page writes (aka screen updates).

> Handshake with the backend would complicate things, need to disable shared
> memory access, remapped it and then reenable it.  Not sure how suspend 
> resume might work in this case.

Backend handshake would be more tricky.  You can't release the pages as
long as the backend has them mapped.  Otherwise things will go seriously
wrong, especially in case the kernel decides to use the released pages
as page tables.

When you touch these things anyway it you might want switch over to
grant tables (we have resizeable grant tables and a grant table device
for userspace apps now) to allow the backend access to the framebuffer
memory.  And make the structs 32/64-bit invariant.

> Absolute mouse positioning needs to know the resolution to scale the 
> position properly.  Need some new events to alert it of a resolution change.

Just watch xenbus width/height nodes?

> No further plans at the moment.  I looked into using grant tables for the
> shared memory but decided against it for now.  Grant tables would break
> backwards compatibility unless both memory sharing techniques were
> supported. 

On the flip side the current scheme (one page full of mfns) limits the
video memory, for larger virtual screens this must be changed anyway.
So maybe just keep the current scheme for 800x600 fixed size?  And
require grant tables for the resizable fb?  That will make the amount of
backward compatibility code smaller as the resizeable bits are required
in the grant tables code paths only.

cheers,
  Gerd