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

[Pat Campbell <plc@xxxxxxxxxx>]

Markus Armbruster wrote:
> Pat Campbell <plc@xxxxxxxxxx> writes:
>
>   
>> Markus Armbruster wrote:
>>     
>>> The current PVFB code shares the framebuffer as follows.  The
>>> framebuffer is described by a two level directory.  The first level is
>>> the page directory pd[] in the shared page.  pd[] contains the mfns of
>>> the second level directory pages.  Those form an array containing the
>>> mfns of the framebuffer.
>>>
>>> Your patch replaces both levels of the page directory by grants, but
>>> not the framebuffer itself.  What exactly does that buy us?
>>>   
>>>       
>> Patch does not replace the pd array.  That is still being used to
>> maintain backwards compatibility.  The required framebuffer memory is
>> allocated in xenfb_probe() and is never reallocated or changed.  Only
>> the mapping to the framebuffer is changed.
>>
>> Maybe some pseudo code this will make it clearer.
>>
>> Frontend (FE)
>>    Determine framebuffer size
>>    Allocate framebuffer 
>>    Fill in array of mfns
>>    Set shared page info to default mem length, width and height
>>    Fill in grant refs using array of mfns
>>    Back end Connected?
>>         Send map extended event (uses grant ref)
>>    Map extended done event?
>>         Free grant refs
>>
>> Backend  (BE)
>>    Calculate number of mfns based on mem length from shared  page
>>    Map in and point at framebuffer
>>    Map extended event?
>>          Map in using grant ref
>>          Change framebuffer pointer to the new location
>>                 (still the same FE memory but now we can reach father
>> into it) 
>>          Send Map extended done
>>
>> At this point the Backend is still treating the framebuffer as
>> 800x600x32 but does has access to the extended framebuffer memory but
>> does not use it.  When a resize event occurs the screen geometry changes
>> but not the framebuffers mappings.
>>     
>
> Understood.
>
>   
>> So to answer what it buys us.  It buys us access to a larger framebuffer
>> for higher resolutions support.
>>     
>
> I can't see how using grants for the page directory is an improvement
> over your previous iteration, which used pd[].  Can you explain?
>   
I will try, I am not the greatest communicator lately. 

Previous iteration did use pd[] extending it to 3 from 2, this had the
drawback of limiting our frame buffer size to a max of 6 MB for a 64 bit
guest, 12mb for a 32 bit guest.  6MB can handle a maximum of 1280x1024
which in previous emails was deemed not enough. 
HD 1080  1920x1200 requires   9MB   (pd[5], 64bit)
WQXGA  2560x1600 requires 16MB   (pd[8], 64bit)

I could of just extended pd[] some more to increase the available slots
but every time we want to increase the total frame buffer size we have
to compile both ends.  Probably could just keep reading/mapping until we
hit a NULL in the backend to eliminate that issue but that ends adding
any new items to the shared info page.

By using grants:
   I don't effect the current shared info
   Don't have to deal with differences between a 64 bit long and a 32
bit long. 
   Single grant ref fits within the event structure

Are those benefits worth the code complexity that grants added?   Not
sure.  Other than grants, which I can remove and revert to pd[], are all
the other issues that were raised addressed?

While I was working on this I "briefly" looked at the grant APIs to see
how hard it would be to create a new API that allocates and claims a
continuous block of references.  If I had a guaranteed continuous block
I would then only need to send the initial ref number and a count to the
backend.


  


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel