WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

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