From: user@example.net   
      
   Aragorn wrote:   
      
   > Either way, the author of the article was attempting to hide the device from   
   > the hypervisor/dom0 and thus had no need for any IOMMU, in software or   
   > otherwise.  I'm also not so sure on how his experiment - even with the   
   > effect of the Windows Remote Desktop Protocol or the reputed poor stability   
   > of Windows itself - could possibly lock up his machine solidly, unless   
   > there is a serious bug in the hypervisor code.  But then again,   
   > hardware-based virtualization is a different beast from paravirtualization.   
   >   
   > Normally, when hardware-based virtualization is used, the hypervisor   
   > and /dom0/ run in the CPU's root mode - which has its own four privilege   
   > rings - while /domU/ virtual machines run in the CPU's non-root mode -   
   > equally with four privilege levels.  So technically, if the machine locked   
   > up solid, then this means that something has gone wrong in the root mode of   
   > the CPU, and thus in the hypervisor code - unless of course we're talking   
   > of a bug/flaw in Intel's Vanderpool technology.   
   >   
   > Still, it was an interesting read, and certainly food for thought, thank   
   > you. :-)   
      
   I'm following your progress with interest here, as some of the ideas I   
   have had, you are now trying to do, mainly this with graphics access for   
   the domU.   
   What I lack at the moment is a machine powerful enough to try Xen on.   
      
   All Xen experience I have is the little I did experimented at work, but   
   that was just to run a number of webserver which don't require graphics   
   output as a virtual media player.   
      
      
   --   
      
     //Aho   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)