Jean Blignaut
2006-May-04 10:20 UTC
[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? 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 ... ) To be able to share or in some way switch which OS has access to your graphics hardware (amongst other such as sound etc.) 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? Forgive my ignorance but the last time I seriously spent time with lowlevel hw programming was on 486 hardware :) Regards Jean Blignaut -- No virus found in this outgoing 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.3/331 - Release Date: 5/3/2006 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Petersson, Mats
2006-May-04 11:26 UTC
RE: [Xen-devel] possible to give/switch direct graphics hw access to doms?
> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of > Jean Blignaut > Sent: 04 May 2006 11:21 > To: xen-devel@lists.xensource.com > 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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Muli Ben-Yehuda
2006-May-04 11:32 UTC
Re: [Xen-devel] possible to give/switch direct graphics hw access to doms?
On Thu, May 04, 2006 at 01:26:21PM +0200, Petersson, Mats wrote:> 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].Does gart provide a 0-based IO space? I don''t recall that it does. Or do you have in mind a scheme where a 0-based IO address isn''t necessary? Cheers, Muli _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Petersson, Mats
2006-May-04 11:43 UTC
RE: [Xen-devel] possible to give/switch direct graphics hw access to doms?
> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of > Muli Ben-Yehuda > Sent: 04 May 2006 12:32 > To: Petersson, Mats > Cc: xen-devel@lists.xensource.com; Jean Blignaut > Subject: Re: [Xen-devel] possible to give/switch direct > graphics hw access to doms? > > On Thu, May 04, 2006 at 01:26:21PM +0200, Petersson, Mats wrote: > > > 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]. > > Does gart provide a 0-based IO space? I don''t recall that it > does. Or do you have in mind a scheme where a 0-based IO > address isn''t necessary?The GART allows TRANSLATION of DMA-accesses from PCI-space to physical RAM, just like a "proper" IOMMU. I''m sure there are some limitations, and it may not actually work for graphics cards that are able to DMA from just about anywhere in the guest memory space - and the mapping would need to be set up by the hypervisor before-hand, so we can''t just map it on a fault in some way or another. I know that we''re working on a "proper" IOMMU that will be in some future generation of AMD processors - I don''t know which generation these will be in, but it''s NOT the ones coming shortly, that''s for sure... -- Mats> > Cheers, > Muli > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com > http://lists.xensource.com/xen-devel > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jean Blignaut
2006-May-09 14:01 UTC
[Xen-devel] possible to give/switch direct graphics hw access to doms?
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?) 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 -----Original Message----- From: Petersson, Mats [mailto:Mats.Petersson@amd.com] Sent: Thursday, May 04, 2006 1:26 PM To: Jean Blignaut; xen-devel@lists.xensource.com Subject: RE: [Xen-devel] possible to give/switch direct graphics hw access to doms?> -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of > Jean Blignaut > Sent: 04 May 2006 11:21 > To: xen-devel@lists.xensource.com > 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@lists.xensource.com http://lists.xensource.com/xen-devel
Petersson, Mats
2006-May-09 14:47 UTC
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 remotedesktopSure. 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@amd.com] > Sent: Thursday, May 04, 2006 1:26 PM > To: Jean Blignaut; xen-devel@lists.xensource.com > Subject: RE: [Xen-devel] possible to give/switch direct > graphics hw access to doms? > > > -----Original Message----- > > From: xen-devel-bounces@lists.xensource.com > > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Jean > > Blignaut > > Sent: 04 May 2006 11:21 > > To: xen-devel@lists.xensource.com > > 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@lists.xensource.com > http://lists.xensource.com/xen-devel > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Jean Blignaut
2006-May-09 15:49 UTC
RE: [Xen-devel] possible to give/switch direct graphics hw access to doms?
>-----Original Message----- >From: Petersson, Mats [mailto:Mats.Petersson@amd.com] >Sent: Tuesday, May 09, 2006 4:48 PM >To: Jean Blignaut; xen-devel@lists.xensource.com >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@amd.com] > Sent: Thursday, May 04, 2006 1:26 PM > To: Jean Blignaut; xen-devel@lists.xensource.com > Subject: RE: [Xen-devel] possible to give/switch direct > graphics hw access to doms? > > > -----Original Message----- > > From: xen-devel-bounces@lists.xensource.com > > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Jean > > Blignaut > > Sent: 04 May 2006 11:21 > > To: xen-devel@lists.xensource.com > > 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@lists.xensource.com > 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@lists.xensource.com http://lists.xensource.com/xen-devel