> 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.
Ahh, I bet your current kernel doesn't have support for
compressed iso images.
CONFIG_ZISOFS=y
> > 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?
Although we fully virtualize the disk and ethernet, only one
domain should be granted access to non-virtualised h/w such as
the frame buffer/
> > 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.
I'm afraid we haven't thought about sound, though we'd probably
follow a similar model to our approach for graphics for
'low-bandwidth' devices.
> > > 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.
You never know, if we succeed in building a user community around
Xen nvidia might one day release drivers ;-)
> thanks very much for the quick response
> + thanks to you and all others that worked the project,
Cheers,
Ian
-------------------------------------------------------
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