On Fri, Oct 03, 2003 at 11:23:02AM +0100, Ian Pratt wrote:
> Alexander Kellett wrote:
> > btw, just fyi the xendemo iso image seems to have corrupt
> > src dir. not certain of this though, could be a local problem
>
> Hmm, we've had success reports from others, so I suspect the
> problem may be at your end. Have you checked the md5sum?
md5sum checked out correctly and i just did a quick
check from the iso itself (loop mounted) to find that
once again the src directory is corrupted. note, its
the src dir only, the actual root dir README's etc
all appear to be fine. oh, and its the files
themselves not the directory entries.
> > i'm guessing that the Xen VMM has its own little drivers for
> > each thing on the system, and i assume they are forwarded
> > after being resource divided somehow, or do the ports of
> > the os's also require new drivers that use simplified xen
> > "hardware"?
>
> For disk and network the hardware device drivers are in Xen and a
> idealised virtual interface is exported to the guest OSes which
> then use simple custom device drivers.
aah. okay. thought that may be the case.
> > given the note about 'agpgart' in the README.CD
> > i'm guessing that you somehow divide the hardware up between
> > users in fact.
>
> We do graphics a bit differently: a domain (guest OS) may be
> granted access to a set of hardware resources, allowing it to
> control them directly. This seemed the most sensible thing to do
> for the display, since it enables an unmodified Xserver to run,
> and it can do its own virtualisation for other guest OSes.
how does switching from one guest to another work exactly?
you somehow supervise the mode switch?, or, is the host
controled through a guest application in any case?
> The problem with agpgart is that we don't currently virtualise
> and export enough of the PCI interface to the privileged guest OS
> to enable it work. We'll fix this at some point.
aah. okay. nice approach. does sound also follow this hardware
resources splitting?. given that you have this potentional, maybe
it would be an idea to "lock" a given isa/pci card to one running
guest, this would allow for use of for example winmodems under
windows, while not having multiplexing problems.
> > as i'm unable to get at the source tree (the burnt cdrom doesn't
> > work and network connection is minimal here) i can't confirm
> > my assumptions. but, i wondered, is it possible for xen to
> > provide multiple virtualized and yet still accelerated graphics
> > cards to the underlying os?
>
> To do that, we'd need to put some part of the accelerated
> graphics drivers into Xen, which we haven't really thought about;
> servers are our main application area.
yeah. this was the principle reason for my emailing, it would really
make a lot of sense for a company such as nvidia to work on extended
xens core drivers (custom agpgart stuff maybe, not sure) and there
own accelerated x driver to allow for fast 3d support inside zen.
vmware is currently not a route. and dual booting is really out
of the question for most people. so, having the ability to run 3d
games within a running instance of windows xp while still begin
able to quickly switch to a background running linux would just
be awesome.
> If you've got limited bandwidth, how about pulling the BK
> repository?
it is only for a short while in any case.
i'll give the bk pull a try from home later on this week.
thanks very much for the quick response
+ thanks to you and all others that worked the project,
Alex
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
Home