what i could tell you is that xen is a little behind with the sources, but
still if configured in the right way there should be no problem in running a
box. you just have to remember that with xen you'll need a "base" system,
then another system to run on this base with reduced priviledges and
assigned stuff. so you'll just need a base gentoo (stage3 should be fine),
then you should configure xen to have another stage3 with installed apps.
the xen problem is that you'll need 2 linuxes to run one linux. but you'll
be allowed to assign processors fragments or ram portions in the way you
like. if you don't really need xen (you would run at least 2 different
systems like using one linux i686 one amd64 or one linux and one windows -
which should run well since you have vt) i think that using it would be a
waste of time. also there are tools that let you install windows in boxes,
like vmware and such (they're very good and fast and don't put you in the
situation to use xen when xen is way back with kernel support and a lot of
the new stuff in new pcs is supported only from the 2.6.21 or later kernel
like the jmicron controller used in asus mobos). so my advice is avoid using
xen unless it is really, really and i mean really necessary (you'll need 2
systems and a lot of configuration to run a single linux box that is slower
than a native one).

for the radeon driver, always use the ~amd64/~x86. always, since the driver
is updated every month and has new things. for example the latest portage
8.433 has aiglx support support for the latest xorg and xorg-server (even if
compiz won't work with xorg-server-1.4) and it has a great performance
boost. also the new radeon has a hidden option to be added into the device
section for enabling a render:
Option "TexturedXrender" "true"
it seems that this has a performance boost with rendering. for ati, you'll
also have to control that you have the following files in /usr/lib/
libGL.so.1, libGL.so.1.2. if one of them is missing create a symlink to the
other libGL.so.x. this is due to a soname bug present in the latest fglrx
releases. also be aware that there's a memory leak bug and apps like
glxgears, amarok, firefox or others that use opengl would continue to suck
out system memory. stay tuned to see if this happens and restart xorg when
the system ram has reached a critical limit like 85-90%.
or you may want to try the xf86 ati drivers for r500 (your chipset) because
airlied, who is the main dev for the r500/600 radeon driver now works for
red hat, has added some cool features like radeon modesetting and other
stuff in the latest releases and you should be able to get a good working
driver. you'll just have to add radeon support to xorg and use the radeon
driver from ~amd64/~x86 branch. with ati these days is almost necessary to
use this branch since the new releases add a lot of new features and fixes
due to the recent amd/ati releasing specs and helping devs. i also would say
you to remove the fbdev and all framebuffer ati modules or so from kernel
since they're buggy and won't work correctly. also fb is useless if you use
vesa or other stuff.
is you use the fglrx then you'll also need to add the following stuff to the
device section of your xorg.conf:
  Option        "RenderAccel" "true" <--- needed for rendering stuff: forces
sw rendering where hw doesn't work.
  Option        "AllowGLXWithComposite" "true" <--- needed for compiz/beryl
  Option        "HWCursor" "On" <---- needed to fix a bug with the mouse
cursor
  Option       "OpenGLOverlay" "off" <---- disables opengl overlay and
doesn't work with Xv enabled
  Option        "VideoOverlay" "on" <--- enables Xv overlay doesn't work
with opengloverlay enabled
  Option       "no_dri" "no" <---- use dri
  Option       "UseInternalAGPGART" "no" <---- this is needed for some
agpgart issues
  Option       "FSAAEnable" "no" <---- disables fsaa since it is buggy on
linux
  Option       "BlockSignalsOnLock" "on" <----- needed to a have a stable
driver
  Option       "Capabilities" "0x00000000" <---- set capabilities to default
since some cards are buggy with non default capabilities
  Option       "mtrr" "off" <---- disables mtrr
  Option        "XAANoOffscreenPixmaps" "true" <---- needed to fix the
watermark issue of the latest fglrx releases
  Option       "UseFastTLS" "0" <---- if you use wine don't set this to
higher than 1.

also for a working compiz you'll need this section:

Section "Extensions"
  Option        "DAMAGE" "true"
  Option        "RENDER" "true"
  Option        "Composite" "Enable"
EndSection

this is the working configuration for a fglrx running with compiz. if you
experience issue with compiz then set the compiz setting from
"texturefrompixmap" rendering to "force copy".

2007/12/8, Florent Ouchet <ouchet.florent@laposte.net>:
>
> Florent Ouchet a écrit :
> > I experienced some problems with the following combination of software:
> > - xen-sources 2.6.20-r6
> > - xen-tools 3.1.2
> > - ati-drivers 8.40.4
> > - linux 2.6.20
> > - xorg-server 1.3.0.0-r2 (build with support for fbdev, vesa and fglrx)
> >
> > The system is a Dom0 of a paravirtualized system:
> > - Core 2 Duo 2.4GHz (vT enabled)
> > - 2GB RAM
> > - ATI Radeon x1300 video card
> >
> > Is anyone running such a configuration with success? I have to stay
> > with the vesa driver without hardware acceleration.
>
> No one managed to get such a config running with optimal performances? :(
>
>
> --
> gentoo-amd64@gentoo.org mailing list
>
>


-- 
dott. ing. beso