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: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Date: Wed, 30 Jan 2008 20:43:12 +0000
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Markus Armbruster <armbru@xxxxxxxxxx>
Delivery-date: Wed, 30 Jan 2008 12:43:59 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <479D2669.5060105@xxxxxxxxxx>
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>
Reply-to: "Daniel P. Berrange" <berrange@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.1i
On Sun, Jan 27, 2008 at 05:48:41PM -0700, Pat Campbell wrote:
> Enough of the implementation has changed so I decided to go through
> another RFC cycle.
> 
> What this patch does
>    Allows PV framebuffer to be resized via xrandr or fbset and to start
>    up the GUI at higher than 800x600
> 
> What is new in this iteration:
>    1. No longer extending pd[] for extra memory
>    2. New kernel xenfb.videomem param
>    3. Added new events for extended FB memory mapping
>    4. Extending FB memory via gntdev, supports up to 20MB
>       on 64 bit guest, 40MB for a 32 bit guest.  Uses a two
>       level grant table.
>    5. xenkbd exported func to set pointer screen geometry
>    6. Removed "wart" from fbif.h
> 
> New kernel xenfb param:
>     videomem array,  FB size in MB, max scanline length
>     vm config ie:
>           extra="xenfb.videomem=5,1024 "

On the one hand I like this because this gives the guest admin control over
how much of their RAM they want to put aside for the FB. On the other hand I
don't like this because it also impacts RAM allocation inside QEMU which is
a denial of service attack on Dom0.  

I was originally thinking that you'd put 'videomem' as a parameter in the
PVFB config of the guest, eg

 vfb = [ "type=vnc,vncunused=1,vnclisten=127.0.0.1,vncpasswd=,videoram=5" ]

I'm fine with it being a kernel param, as long as we also have a way for the
Dom0 admin to specify a hard limit in the vfb= config option. A combo of both
will allow flexibility for domU admin, and good control for the Dom0 admin.

> Screen should start out at 800x600 in the console and then switch to
> whatever resolution you specified in xorg.conf for the GUI.  Switching 
> to the console will revert screen to 800x600.
> 
> X11 fbdev will use the builtin resolution of 800x600 if alternate modes are
> not specified in xorg.conf.

I don't have an answer for this problem, since its not my areas of expertise,
but requiring manual xorg.conf settings is really not a very nice thing to
deal with. Xorg is moving to a 100% auto-configured setup. With regular
monitors it'll probe EDID or whatever to get display capabilities - obviously
we don't have that capability, but I wonder if there's some way we can provide
enough info to X so that it can automatically enable any of the resolutions
without needing Modelines / Modes.

Ideally the out of the box config would allow X to auto-startup with zero
config file, pick a resonable default resolution, and provide enough info
to allow 'xrandr' to be used to resize to any resolution within the confines
of the video RAM allocation.

Dan.
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=| 

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