Xen 
 
Home About Xen.org Xen Xen Summit Wiki Mailing List Bug Tracker Xen Downloads
 
   
 

xen-devel

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

To: Pat Campbell <plc@xxxxxxxxxx>
Subject: Re: [Xen-devel][RFC] Dynamic modes support for PV xenfb (included)
From: Markus Armbruster <armbru@xxxxxxxxxx>
Date: Wed, 30 Jan 2008 18:45:12 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Delivery-date: Wed, 30 Jan 2008 09:45:42 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <47A07E7E.6040601@xxxxxxxxxx> (Pat Campbell's message of "Wed\, 30 Jan 2008 06\:41\:18 -0700")
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <479D2669.5060105@xxxxxxxxxx> <87hcgv643k.fsf@xxxxxxxxxxxxxxxxx> <47A07E7E.6040601@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)
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?

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