[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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=,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.

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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.