From: aragorn@chatfactory.invalid   
      
   J.O. Aho wrote:   
      
   > Aragorn wrote:   
   >   
   >> [...] - the AMD64 Live CD I have for instance goes haywire on my two   
   >> different videocards[1] - and then this would automatically include a   
   >> newer kernel, or so I imagine.   
   >>   
   >> [1] I've got two videocards in the new machine I spoke of earlier.  One   
   >> is a brandnew Asus GeForce 8800 GTS PCIe card with 640 MB of memory,   
   >> which will be driving my two SGI 21" monitors for X11 in an unprivileged   
   >> Xen domain.   
   >   
   > Use the VESA driver during install of the Gentoo and then install the   
   > nVidia driver when all is finished. In your case it may be better to just   
   > use the VESA until nVidia has released a Xen compatible driver.   
      
   Sure, I have no problems installing the system via the character mode   
   commandline console, as I stated earlier.  It's just that the Live CD   
   attempted to start up X11 - which I had not expected it to do - and then   
   went a little crazy on the fact that there is a PCI Radeon card (which   
   always takes precedence as the primary videocard) and a PCIe GeForce card.   
      
   It attempted to load the nVidia driver, or so the error messages said, and   
   then it b0rk3d on loading the GLX module.  I still need to properly connect   
   that machine to the internet hardwarewise, so my attempt to boot from the   
   Live CD was just a test, not an actual installation attempt.   
      
   As for nVidia releasing a Xen-compatible driver - or let us have a wild   
   dream for a moment: having them open up their source code - that is not   
   going to happen.  The best they will do is offer a driver that no longer   
   needs to be patched in order to run it inside a GNU/Linux system in a   
   Xen /dom0./   
      
   For those not familiar with Xen, /dom0/ is the management virtual machine,   
   i.e. the operating system started on top of the Xen hypervisor at   
   (hardware) boot time, and from which other virtual machines are created,   
   started, stopped, paused and saved.  /dom0/ has direct access to the   
   hardware via special drivers.  The other virtual machines are called /domU/   
   (the unprivileged domain) and in this environment, the kernels of the   
   respective operating systems use only front-end drivers, which access the   
   hardware via the back-end drivers in the /dom0/ kernel.   
      
   At least, that's how it works for paravirtualization.  Xen also supports   
   hardware virtualization on Intel CPUs with Vanderpool technology (VT) or   
   AMD CPUs with Pacifica technology (SVM), in which case the "guest"   
   operating systems in a /domU/ can make use of their native drivers.   
      
   As I wrote above, nVidia's latest driver now no longer requires patching for   
   it to be able to work inside a /dom0/ Linux kernel - it previously required   
   patching because the presence of Xen in memory broke the driver's ability   
   to access the videocard's physical address space correctly.  Allegedly - or   
   so one of the nVidia developers wrote on a forum, passing "IGNORE_XEN" as a   
   parameter to the building of the driver's kernel interface code should fix   
   this.   
      
   However - and despite the rather popular tendency to run X11 in /dom0/ - the   
   nVidia driver still does not have access to the adapter's 3D hardware   
   acceleration from within an unprivileged virtual machine.  Hence my need to   
   hide the adapter from /dom0,/ which will then subsequently make the   
   adapter's hardware directly available to /domU./   
      
   On account of running X11 inside /dom0/ - again, however popular it may be -   
   this totally defeats the purpose of running Xen at all, in my humble   
   opinion.  /dom0/ has access to the memory of each /domU/ and we all know   
   that (especially proprietary) video drivers are the number one cause for   
   stability problems in the Linux kernel.   
      
   The idea behind Xen is that you can shield off the less stable environments   
   from the normally stable ones, so that mission-critical virtual machines   
   can remain uncompromised.  Ergo, if you run X11 inside /dom0/ and you run a   
   few servers in unprivileged virtual machines, then an eventual crash or   
   need to reboot in /dom0/ will compromise all those other servers as well.   
   Running X11, especially with a proprietary video driver, inside /dom0/ is   
   like doing your daily work as root, i.e. that's a definite Don't_Do_That   
   (TM). ;-)   
      
   >> I don't need those on the installation media themselves, of course.  I am   
   >> however currently still waiting until the official release of 2.6.24, as   
   >> that kernel has several new features that I really want - the new   
   >> scheduler, for one - and I don't plan on compiling a kernel now and   
   >> configuring/compiling one again in one or two weeks.   
   >   
   > It's rc6 at the moment, so it should come out soon, and you need only to   
   > configure it once even if you try out the rc6 first, as all you need to do   
   > is to copy the .config to the final version and run "make oldconfig".   
      
   If they don't shuffle around configuration options anymore in the meantime,   
   that is... :-/  Typically, when Linus announces a feature freeze, everyone   
   will be squeezing in last-minute feature patches again... :-/   
      
   > Can even be so that all the changes between rc6 and final version will be   
   > for other architectures than yours, then it won't make any difference for   
   > you irf you run a rc or final.   
      
   Could be, but life has taught me not to be so optimistic... ;-)   
      
   > But of course if there will be a load of x86/amd64 changes in last minute,   
   > then it may feel a bit dumb, but the amd64 should compile things quite   
   > fast, at least mine does.   
      
   Well, it's a twin socket (ccNUMA) dualcore Opteron 2218 HE (2.6 GHz), with a   
   SAS RAID 5 and 32 GB of pc5300 DDR-2 memory - with maximum ECC protection,   
   so that'll slow it down a bit - so it should indeed be fast enough, but I   
   have a habit of going over each and every kernel configuration option   
   integrally upon each configure, and this takes up far more time than the   
   actual compile. :-)   
      
   And then of course, as I said, I will be custom-configuring each virtual   
   machine's designated kernel and installation.  For instance, there's no   
   need to have 32-bit (multilib) support in a 64-bit-only server environment,   
   but my X11 environment will need 32-bit support.  I'm also still   
   contemplating the hardening stuff like RBAC and/or PAX.   
      
   In addition, I have very little knowledge of iptables and routing, and I'll   
   have to set up everything using a custom routing table, as I'll only have   
   one public IP address, but all virtual machines should have access to the   
   internet.  For /dom0,/ this only need be /ssh/ access, but I might set up   
   a /ssh/ DMZ inside one of the other virtual machines, so that one   
   must /ssh/ into that virtual machine first and then from there /ssh/ into   
   the /dom0./  This is probably the wisest solution. ;-)   
      
   Oh, and I have lots of other precautions in mind as well.  For starters, I   
   intend to run every virtual machine with a read-only root filesystem during   
   normal system operation.  Other filesystems will be read-only as well - but   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)