>-----Original Message-----
>From: Petersson, Mats [mailto:Mats.Petersson@xxxxxxx]
>Sent: Tuesday, May 09, 2006 4:48 PM
>To: Jean Blignaut; xen-devel@xxxxxxxxxxxxxxxxxxx
>Subject: RE: [Xen-devel] possible to give/switch direct graphics hw access >to
>doms?
>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...
Yeah I was going to add games to my list but forgot.
So given these factors it would be best (in theory) to implement some thing
like this in BIOS?
--
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
>
>
--
No virus found in this incoming 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
|
Home