Jean Blignaut wrote:
>
> Why not use suspend resume?
> You could simulate say a keyboard sleep button push or some
> thing to make the guest OS go into sleep mode while
> switching the full power of you graphichs hw over to another
> OS (As I recall there is a special mode that the x86 uses for
> powermanagement interrupts etc. why not use an existing
> system and just expand on it?)
The problem with a SUSPEND/RESUME button is that it's controlled almost
entirely by the BIOS - which means that the hypervisor will not have
much say in what happens. Ok, so in SVM (AMD's solution) we could very
well intercept the SMI (System Management Interrupt) that happens due to
the button-press, but unfortunately, the hardware that we need to deal
with, primarily the south-bridge, will need specific hardware support
for each model (and perhaps also different depending on each hardware
platform, i.e. some models of a machine will need one setup, another
model will need another setup), and we'd have to replicate all the
power-management code in the BIOS and make it play with the hypervisor.
It could probably be done, but it's not going to be easy, and I think
it's more sensible to actually use a para-virtualized driver for the
Windows system, and then use a back-end/front-end model as per normal
Xen to achieve decent performance using the native driver in Dom0.
>
> I think that the problem with remote desktop and vnc has is
> that its all very well for run of the mill office apps and
> server stuff (I'm actually unix sysadmin at a small isp so
> excuse the "stuff" shorthand ;-) ) the real areas where what
> I'm asking would be use full is for powerfull graphics apps
> and games. I don't think you'll find any one happily working
> in may/3d studio max/photoshop etc. via vnc or remotedesktop
Sure. Game-playing would be another place where graphics performance is
critical. I don't think Xen will be ready for either of these types of
apps for some time...
--
Mats
>
> -----Original Message-----
> From: Petersson, Mats [mailto:Mats.Petersson@xxxxxxx]
> Sent: Thursday, May 04, 2006 1:26 PM
> To: Jean Blignaut; xen-devel@xxxxxxxxxxxxxxxxxxx
> Subject: RE: [Xen-devel] possible to give/switch direct
> graphics hw access to doms?
>
> > -----Original Message-----
> > From: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
> > [mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Jean
> > Blignaut
> > Sent: 04 May 2006 11:21
> > To: xen-devel@xxxxxxxxxxxxxxxxxxx
> > Subject: [Xen-devel] possible to give/switch direct
> graphics hw access
> > to doms?
> >
> >
> > I hope this is the right place to be posting this question.
> >
> > I was wondering about the possibility of giving full access to
> > graphics hw to domU perhaps especially when intel VT or AMD
> pacifica
> > is available?
>
> In short: no.
>
> The problem here isn't so much the ownership of the graphics
> (that CAN be dealt with), but the fact that in HVM (Intel
> VT/AMD SVM) we "lie" to the DomU about where it's memory is,
> because most operating systems assume that memory starts
> roundabout address zero, and goes up to whatever number of
> megabytes - which of course is true for Dom0, but DomU's
> won't have that setup, so we fake it to LOOK like it is by
> using page-tables that are "adjusted" when the guest sets
> it's paging up.
>
> However, the graphics card will have direct memory accessing
> - which means that the graphics card will need to be told
> about the ACTUAL physical address (not the fake one we told
> the guest about).
>
> The solution is an IOMMU device, which is basicly a
> translation system to translate a "fake physical" to "actual
> physical" address. There is a GART in the AMD x86-64
> processors that COULD be used for this purpose, but currently
> there's no code to support this [although I believe it's
> being worked on].
>
> >
> > I have been reading every thing I can find on the subject
> as it would
> > be most use full for my personal desktop system (and I'm
> sure I'm not
> > alone ... )
>
> No, this question comes up every few weeks or so, and I'm
> sure there are MORE people who actually want it than those
> that ask about it...
> >
> > To be able to share or in some way switch which OS has
> access to your
> > graphics hardware (amongst other such as sound etc.)
>
> Currently you can (sort of) share it, but if you want to run
> Windows on a HVM system, the best solution is to use "Remote
> Desktop" and use the Dom0 display for your display device.
> Similarly, VNC works well for Linux, whether it's
> para-virtual or HVM...
> >
> > I realize that this is only realy use full in desktop/workstation
> > situations but I have been pondering the subject for some years.
> >
> > One problem I guess would be the state/mode of the graphics
> hardware
> > in different doms - whitch is probably why they could not
> share it at
> > the same time - but perhaps switching is more feasible. I seem to
> > remember that there was an INT 10 function in vga (pre svga) that
> > could store the state of all the registers etc. on the
> card. Combined
> > with some sort of frame buffer (that only gets used when graphics
> > operation is suspended ex. A nother dom has the graphhw at
> the moment)
> > you could perhaps store the mode, state and graphichs ram
> of each dom
> > and be able to restore each in turn?
>
> The first criteria in this case would be that the DomU is
> aware of the fact that it's on a virtual machine - otherwise,
> the DomU can't perform the "save state" function - most
> drivers have that functionality, because that's how
> power-saving the graphics card works, including "Suspend to
> ram" and "Hibernate", etc. But it's a case of "How to tell
> the driver to do this".
>
> There is of course the problem that if the OS isn't helping
> out when you're saving state (as the OS does in Power-saving
> state-save), then you may have to STORE ALL OF THE
> FRAME-BUFFER, which could easily be 128MB - which in turn
> means more memory for each domain.
>
> I think you really need to have specific drivers that are
> virtualization aware (para-virtualized drivers) to solve
> this. In this case, you could for example allow the card to
> not USE all of it's frame-buffer for one particular guest,
> and have several sections of frame-buffer, one for each
> guest. That way, there will be no need to store 128+MB of
> frame buffer each time.
>
> Another solution is of course a "simple but efficient"
> para-virtualized driver, which allows the guest to just pass
> the drawing information from the primitives in the guest
> directly to the driver of the actual display (the latter is
> either DIRECTLY to the driver with some sort of switching, or
> to an application that draws within a window). In this case,
> the driver in the guest doesn't actually draw anything, or
> even have any real hardware (a faked entry in the PCI device
> config space that we provide, so that the driver can be
> loaded with whatever Plug&Play mechanism the OS uses).
>
> >
> > Forgive my ignorance but the last time I seriously spent time with
> > lowlevel hw programming was on 486 hardware :)
>
> That's probably some time ago then ;-) But I'd say you have
> the right questions, give or take a bit...
>
> >
> > Regards
> > Jean Blignaut
> >
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.392 / Virus Database: 268.5.3/331 - Release
> Date: 5/3/2006
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.392 / Virus Database: 268.5.5/334 - Release
> Date: 5/8/2006
>
>
> --
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.392 / Virus Database: 268.5.5/334 - Release
> Date: 5/8/2006
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home