| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel][RFC] Dynamic modes support for PV xenfb (included)
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
|
|
|
| |
|
Home