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: Thu, 31 Jan 2008 10:06:32 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Delivery-date: Thu, 31 Jan 2008 01:06:57 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <47A0DDB4.20103@xxxxxxxxxx> (Pat Campbell's message of "Wed\, 30 Jan 2008 13\:27\:32 -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> <87sl0fxl5j.fsf@xxxxxxxxxxxxxxxxx> <47A0DDB4.20103@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:
[...]
>> 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.

Every slot in pd[] gets us 2M (64 bit).  The shared page has space
left for about 500 slots.  We can easily increase pd[] to 256 slots,
good for 512M of framebuffer, or 128 Megapixels (>12000x10000), *and*
leave plenty of space in the shared page for future uses.

The backend should map precisely as much framebuffer as the frontend
tells it (struct xenfb_page member mem_length), using as much of pd[]
as necessary for that.

> 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?

I haven't reviewed your patch in detail.  The change in fb mapping
stuck out, and I wanted it discussed before I do that.  Assuming we
can agree to extending pd[] instead, would you mind preparing a new
patch for us to review?

[...]

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