This patch supports basic gfx passthrough on QEMU: - disable emulated VGA adpater if there is passthroughed gfx - register/unregister legacy VGA I/O ports and MMIOs for passthroughed gfx Signed-off-by: Ben Lin <ben.y.lin@intel.com> Signed-off-by: Weidong Han <weidong.han@intel.com> _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Teo En Ming (Zhang Enming)
2009-Aug-28 15:34 UTC
[Xen-devel] [PATCH 2/2] graphics passthrough with VT-d
This patch supports basic gfx passthrough on QEMU: - disable emulated VGA adpater if there is passthroughed gfx - register/unregister legacy VGA I/O ports and MMIOs for passthroughed gfx Signed-off-by: Ben Lin <ben.y.lin@intel.com> Signed-off-by: Weidong Han <weidong.han@intel.com> No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.409 / Virus Database: 270.13.69/2328 - Release Date: 08/27/09 18:02:00 No virus found in this outgoing message. Checked by AVG - www.avg.com Version: 8.5.409 / Virus Database: 270.13.71/2330 - Release Date: 08/27/09 18:02:00 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mr. Teo En Ming (Zhang Enming)
2009-Aug-28 15:55 UTC
Re: [Xen-devel] [PATCH 2/2] graphics passthrough with VT-d
Dear Weidong,
A big big thanks for the vga passthrough patches for xen 3.5-unstable!!!
These are eagerly anticipated patches. As I did not study computer
science and computer architecture, I won''t be able to write those
patches you guys at Intel wrote.
I applied the following patches *xen-gfx-passthrough.patch
<http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin>
and **qemu-gfx-passthrough.patch
<http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin>
to xen 3.5-unstable without issues.*
Then I tried to apply the 3rd patch you provided at
http://lists.xensource.com/archives/html/xen-devel/2009-08/msg01047.html
I saved the following code
<CODE>
diff -r 494be76c1ad9 tools/firmware/hvmloader/Makefile
--- a/tools/firmware/hvmloader/Makefile Thu Aug 27 16:54:33 2009 +0800
+++ b/tools/firmware/hvmloader/Makefile Thu Aug 27 17:22:01 2009 +0800
@@ -50,6 +50,7 @@ roms.h: ../rombios/BIOS-bochs-latest ../
roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \
../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h
sh ./mkhex rombios ../rombios/BIOS-bochs-latest> roms.h
+ sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin>> roms.h
sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin>>
roms.h
sh ./mkhex vgabios_cirrusvga \
../vgabios/VGABIOS-lgpl-latest.cirrus.bin>> roms.h
diff -r 494be76c1ad9 tools/firmware/hvmloader/hvmloader.c
--- a/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 16:54:33 2009 +0800
+++ b/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 17:23:00 2009 +0800
@@ -688,9 +688,9 @@ int main(void)
vgabios_sz = round_option_rom(sizeof(vgabios_stdvga));
break;
case VGA_pt:
- printf("Loading Gfx Video BIOS from 0xC0000 ...\n");
- vgabios_sz - round_option_rom((*(uint8_t
*)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512);
+ printf("Loading Gfx Video BIOS from file ...\n");
+ memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt,
sizeof(vgabios_pt));
+ vgabios_sz = round_option_rom(sizeof(vgabios_pt));
break;
default:
printf("No emulated VGA adaptor ...\n");
</CODE>
as intel-gfx-passthru-patch-3.patch and then I tried to apply the patch to xen
3.5-unstable. I got errors. I think it''s because the 3rd patch you
provided is incomplete.
Here''s my patching process:
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name vgabios
./tools/firmware/vgabios
./.hg/store/data/tools/firmware/vgabios
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cp ~enming/vgabios-pt.bin
tools/firmware/vgabios/
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ls tools/firmware/vgabios/
biossums.c clext.c Makefile TODO vbe.h
vgabios.h vgatables.h
BUGS COPYING Notes vbe.c vbetables-gen.c
vgabios-pt.bin
ChangeLog dataseghack README vbe_display_api.txt vgabios.c
vgafonts.h
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# pwd
/usr/src/xen-unstable.hg-vgapt
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wget
http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin
--2009-08-28 23:18:21--
http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin
Resolving lists.xensource.com... 70.42.241.110
Connecting to lists.xensource.com|70.42.241.110|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 12565 (12K) [application/octet-stream]
Saving to: `bincPiiAf0QWg.bin''
100%[======================================================================>]
12,565 30.7K/s in 0.4s
2009-08-28 23:18:22 (30.7 KB/s) - `bincPiiAf0QWg.bin'' saved
[12565/12565]
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv bincPiiAf0QWg.bin
xen-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi xen-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch<
xen-gfx-passthrough.patch
can''t find file to patch at input line 4
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff -r 5d7e7a250267 tools/firmware/hvmloader/config.h
|--- a/tools/firmware/hvmloader/config.h Wed Aug 26 18:28:44 2009 +0800
|+++ b/tools/firmware/hvmloader/config.h Thu Aug 27 16:54:24 2009 +0800
--------------------------
File to patch: ^C
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ex xen-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1<
xen-gfx-passthrough.patch
patching file tools/firmware/hvmloader/config.h
patching file tools/firmware/hvmloader/hvmloader.c
patching file tools/libxc/ia64/xc_ia64_hvm_build.c
patching file tools/libxc/xc_hvm_build.c
patching file tools/libxc/xc_linux.c
patching file tools/libxc/xenctrl.h
patching file tools/libxc/xenguest.h
patching file tools/python/xen/lowlevel/xc/xc.c
patching file tools/python/xen/xend/XendConfig.py
Hunk #1 succeeded at 174 (offset -1 lines).
patching file tools/python/xen/xend/image.py
Hunk #1 succeeded at 780 (offset -6 lines).
Hunk #3 succeeded at 895 (offset -6 lines).
patching file tools/python/xen/xm/create.py
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wget
http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin
--2009-08-28 23:21:35--
http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin
Resolving lists.xensource.com... 70.42.241.110
Connecting to lists.xensource.com|70.42.241.110|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9841 (9.6K) [application/octet-stream]
Saving to: `binglLqkeq4Rj.bin''
100%[======================================================================>]
9,841 24.3K/s in 0.4s
2009-08-28 23:21:36 (24.3 KB/s) - `binglLqkeq4Rj.bin'' saved [9841/9841]
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv binglLqkeq4Rj.bin
qemu-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi qemu-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name hw
./tools/ioemu-remote/hw
./.hg/store/data/tools/ioemu/hw
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv qemu-gfx-passthrough.patch
tools/ioemu-remote/
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cd tools/ioemu-remote/
[root@fedora11-x86-64-host ioemu-remote]# patch -p1< qemu-
qemu-aio.h qemu-img.c qemu-sockets.c
qemu-binfmt-conf.sh qemu-img.texi qemu-tech.texi
qemu-char.c qemu-lock.h qemu-timer.h
qemu-char.h qemu-log.h qemu-tool.c
qemu-common.h qemu-malloc.c qemu-xen.h
qemu-doc.texi qemu-nbd.c
qemu-gfx-passthrough.patch qemu-nbd.texi
[root@fedora11-x86-64-host ioemu-remote]# patch -p1<
qemu-gfx-passthrough.patch
patching file hw/pass-through.c
patching file hw/pass-through.h
patching file hw/pc.c
patching file vl.c
[root@fedora11-x86-64-host ioemu-remote]# cd ..
[root@fedora11-x86-64-host tools]# cd ..
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi
intel-gfx-passthru-patch-3.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1<
intel-gfx-passthru-patch-3.patch
patching file tools/firmware/hvmloader/Makefile
Hunk #1 FAILED at 50.
1 out of 1 hunk FAILED -- saving rejects to file
tools/firmware/hvmloader/Makefile.rej
patching file tools/firmware/hvmloader/hvmloader.c
patch: **** malformed patch at line 24: sizeof(vgabios_pt));
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi
intel-gfx-passthru-patch-3.patch
For everybody''s convenience, I have attached
intel-gfx-passthru-patch-3.patch and the firmware for my nVidia GeForce 8400 GS
PCI Express x16 graphics card in this email.
Please help me complete intel-gfx-passthru-patch-3.patch as I really need it.
Thank you very much!!!
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
Alma Maters: Singapore Polytechnic, National University of Singapore
> This patch supports basic gfx passthrough on QEMU:
> - disable emulated VGA adpater if there is passthroughed gfx
> - register/unregister legacy VGA I/O ports and MMIOs for passthroughed
gfx
>
> Signed-off-by: Ben Lin<ben.y.lin@intel.com>
> Signed-off-by: Weidong Han<weidong.han@intel.com>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 8.5.409 / Virus Database: 270.13.69/2328 - Release Date: 08/27/09
> 18:02:00
>
> No virus found in this outgoing message.
> Checked by AVG - www.avg.com
> Version: 8.5.409 / Virus Database: 270.13.71/2330 - Release Date: 08/27/09
> 18:02:00
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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
Mr. Teo En Ming (Zhang Enming)
2009-Aug-28 16:08 UTC
Re: [Xen-devel] [PATCH 2/2] graphics passthrough with VT-d
The vga bios file for my nvidia geforce 8400 gs was extracted using nvflash.exe executed from a USB floppy drive. I couldn''t run NiBiTor as I don''t have a running native Windows operating system. -- Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) Technical Support Engineer Information Technology Department Asiasoft Online Pte Ltd Tampines Central 1 #04-01 Tampines Plaza Singapore 529541 Republic of Singapore Mobile: +65-9648-9798 MSN: teoenming@hotmail.com Alma Maters: Singapore Polytechnic, National University of Singapore On 08/28/2009 11:55 PM, Mr. Teo En Ming (Zhang Enming) wrote:> Dear Weidong, > > A big big thanks for the vga passthrough patches for xen > 3.5-unstable!!! These are eagerly anticipated patches. As I did not > study computer science and computer architecture, I won''t be able to > write those patches you guys at Intel wrote. > > I applied the following patches *xen-gfx-passthrough.patch > <http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin> > and **qemu-gfx-passthrough.patch > <http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin> > to xen 3.5-unstable without issues.* > > Then I tried to apply the 3rd patch you provided at > http://lists.xensource.com/archives/html/xen-devel/2009-08/msg01047.html > > I saved the following code > > <CODE> > diff -r 494be76c1ad9 tools/firmware/hvmloader/Makefile > --- a/tools/firmware/hvmloader/Makefile Thu Aug 27 16:54:33 2009 +0800 > +++ b/tools/firmware/hvmloader/Makefile Thu Aug 27 17:22:01 2009 +0800 > @@ -50,6 +50,7 @@ roms.h: ../rombios/BIOS-bochs-latest ../ > roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \ > ../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h > sh ./mkhex rombios ../rombios/BIOS-bochs-latest> roms.h > + sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin>> roms.h > sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin>> roms.h > sh ./mkhex vgabios_cirrusvga \ > ../vgabios/VGABIOS-lgpl-latest.cirrus.bin>> roms.h > diff -r 494be76c1ad9 tools/firmware/hvmloader/hvmloader.c > --- a/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 16:54:33 2009 +0800 > +++ b/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 17:23:00 2009 +0800 > @@ -688,9 +688,9 @@ int main(void) > vgabios_sz = round_option_rom(sizeof(vgabios_stdvga)); > break; > case VGA_pt: > - printf("Loading Gfx Video BIOS from 0xC0000 ...\n"); > - vgabios_sz > - round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512); > + printf("Loading Gfx Video BIOS from file ...\n"); > + memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt, > sizeof(vgabios_pt)); > + vgabios_sz = round_option_rom(sizeof(vgabios_pt)); > break; > default: > printf("No emulated VGA adaptor ...\n"); > > </CODE> > > as intel-gfx-passthru-patch-3.patch and then I tried to apply the patch to xen 3.5-unstable. I got errors. I think it''s because the 3rd patch you provided is incomplete. > > Here''s my patching process: > > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name vgabios > ./tools/firmware/vgabios > ./.hg/store/data/tools/firmware/vgabios > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cp ~enming/vgabios-pt.bin tools/firmware/vgabios/ > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ls tools/firmware/vgabios/ > biossums.c clext.c Makefile TODO vbe.h vgabios.h vgatables.h > BUGS COPYING Notes vbe.c vbetables-gen.c vgabios-pt.bin > ChangeLog dataseghack README vbe_display_api.txt vgabios.c vgafonts.h > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# pwd > /usr/src/xen-unstable.hg-vgapt > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wgethttp://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin > --2009-08-28 23:18:21--http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin > Resolving lists.xensource.com... 70.42.241.110 > Connecting to lists.xensource.com|70.42.241.110|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 12565 (12K) [application/octet-stream] > Saving to: `bincPiiAf0QWg.bin'' > > 100%[======================================================================>] 12,565 30.7K/s in 0.4s > > 2009-08-28 23:18:22 (30.7 KB/s) - `bincPiiAf0QWg.bin'' saved [12565/12565] > > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv bincPiiAf0QWg.bin xen-gfx-passthrough.patch > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi xen-gfx-passthrough.patch > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch< xen-gfx-passthrough.patch > can''t find file to patch at input line 4 > Perhaps you should have used the -p or --strip option? > The text leading up to this was: > -------------------------- > |diff -r 5d7e7a250267 tools/firmware/hvmloader/config.h > |--- a/tools/firmware/hvmloader/config.h Wed Aug 26 18:28:44 2009 +0800 > |+++ b/tools/firmware/hvmloader/config.h Thu Aug 27 16:54:24 2009 +0800 > -------------------------- > File to patch: ^C > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ex xen-gfx-passthrough.patch > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1< xen-gfx-passthrough.patch > patching file tools/firmware/hvmloader/config.h > patching file tools/firmware/hvmloader/hvmloader.c > patching file tools/libxc/ia64/xc_ia64_hvm_build.c > patching file tools/libxc/xc_hvm_build.c > patching file tools/libxc/xc_linux.c > patching file tools/libxc/xenctrl.h > patching file tools/libxc/xenguest.h > patching file tools/python/xen/lowlevel/xc/xc.c > patching file tools/python/xen/xend/XendConfig.py > Hunk #1 succeeded at 174 (offset -1 lines). > patching file tools/python/xen/xend/image.py > Hunk #1 succeeded at 780 (offset -6 lines). > Hunk #3 succeeded at 895 (offset -6 lines). > patching file tools/python/xen/xm/create.py > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wgethttp://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin > --2009-08-28 23:21:35--http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin > Resolving lists.xensource.com... 70.42.241.110 > Connecting to lists.xensource.com|70.42.241.110|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 9841 (9.6K) [application/octet-stream] > Saving to: `binglLqkeq4Rj.bin'' > > 100%[======================================================================>] 9,841 24.3K/s in 0.4s > > 2009-08-28 23:21:36 (24.3 KB/s) - `binglLqkeq4Rj.bin'' saved [9841/9841] > > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv binglLqkeq4Rj.bin qemu-gfx-passthrough.patch > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi qemu-gfx-passthrough.patch > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name hw > ./tools/ioemu-remote/hw > ./.hg/store/data/tools/ioemu/hw > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv qemu-gfx-passthrough.patch tools/ioemu-remote/ > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cd tools/ioemu-remote/ > [root@fedora11-x86-64-host ioemu-remote]# patch -p1< qemu- > qemu-aio.h qemu-img.c qemu-sockets.c > qemu-binfmt-conf.sh qemu-img.texi qemu-tech.texi > qemu-char.c qemu-lock.h qemu-timer.h > qemu-char.h qemu-log.h qemu-tool.c > qemu-common.h qemu-malloc.c qemu-xen.h > qemu-doc.texi qemu-nbd.c > qemu-gfx-passthrough.patch qemu-nbd.texi > [root@fedora11-x86-64-host ioemu-remote]# patch -p1< qemu-gfx-passthrough.patch > patching file hw/pass-through.c > patching file hw/pass-through.h > patching file hw/pc.c > patching file vl.c > [root@fedora11-x86-64-host ioemu-remote]# cd .. > [root@fedora11-x86-64-host tools]# cd .. > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi intel-gfx-passthru-patch-3.patch > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1< intel-gfx-passthru-patch-3.patch > patching file tools/firmware/hvmloader/Makefile > Hunk #1 FAILED at 50. > 1 out of 1 hunk FAILED -- saving rejects to file tools/firmware/hvmloader/Makefile.rej > patching file tools/firmware/hvmloader/hvmloader.c > patch: **** malformed patch at line 24: sizeof(vgabios_pt)); > > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi intel-gfx-passthru-patch-3.patch > > For everybody''s convenience, I have attached intel-gfx-passthru-patch-3.patch and the firmware for my nVidia GeForce 8400 GS PCI Express x16 graphics card in this email. > > Please help me complete intel-gfx-passthru-patch-3.patch as I really need it. > > Thank you very much!!! > > -- > Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) > Technical Support Engineer > Information Technology Department > Asiasoft Online Pte Ltd > Tampines Central 1 #04-01 Tampines Plaza > Singapore 529541 > Republic of Singapore > Mobile: +65-9648-9798 > MSN:teoenming@hotmail.com > Alma Maters: Singapore Polytechnic, National University of Singapore >> This patch supports basic gfx passthrough on QEMU: >> - disable emulated VGA adpater if there is passthroughed gfx >> - register/unregister legacy VGA I/O ports and MMIOs for passthroughed gfx >> >> Signed-off-by: Ben Lin<ben.y.lin@intel.com> >> Signed-off-by: Weidong Han<weidong.han@intel.com> >> No virus found in this incoming message. >> Checked by AVG -www.avg.com >> Version: 8.5.409 / Virus Database: 270.13.69/2328 - Release Date: 08/27/09 >> 18:02:00 >> >> No virus found in this outgoing message. >> Checked by AVG -www.avg.com >> Version: 8.5.409 / Virus Database: 270.13.71/2330 - Release Date: 08/27/09 >> 18:02:00 >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tim Moore
2009-Aug-28 16:10 UTC
RE: [Xen-devel] [PATCH(es)] graphics passthrough with VT-d
Teo,
It looks like the patches that Wiedong has supplied already copy the VGA bios
from the card and re-execute it within the DomU, therefore there should be no
need to load it from a file.
I think you will have trouble for 2 reasons:
1) Bios re-execution, these Nvidia cards do not like having the BIOS re-executed
(from memcpy or file)
2) the Base Address Registers (BARs) will require 1:1 mappings to the real
addresses, which these patches dont cater for
If you want to make it work, you will need a card that works without the 1:1
mapping and is more friendly to virtualisation.
ie:
http://www.nvidia.com/object/sli_multi_os.html
(as Andrew Lyon describes)
Dual Quadro FX 5800, 4800, and 3800 professional graphics boards
Tm
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Mr. Teo En Ming
(Zhang Enming)
Sent: 28 August 2009 16:55
To: weidong.han@intel.com
Cc: xen-devel@lists.xensource.com; ''Lin, Ben Y'';
''Kay, Allen M''; ''Jean Guyader'';
Keir.Fraser@eu.citrix.com; bengheng@eecs.umich.edu
Subject: Re: [Xen-devel] [PATCH 2/2] graphics passthrough with VT-d
Dear Weidong,
A big big thanks for the vga passthrough patches for xen 3.5-unstable!!! These
are eagerly anticipated patches. As I did not study computer science and
computer architecture, I won''t be able to write those patches you guys
at Intel wrote.
I applied the following patches
xen-gfx-passthrough.patch<http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin>
and
qemu-gfx-passthrough.patch<http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin>
to xen 3.5-unstable without issues.
Then I tried to apply the 3rd patch you provided at
http://lists.xensource.com/archives/html/xen-devel/2009-08/msg01047.html
I saved the following code
<CODE>
diff -r 494be76c1ad9 tools/firmware/hvmloader/Makefile
--- a/tools/firmware/hvmloader/Makefile Thu Aug 27 16:54:33 2009 +0800
+++ b/tools/firmware/hvmloader/Makefile Thu Aug 27 17:22:01 2009 +0800
@@ -50,6 +50,7 @@ roms.h: ../rombios/BIOS-bochs-latest ../
roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \
../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h
sh ./mkhex rombios ../rombios/BIOS-bochs-latest > roms.h
+ sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin >> roms.h
sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin >> roms.h
sh ./mkhex vgabios_cirrusvga \
../vgabios/VGABIOS-lgpl-latest.cirrus.bin >> roms.h
diff -r 494be76c1ad9 tools/firmware/hvmloader/hvmloader.c
--- a/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 16:54:33 2009 +0800
+++ b/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 17:23:00 2009 +0800
@@ -688,9 +688,9 @@ int main(void)
vgabios_sz = round_option_rom(sizeof(vgabios_stdvga));
break;
case VGA_pt:
- printf("Loading Gfx Video BIOS from 0xC0000 ...\n");
- vgabios_sz
- round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512);
+ printf("Loading Gfx Video BIOS from file ...\n");
+ memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt,
sizeof(vgabios_pt));
+ vgabios_sz = round_option_rom(sizeof(vgabios_pt));
break;
default:
printf("No emulated VGA adaptor ...\n");
</CODE>
as intel-gfx-passthru-patch-3.patch and then I tried to apply the patch to xen
3.5-unstable. I got errors. I think it''s because the 3rd patch you
provided is incomplete.
Here''s my patching process:
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name vgabios
./tools/firmware/vgabios
./.hg/store/data/tools/firmware/vgabios
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cp ~enming/vgabios-pt.bin
tools/firmware/vgabios/
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ls tools/firmware/vgabios/
biossums.c clext.c Makefile TODO vbe.h
vgabios.h vgatables.h
BUGS COPYING Notes vbe.c vbetables-gen.c
vgabios-pt.bin
ChangeLog dataseghack README vbe_display_api.txt vgabios.c
vgafonts.h
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# pwd
/usr/src/xen-unstable.hg-vgapt
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wget
http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin
--2009-08-28 23:18:21--
http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin
Resolving lists.xensource.com... 70.42.241.110
Connecting to lists.xensource.com|70.42.241.110|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 12565 (12K) [application/octet-stream]
Saving to: `bincPiiAf0QWg.bin''
100%[======================================================================>]
12,565 30.7K/s in 0.4s
2009-08-28 23:18:22 (30.7 KB/s) - `bincPiiAf0QWg.bin'' saved
[12565/12565]
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv bincPiiAf0QWg.bin
xen-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi xen-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch <
xen-gfx-passthrough.patch
can''t find file to patch at input line 4
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff -r 5d7e7a250267 tools/firmware/hvmloader/config.h
|--- a/tools/firmware/hvmloader/config.h Wed Aug 26 18:28:44 2009 +0800
|+++ b/tools/firmware/hvmloader/config.h Thu Aug 27 16:54:24 2009 +0800
--------------------------
File to patch: ^C
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ex xen-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1 <
xen-gfx-passthrough.patch
patching file tools/firmware/hvmloader/config.h
patching file tools/firmware/hvmloader/hvmloader.c
patching file tools/libxc/ia64/xc_ia64_hvm_build.c
patching file tools/libxc/xc_hvm_build.c
patching file tools/libxc/xc_linux.c
patching file tools/libxc/xenctrl.h
patching file tools/libxc/xenguest.h
patching file tools/python/xen/lowlevel/xc/xc.c
patching file tools/python/xen/xend/XendConfig.py
Hunk #1 succeeded at 174 (offset -1 lines).
patching file tools/python/xen/xend/image.py
Hunk #1 succeeded at 780 (offset -6 lines).
Hunk #3 succeeded at 895 (offset -6 lines).
patching file tools/python/xen/xm/create.py
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wget
http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin
--2009-08-28 23:21:35--
http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin
Resolving lists.xensource.com... 70.42.241.110
Connecting to lists.xensource.com|70.42.241.110|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9841 (9.6K) [application/octet-stream]
Saving to: `binglLqkeq4Rj.bin''
100%[======================================================================>]
9,841 24.3K/s in 0.4s
2009-08-28 23:21:36 (24.3 KB/s) - `binglLqkeq4Rj.bin'' saved [9841/9841]
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv binglLqkeq4Rj.bin
qemu-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi qemu-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name hw
./tools/ioemu-remote/hw
./.hg/store/data/tools/ioemu/hw
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv qemu-gfx-passthrough.patch
tools/ioemu-remote/
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cd tools/ioemu-remote/
[root@fedora11-x86-64-host ioemu-remote]# patch -p1 < qemu-
qemu-aio.h qemu-img.c qemu-sockets.c
qemu-binfmt-conf.sh qemu-img.texi qemu-tech.texi
qemu-char.c qemu-lock.h qemu-timer.h
qemu-char.h qemu-log.h qemu-tool.c
qemu-common.h qemu-malloc.c qemu-xen.h
qemu-doc.texi qemu-nbd.c
qemu-gfx-passthrough.patch qemu-nbd.texi
[root@fedora11-x86-64-host ioemu-remote]# patch -p1 <
qemu-gfx-passthrough.patch
patching file hw/pass-through.c
patching file hw/pass-through.h
patching file hw/pc.c
patching file vl.c
[root@fedora11-x86-64-host ioemu-remote]# cd ..
[root@fedora11-x86-64-host tools]# cd ..
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi
intel-gfx-passthru-patch-3.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1 <
intel-gfx-passthru-patch-3.patch
patching file tools/firmware/hvmloader/Makefile
Hunk #1 FAILED at 50.
1 out of 1 hunk FAILED -- saving rejects to file
tools/firmware/hvmloader/Makefile.rej
patching file tools/firmware/hvmloader/hvmloader.c
patch: **** malformed patch at line 24: sizeof(vgabios_pt));
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi
intel-gfx-passthru-patch-3.patch
For everybody''s convenience, I have attached
intel-gfx-passthru-patch-3.patch and the firmware for my nVidia GeForce 8400 GS
PCI Express x16 graphics card in this email.
Please help me complete intel-gfx-passthru-patch-3.patch as I really need it.
Thank you very much!!!
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
This patch supports basic gfx passthrough on QEMU:
- disable emulated VGA adpater if there is passthroughed gfx
- register/unregister legacy VGA I/O ports and MMIOs for passthroughed gfx
Signed-off-by: Ben Lin
<ben.y.lin@intel.com><mailto:ben.y.lin@intel.com>
Signed-off-by: Weidong Han
<weidong.han@intel.com><mailto:weidong.han@intel.com>
No virus found in this incoming message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 8.5.409 / Virus Database: 270.13.69/2328 - Release Date: 08/27/09
18:02:00
No virus found in this outgoing message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 8.5.409 / Virus Database: 270.13.71/2330 - Release Date: 08/27/09
18:02:00
________________________________
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com<mailto: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
> If you want to make it work, you will need a card that works without the 1:1 mapping and is more friendly to virtualisation.Or to do your own board initialisation code for a cheap board - there is sufficient code in the Linux nvidia fb driver and/or the Nouveau codebase for that for a fair number of boards. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tim Moore
2009-Aug-28 16:22 UTC
RE: [Xen-devel] [PATCH(es)] graphics passthrough with VT-d
Thanks for the steer Alan, it would be ok for limited support and testing but I don''t think it would be supportable to maintain Xen specific board initialisation code especially when the DomU is HVM running Windows OS .. you would want to use the Nvidia shipped drivers.. -----Original Message----- From: Alan Cox [mailto:alan@lxorguk.ukuu.org.uk] Sent: 28 August 2009 17:20 To: Tim Moore Cc: ''enming.teo@asiasoftsea.net''; xen-devel@lists.xensource.com Subject: Re: [Xen-devel] [PATCH(es)] graphics passthrough with VT-d> If you want to make it work, you will need a card that works without the 1:1 mapping and is more friendly to virtualisation.Or to do your own board initialisation code for a cheap board - there is sufficient code in the Linux nvidia fb driver and/or the Nouveau codebase for that for a fair number of boards. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mr. Teo En Ming (Zhang Enming)
2009-Aug-28 16:28 UTC
Re: [Xen-devel] [PATCH(es)] graphics passthrough with VT-d
Dear Tim, I am using onboard Intel GMA 4500 for my Dom 0 and nVidia Geforce 8400 GS for passthrough to Windows XP HVM domU. I believe the VGA BIOS in the physical memory region 0xC0000 to 0xC7FFF is the vga bios of onboard Intel graphics, and not my Geforce 8400 GS. Hence I would need to extract out the firmware file for my Geforce 8400 GS card. As for nvidia professional graphics cards, they are too expensive for me for home use. -- Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) Technical Support Engineer Information Technology Department Asiasoft Online Pte Ltd Tampines Central 1 #04-01 Tampines Plaza Singapore 529541 Republic of Singapore Mobile: +65-9648-9798 MSN: teoenming@hotmail.com Alma Maters: Singapore Polytechnic, National University of Singapore On 08/29/2009 12:10 AM, Tim Moore wrote:> > Teo, > > It looks like the patches that Wiedong has supplied already copy the > VGA bios from the card and re-execute it within the DomU, therefore > there should be no need to load it from a file. > > I think you will have trouble for 2 reasons: > > 1) Bios re-execution, these Nvidia cards do not like having the BIOS > re-executed (from memcpy or file) > > 2) the Base Address Registers (BARs) will require 1:1 mappings to the > real addresses, which these patches dont cater for > > If you want to make it work, you will need a card that works without > the 1:1 mapping and is more friendly to virtualisation. > > ie: > > http://www.nvidia.com/object/sli_multi_os.html > > (as Andrew Lyon describes) > > Dual Quadro FX 5800, 4800, and 3800 professional graphics boards > > Tm > > *From:* xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] *On Behalf Of *Mr. Teo > En Ming (Zhang Enming) > *Sent:* 28 August 2009 16:55 > *To:* weidong.han@intel.com > *Cc:* xen-devel@lists.xensource.com; ''Lin, Ben Y''; ''Kay, Allen M''; > ''Jean Guyader''; Keir.Fraser@eu.citrix.com; bengheng@eecs.umich.edu > *Subject:* Re: [Xen-devel] [PATCH 2/2] graphics passthrough with VT-d > > Dear Weidong, > > A big big thanks for the vga passthrough patches for xen > 3.5-unstable!!! These are eagerly anticipated patches. As I did not > study computer science and computer architecture, I won''t be able to > write those patches you guys at Intel wrote. > > I applied the following patches *xen-gfx-passthrough.patch > <http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin> > and qemu-gfx-passthrough.patch > <http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin> > to xen 3.5-unstable without issues.* > > Then I tried to apply the 3rd patch you provided at > http://lists.xensource.com/archives/html/xen-devel/2009-08/msg01047.html > > I saved the following code > > <CODE> > > diff -r 494be76c1ad9 tools/firmware/hvmloader/Makefile > --- a/tools/firmware/hvmloader/Makefile Thu Aug 27 16:54:33 2009 +0800 > +++ b/tools/firmware/hvmloader/Makefile Thu Aug 27 17:22:01 2009 +0800 > @@ -50,6 +50,7 @@ roms.h: ../rombios/BIOS-bochs-latest ../ > roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \ > ../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h > sh ./mkhex rombios ../rombios/BIOS-bochs-latest> roms.h > + sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin>> roms.h > sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin>> roms.h > sh ./mkhex vgabios_cirrusvga \ > ../vgabios/VGABIOS-lgpl-latest.cirrus.bin>> roms.h > diff -r 494be76c1ad9 tools/firmware/hvmloader/hvmloader.c > --- a/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 16:54:33 2009 +0800 > +++ b/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 17:23:00 2009 +0800 > @@ -688,9 +688,9 @@ int main(void) > vgabios_sz = round_option_rom(sizeof(vgabios_stdvga)); > break; > case VGA_pt: > - printf("Loading Gfx Video BIOS from 0xC0000 ...\n"); > - vgabios_sz > - round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512); > + printf("Loading Gfx Video BIOS from file ...\n"); > + memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt, > sizeof(vgabios_pt)); > + vgabios_sz = round_option_rom(sizeof(vgabios_pt)); > break; > default: > printf("No emulated VGA adaptor ...\n"); > </CODE> > > as intel-gfx-passthru-patch-3.patch and then I tried to apply the patch to xen 3.5-unstable. I got errors. I think it''s because the 3rd patch you provided is incomplete. > > Here''s my patching process: > > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name vgabios > ./tools/firmware/vgabios > ./.hg/store/data/tools/firmware/vgabios > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cp ~enming/vgabios-pt.bin tools/firmware/vgabios/ > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ls tools/firmware/vgabios/ > biossums.c clext.c Makefile TODO vbe.h vgabios.h vgatables.h > BUGS COPYING Notes vbe.c vbetables-gen.c vgabios-pt.bin > ChangeLog dataseghack README vbe_display_api.txt vgabios.c vgafonts.h > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# pwd > /usr/src/xen-unstable.hg-vgapt > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wgethttp://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin > --2009-08-28 23:18:21--http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin > Resolving lists.xensource.com... 70.42.241.110 > Connecting to lists.xensource.com|70.42.241.110|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 12565 (12K) [application/octet-stream] > Saving to: `bincPiiAf0QWg.bin'' > > 100%[======================================================================>] 12,565 30.7K/s in 0.4s > > 2009-08-28 23:18:22 (30.7 KB/s) - `bincPiiAf0QWg.bin'' saved [12565/12565] > > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv bincPiiAf0QWg.bin xen-gfx-passthrough.patch > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi xen-gfx-passthrough.patch > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch< xen-gfx-passthrough.patch > can''t find file to patch at input line 4 > Perhaps you should have used the -p or --strip option? > The text leading up to this was: > -------------------------- > |diff -r 5d7e7a250267 tools/firmware/hvmloader/config.h > |--- a/tools/firmware/hvmloader/config.h Wed Aug 26 18:28:44 2009 +0800 > |+++ b/tools/firmware/hvmloader/config.h Thu Aug 27 16:54:24 2009 +0800 > -------------------------- > File to patch: ^C > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ex xen-gfx-passthrough.patch > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1< xen-gfx-passthrough.patch > patching file tools/firmware/hvmloader/config.h > patching file tools/firmware/hvmloader/hvmloader.c > patching file tools/libxc/ia64/xc_ia64_hvm_build.c > patching file tools/libxc/xc_hvm_build.c > patching file tools/libxc/xc_linux.c > patching file tools/libxc/xenctrl.h > patching file tools/libxc/xenguest.h > patching file tools/python/xen/lowlevel/xc/xc.c > patching file tools/python/xen/xend/XendConfig.py > Hunk #1 succeeded at 174 (offset -1 lines). > patching file tools/python/xen/xend/image.py > Hunk #1 succeeded at 780 (offset -6 lines). > Hunk #3 succeeded at 895 (offset -6 lines). > patching file tools/python/xen/xm/create.py > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wgethttp://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin > --2009-08-28 23:21:35--http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin > Resolving lists.xensource.com... 70.42.241.110 > Connecting to lists.xensource.com|70.42.241.110|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 9841 (9.6K) [application/octet-stream] > Saving to: `binglLqkeq4Rj.bin'' > > 100%[======================================================================>] 9,841 24.3K/s in 0.4s > > 2009-08-28 23:21:36 (24.3 KB/s) - `binglLqkeq4Rj.bin'' saved [9841/9841] > > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv binglLqkeq4Rj.bin qemu-gfx-passthrough.patch > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi qemu-gfx-passthrough.patch > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name hw > ./tools/ioemu-remote/hw > ./.hg/store/data/tools/ioemu/hw > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv qemu-gfx-passthrough.patch tools/ioemu-remote/ > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cd tools/ioemu-remote/ > [root@fedora11-x86-64-host ioemu-remote]# patch -p1< qemu- > qemu-aio.h qemu-img.c qemu-sockets.c > qemu-binfmt-conf.sh qemu-img.texi qemu-tech.texi > qemu-char.c qemu-lock.h qemu-timer.h > qemu-char.h qemu-log.h qemu-tool.c > qemu-common.h qemu-malloc.c qemu-xen.h > qemu-doc.texi qemu-nbd.c > qemu-gfx-passthrough.patch qemu-nbd.texi > [root@fedora11-x86-64-host ioemu-remote]# patch -p1< qemu-gfx-passthrough.patch > patching file hw/pass-through.c > patching file hw/pass-through.h > patching file hw/pc.c > patching file vl.c > [root@fedora11-x86-64-host ioemu-remote]# cd .. > [root@fedora11-x86-64-host tools]# cd .. > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi intel-gfx-passthru-patch-3.patch > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1< intel-gfx-passthru-patch-3.patch > patching file tools/firmware/hvmloader/Makefile > Hunk #1 FAILED at 50. > 1 out of 1 hunk FAILED -- saving rejects to file tools/firmware/hvmloader/Makefile.rej > patching file tools/firmware/hvmloader/hvmloader.c > patch: **** malformed patch at line 24: sizeof(vgabios_pt)); > > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi intel-gfx-passthru-patch-3.patch > > For everybody''s convenience, I have attached intel-gfx-passthru-patch-3.patch and the firmware for my nVidia GeForce 8400 GS PCI Express x16 graphics card in this email. > > Please help me complete intel-gfx-passthru-patch-3.patch as I really need it. > > Thank you very much!!! > -- > Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) > Technical Support Engineer > Information Technology Department > Asiasoft Online Pte Ltd > Tampines Central 1 #04-01 Tampines Plaza > Singapore 529541 > Republic of Singapore > Mobile: +65-9648-9798 > MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> > Alma Maters: Singapore Polytechnic, National University of Singapore > > This patch supports basic gfx passthrough on QEMU: > > - disable emulated VGA adpater if there is passthroughed gfx > > - register/unregister legacy VGA I/O ports and MMIOs for passthroughed gfx > > > > Signed-off-by: Ben Lin<ben.y.lin@intel.com> <mailto:ben.y.lin@intel.com> > > Signed-off-by: Weidong Han<weidong.han@intel.com> <mailto:weidong.han@intel.com> > > No virus found in this incoming message. > > Checked by AVG -www.avg.com <http://www.avg.com> > > Version: 8.5.409 / Virus Database: 270.13.69/2328 - Release Date: 08/27/09 > > 18:02:00 > > > > No virus found in this outgoing message. > > Checked by AVG -www.avg.com <http://www.avg.com> > > Version: 8.5.409 / Virus Database: 270.13.71/2330 - Release Date: 08/27/09 > > 18:02:00 > > > > > > ------------------------------------------------------------------------ > > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com <mailto: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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mr. Teo En Ming (Zhang Enming)
2009-Aug-28 16:31 UTC
Re: [Xen-devel] [PATCH(es)] graphics passthrough with VT-d
I believe Weidong mentioned he will release 1:1 mapping patches in a future date. Let''s hope he will release it tomorrow. :-) -- Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) Technical Support Engineer Information Technology Department Asiasoft Online Pte Ltd Tampines Central 1 #04-01 Tampines Plaza Singapore 529541 Republic of Singapore Mobile: +65-9648-9798 MSN: teoenming@hotmail.com Alma Maters: Singapore Polytechnic, National University of Singapore On 08/29/2009 12:28 AM, Mr. Teo En Ming (Zhang Enming) wrote:> Dear Tim, > > I am using onboard Intel GMA 4500 for my Dom 0 and nVidia Geforce 8400 > GS for passthrough to Windows XP HVM domU. > > I believe the VGA BIOS in the physical memory region 0xC0000 to > 0xC7FFF is the vga bios of onboard Intel graphics, and not my Geforce > 8400 GS. Hence I would need to extract out the firmware file for my > Geforce 8400 GS card. > > As for nvidia professional graphics cards, they are too expensive for > me for home use. > > -- > Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) > Technical Support Engineer > Information Technology Department > Asiasoft Online Pte Ltd > Tampines Central 1 #04-01 Tampines Plaza > Singapore 529541 > Republic of Singapore > Mobile: +65-9648-9798 > MSN:teoenming@hotmail.com > Alma Maters: Singapore Polytechnic, National University of Singapore > > > On 08/29/2009 12:10 AM, Tim Moore wrote: >> >> Teo, >> >> It looks like the patches that Wiedong has supplied already copy the >> VGA bios from the card and re-execute it within the DomU, therefore >> there should be no need to load it from a file. >> >> I think you will have trouble for 2 reasons: >> >> 1) Bios re-execution, these Nvidia cards do not like having the BIOS >> re-executed (from memcpy or file) >> >> 2) the Base Address Registers (BARs) will require 1:1 mappings to the >> real addresses, which these patches dont cater for >> >> If you want to make it work, you will need a card that works without >> the 1:1 mapping and is more friendly to virtualisation. >> >> ie: >> >> http://www.nvidia.com/object/sli_multi_os.html >> >> (as Andrew Lyon describes) >> >> Dual Quadro FX 5800, 4800, and 3800 professional graphics boards >> >> Tm >> >> *From:* xen-devel-bounces@lists.xensource.com >> [mailto:xen-devel-bounces@lists.xensource.com] *On Behalf Of *Mr. Teo >> En Ming (Zhang Enming) >> *Sent:* 28 August 2009 16:55 >> *To:* weidong.han@intel.com >> *Cc:* xen-devel@lists.xensource.com; ''Lin, Ben Y''; ''Kay, Allen M''; >> ''Jean Guyader''; Keir.Fraser@eu.citrix.com; bengheng@eecs.umich.edu >> *Subject:* Re: [Xen-devel] [PATCH 2/2] graphics passthrough with VT-d >> >> Dear Weidong, >> >> A big big thanks for the vga passthrough patches for xen >> 3.5-unstable!!! These are eagerly anticipated patches. As I did not >> study computer science and computer architecture, I won''t be able to >> write those patches you guys at Intel wrote. >> >> I applied the following patches *xen-gfx-passthrough.patch >> <http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin> >> and qemu-gfx-passthrough.patch >> <http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin> >> to xen 3.5-unstable without issues.* >> >> Then I tried to apply the 3rd patch you provided at >> http://lists.xensource.com/archives/html/xen-devel/2009-08/msg01047.html >> >> I saved the following code >> >> <CODE> >> >> diff -r 494be76c1ad9 tools/firmware/hvmloader/Makefile >> --- a/tools/firmware/hvmloader/Makefile Thu Aug 27 16:54:33 2009 +0800 >> +++ b/tools/firmware/hvmloader/Makefile Thu Aug 27 17:22:01 2009 +0800 >> @@ -50,6 +50,7 @@ roms.h: ../rombios/BIOS-bochs-latest ../ >> roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \ >> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h >> sh ./mkhex rombios ../rombios/BIOS-bochs-latest> roms.h >> + sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin>> roms.h >> sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin>> roms.h >> sh ./mkhex vgabios_cirrusvga \ >> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin>> roms.h >> diff -r 494be76c1ad9 tools/firmware/hvmloader/hvmloader.c >> --- a/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 16:54:33 2009 +0800 >> +++ b/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 17:23:00 2009 +0800 >> @@ -688,9 +688,9 @@ int main(void) >> vgabios_sz = round_option_rom(sizeof(vgabios_stdvga)); >> break; >> case VGA_pt: >> - printf("Loading Gfx Video BIOS from 0xC0000 ...\n"); >> - vgabios_sz >> - round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512); >> + printf("Loading Gfx Video BIOS from file ...\n"); >> + memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt, >> sizeof(vgabios_pt)); >> + vgabios_sz = round_option_rom(sizeof(vgabios_pt)); >> break; >> default: >> printf("No emulated VGA adaptor ...\n"); >> </CODE> >> >> as intel-gfx-passthru-patch-3.patch and then I tried to apply the patch to xen 3.5-unstable. I got errors. I think it''s because the 3rd patch you provided is incomplete. >> >> Here''s my patching process: >> >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name vgabios >> ./tools/firmware/vgabios >> ./.hg/store/data/tools/firmware/vgabios >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cp ~enming/vgabios-pt.bin tools/firmware/vgabios/ >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ls tools/firmware/vgabios/ >> biossums.c clext.c Makefile TODO vbe.h vgabios.h vgatables.h >> BUGS COPYING Notes vbe.c vbetables-gen.c vgabios-pt.bin >> ChangeLog dataseghack README vbe_display_api.txt vgabios.c vgafonts.h >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# pwd >> /usr/src/xen-unstable.hg-vgapt >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wgethttp://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin >> --2009-08-28 23:18:21--http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin >> Resolving lists.xensource.com... 70.42.241.110 >> Connecting to lists.xensource.com|70.42.241.110|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 12565 (12K) [application/octet-stream] >> Saving to: `bincPiiAf0QWg.bin'' >> >> 100%[======================================================================>] 12,565 30.7K/s in 0.4s >> >> 2009-08-28 23:18:22 (30.7 KB/s) - `bincPiiAf0QWg.bin'' saved [12565/12565] >> >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv bincPiiAf0QWg.bin xen-gfx-passthrough.patch >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi xen-gfx-passthrough.patch >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch< xen-gfx-passthrough.patch >> can''t find file to patch at input line 4 >> Perhaps you should have used the -p or --strip option? >> The text leading up to this was: >> -------------------------- >> |diff -r 5d7e7a250267 tools/firmware/hvmloader/config.h >> |--- a/tools/firmware/hvmloader/config.h Wed Aug 26 18:28:44 2009 +0800 >> |+++ b/tools/firmware/hvmloader/config.h Thu Aug 27 16:54:24 2009 +0800 >> -------------------------- >> File to patch: ^C >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ex xen-gfx-passthrough.patch >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1< xen-gfx-passthrough.patch >> patching file tools/firmware/hvmloader/config.h >> patching file tools/firmware/hvmloader/hvmloader.c >> patching file tools/libxc/ia64/xc_ia64_hvm_build.c >> patching file tools/libxc/xc_hvm_build.c >> patching file tools/libxc/xc_linux.c >> patching file tools/libxc/xenctrl.h >> patching file tools/libxc/xenguest.h >> patching file tools/python/xen/lowlevel/xc/xc.c >> patching file tools/python/xen/xend/XendConfig.py >> Hunk #1 succeeded at 174 (offset -1 lines). >> patching file tools/python/xen/xend/image.py >> Hunk #1 succeeded at 780 (offset -6 lines). >> Hunk #3 succeeded at 895 (offset -6 lines). >> patching file tools/python/xen/xm/create.py >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wgethttp://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin >> --2009-08-28 23:21:35--http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin >> Resolving lists.xensource.com... 70.42.241.110 >> Connecting to lists.xensource.com|70.42.241.110|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 9841 (9.6K) [application/octet-stream] >> Saving to: `binglLqkeq4Rj.bin'' >> >> 100%[======================================================================>] 9,841 24.3K/s in 0.4s >> >> 2009-08-28 23:21:36 (24.3 KB/s) - `binglLqkeq4Rj.bin'' saved [9841/9841] >> >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv binglLqkeq4Rj.bin qemu-gfx-passthrough.patch >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi qemu-gfx-passthrough.patch >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name hw >> ./tools/ioemu-remote/hw >> ./.hg/store/data/tools/ioemu/hw >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv qemu-gfx-passthrough.patch tools/ioemu-remote/ >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cd tools/ioemu-remote/ >> [root@fedora11-x86-64-host ioemu-remote]# patch -p1< qemu- >> qemu-aio.h qemu-img.c qemu-sockets.c >> qemu-binfmt-conf.sh qemu-img.texi qemu-tech.texi >> qemu-char.c qemu-lock.h qemu-timer.h >> qemu-char.h qemu-log.h qemu-tool.c >> qemu-common.h qemu-malloc.c qemu-xen.h >> qemu-doc.texi qemu-nbd.c >> qemu-gfx-passthrough.patch qemu-nbd.texi >> [root@fedora11-x86-64-host ioemu-remote]# patch -p1< qemu-gfx-passthrough.patch >> patching file hw/pass-through.c >> patching file hw/pass-through.h >> patching file hw/pc.c >> patching file vl.c >> [root@fedora11-x86-64-host ioemu-remote]# cd .. >> [root@fedora11-x86-64-host tools]# cd .. >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi intel-gfx-passthru-patch-3.patch >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1< intel-gfx-passthru-patch-3.patch >> patching file tools/firmware/hvmloader/Makefile >> Hunk #1 FAILED at 50. >> 1 out of 1 hunk FAILED -- saving rejects to file tools/firmware/hvmloader/Makefile.rej >> patching file tools/firmware/hvmloader/hvmloader.c >> patch: **** malformed patch at line 24: sizeof(vgabios_pt)); >> >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi intel-gfx-passthru-patch-3.patch >> >> For everybody''s convenience, I have attached intel-gfx-passthru-patch-3.patch and the firmware for my nVidia GeForce 8400 GS PCI Express x16 graphics card in this email. >> >> Please help me complete intel-gfx-passthru-patch-3.patch as I really need it. >> >> Thank you very much!!! >> -- >> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >> Technical Support Engineer >> Information Technology Department >> Asiasoft Online Pte Ltd >> Tampines Central 1 #04-01 Tampines Plaza >> Singapore 529541 >> Republic of Singapore >> Mobile: +65-9648-9798 >> MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> >> Alma Maters: Singapore Polytechnic, National University of Singapore >> >> This patch supports basic gfx passthrough on QEMU: >> >> - disable emulated VGA adpater if there is passthroughed gfx >> >> - register/unregister legacy VGA I/O ports and MMIOs for passthroughed gfx >> >> >> >> Signed-off-by: Ben Lin<ben.y.lin@intel.com> <mailto:ben.y.lin@intel.com> >> >> Signed-off-by: Weidong Han<weidong.han@intel.com> <mailto:weidong.han@intel.com> >> >> No virus found in this incoming message. >> >> Checked by AVG -www.avg.com <http://www.avg.com> >> >> Version: 8.5.409 / Virus Database: 270.13.69/2328 - Release Date: 08/27/09 >> >> 18:02:00 >> >> >> >> No virus found in this outgoing message. >> >> Checked by AVG -www.avg.com <http://www.avg.com> >> >> Version: 8.5.409 / Virus Database: 270.13.71/2330 - Release Date: 08/27/09 >> >> 18:02:00 >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> >> >> >> >> >> _______________________________________________ >> >> Xen-devel mailing list >> >> Xen-devel@lists.xensource.com <mailto: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 >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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
> I believe the VGA BIOS in the physical memory region 0xC0000 to 0xC7FFF > is the vga bios of onboard Intel graphics, and not my Geforce 8400 GS.If that was your boot video device. To extract the video BIOS for the Nvidia you either need to map it and read it out or boot with the Nvidia as the boot video device to acquire it and then switch back. That ought to work. Alan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mr. Teo En Ming (Zhang Enming)
2009-Aug-28 16:39 UTC
Re: [Xen-devel] [PATCH(es)] graphics passthrough with VT-d
Dear Alan, When I extracted the vga bios for my nvidia geforce 8400 gs, i went into BIOS to set PEG as the primary video adapter. Then I booted using nvidia gfx and extracted the vga bios using nvflash.exe. I believe it is possible to use a hex editor to examine the vga firmware file to see if it''s the vga bios for nvidia. -- Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) Technical Support Engineer Information Technology Department Asiasoft Online Pte Ltd Tampines Central 1 #04-01 Tampines Plaza Singapore 529541 Republic of Singapore Mobile: +65-9648-9798 MSN: teoenming@hotmail.com Alma Maters: Singapore Polytechnic, National University of Singapore On 08/29/2009 12:36 AM, Alan Cox wrote:>> I believe the VGA BIOS in the physical memory region 0xC0000 to 0xC7FFF >> is the vga bios of onboard Intel graphics, and not my Geforce 8400 GS. >> > If that was your boot video device. To extract the video BIOS for the > Nvidia you either need to map it and read it out or boot with the Nvidia > as the boot video device to acquire it and then switch back. That ought > to work. > > Alan >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mr. Teo En Ming (Zhang Enming)
2009-Aug-28 16:59 UTC
Re: [Xen-devel] [PATCH 2/2] graphics passthrough with VT-d
OK I believe the 3rd patch is not incomplete but there''s a white space issue when I copied the code from the mailing list into my vi. See http://www.htdig.org/mail/2000/11/0167.html When I used the -l flag to patch using the 3rd patch, the number of errors was reduced. [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -l -p1< intel-gfx-passthru-patch-3.patch patching file tools/firmware/hvmloader/Makefile patching file tools/firmware/hvmloader/hvmloader.c Hunk #1 FAILED at 688. 1 out of 1 hunk FAILED -- saving rejects to file tools/firmware/hvmloader/hvmloader.c.rej Now patching tools/firmware/hvmloader/Makefile is successful but patching tools/firmware/hvmloader/hvmloader.c still failed. -- Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) Technical Support Engineer Information Technology Department Asiasoft Online Pte Ltd Tampines Central 1 #04-01 Tampines Plaza Singapore 529541 Republic of Singapore Mobile: +65-9648-9798 MSN: teoenming@hotmail.com Alma Maters: Singapore Polytechnic, National University of Singapore On 08/28/2009 11:55 PM, Mr. Teo En Ming (Zhang Enming) wrote:> Dear Weidong, > > A big big thanks for the vga passthrough patches for xen > 3.5-unstable!!! These are eagerly anticipated patches. As I did not > study computer science and computer architecture, I won''t be able to > write those patches you guys at Intel wrote. > > I applied the following patches *xen-gfx-passthrough.patch > <http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin> > and **qemu-gfx-passthrough.patch > <http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin> > to xen 3.5-unstable without issues.* > > Then I tried to apply the 3rd patch you provided at > http://lists.xensource.com/archives/html/xen-devel/2009-08/msg01047.html > > I saved the following code > > <CODE> > diff -r 494be76c1ad9 tools/firmware/hvmloader/Makefile > --- a/tools/firmware/hvmloader/Makefile Thu Aug 27 16:54:33 2009 +0800 > +++ b/tools/firmware/hvmloader/Makefile Thu Aug 27 17:22:01 2009 +0800 > @@ -50,6 +50,7 @@ roms.h: ../rombios/BIOS-bochs-latest ../ > roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \ > ../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h > sh ./mkhex rombios ../rombios/BIOS-bochs-latest> roms.h > + sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin>> roms.h > sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin>> roms.h > sh ./mkhex vgabios_cirrusvga \ > ../vgabios/VGABIOS-lgpl-latest.cirrus.bin>> roms.h > diff -r 494be76c1ad9 tools/firmware/hvmloader/hvmloader.c > --- a/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 16:54:33 2009 +0800 > +++ b/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 17:23:00 2009 +0800 > @@ -688,9 +688,9 @@ int main(void) > vgabios_sz = round_option_rom(sizeof(vgabios_stdvga)); > break; > case VGA_pt: > - printf("Loading Gfx Video BIOS from 0xC0000 ...\n"); > - vgabios_sz > - round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512); > + printf("Loading Gfx Video BIOS from file ...\n"); > + memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt, > sizeof(vgabios_pt)); > + vgabios_sz = round_option_rom(sizeof(vgabios_pt)); > break; > default: > printf("No emulated VGA adaptor ...\n"); > > </CODE> > > as intel-gfx-passthru-patch-3.patch and then I tried to apply the patch to xen 3.5-unstable. I got errors. I think it''s because the 3rd patch you provided is incomplete. > > Here''s my patching process: > > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name vgabios > ./tools/firmware/vgabios > ./.hg/store/data/tools/firmware/vgabios > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cp ~enming/vgabios-pt.bin tools/firmware/vgabios/ > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ls tools/firmware/vgabios/ > biossums.c clext.c Makefile TODO vbe.h vgabios.h vgatables.h > BUGS COPYING Notes vbe.c vbetables-gen.c vgabios-pt.bin > ChangeLog dataseghack README vbe_display_api.txt vgabios.c vgafonts.h > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# pwd > /usr/src/xen-unstable.hg-vgapt > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wgethttp://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin > --2009-08-28 23:18:21--http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin > Resolving lists.xensource.com... 70.42.241.110 > Connecting to lists.xensource.com|70.42.241.110|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 12565 (12K) [application/octet-stream] > Saving to: `bincPiiAf0QWg.bin'' > > 100%[======================================================================>] 12,565 30.7K/s in 0.4s > > 2009-08-28 23:18:22 (30.7 KB/s) - `bincPiiAf0QWg.bin'' saved [12565/12565] > > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv bincPiiAf0QWg.bin xen-gfx-passthrough.patch > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi xen-gfx-passthrough.patch > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch< xen-gfx-passthrough.patch > can''t find file to patch at input line 4 > Perhaps you should have used the -p or --strip option? > The text leading up to this was: > -------------------------- > |diff -r 5d7e7a250267 tools/firmware/hvmloader/config.h > |--- a/tools/firmware/hvmloader/config.h Wed Aug 26 18:28:44 2009 +0800 > |+++ b/tools/firmware/hvmloader/config.h Thu Aug 27 16:54:24 2009 +0800 > -------------------------- > File to patch: ^C > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ex xen-gfx-passthrough.patch > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1< xen-gfx-passthrough.patch > patching file tools/firmware/hvmloader/config.h > patching file tools/firmware/hvmloader/hvmloader.c > patching file tools/libxc/ia64/xc_ia64_hvm_build.c > patching file tools/libxc/xc_hvm_build.c > patching file tools/libxc/xc_linux.c > patching file tools/libxc/xenctrl.h > patching file tools/libxc/xenguest.h > patching file tools/python/xen/lowlevel/xc/xc.c > patching file tools/python/xen/xend/XendConfig.py > Hunk #1 succeeded at 174 (offset -1 lines). > patching file tools/python/xen/xend/image.py > Hunk #1 succeeded at 780 (offset -6 lines). > Hunk #3 succeeded at 895 (offset -6 lines). > patching file tools/python/xen/xm/create.py > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wgethttp://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin > --2009-08-28 23:21:35--http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin > Resolving lists.xensource.com... 70.42.241.110 > Connecting to lists.xensource.com|70.42.241.110|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 9841 (9.6K) [application/octet-stream] > Saving to: `binglLqkeq4Rj.bin'' > > 100%[======================================================================>] 9,841 24.3K/s in 0.4s > > 2009-08-28 23:21:36 (24.3 KB/s) - `binglLqkeq4Rj.bin'' saved [9841/9841] > > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv binglLqkeq4Rj.bin qemu-gfx-passthrough.patch > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi qemu-gfx-passthrough.patch > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name hw > ./tools/ioemu-remote/hw > ./.hg/store/data/tools/ioemu/hw > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv qemu-gfx-passthrough.patch tools/ioemu-remote/ > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cd tools/ioemu-remote/ > [root@fedora11-x86-64-host ioemu-remote]# patch -p1< qemu- > qemu-aio.h qemu-img.c qemu-sockets.c > qemu-binfmt-conf.sh qemu-img.texi qemu-tech.texi > qemu-char.c qemu-lock.h qemu-timer.h > qemu-char.h qemu-log.h qemu-tool.c > qemu-common.h qemu-malloc.c qemu-xen.h > qemu-doc.texi qemu-nbd.c > qemu-gfx-passthrough.patch qemu-nbd.texi > [root@fedora11-x86-64-host ioemu-remote]# patch -p1< qemu-gfx-passthrough.patch > patching file hw/pass-through.c > patching file hw/pass-through.h > patching file hw/pc.c > patching file vl.c > [root@fedora11-x86-64-host ioemu-remote]# cd .. > [root@fedora11-x86-64-host tools]# cd .. > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi intel-gfx-passthru-patch-3.patch > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1< intel-gfx-passthru-patch-3.patch > patching file tools/firmware/hvmloader/Makefile > Hunk #1 FAILED at 50. > 1 out of 1 hunk FAILED -- saving rejects to file tools/firmware/hvmloader/Makefile.rej > patching file tools/firmware/hvmloader/hvmloader.c > patch: **** malformed patch at line 24: sizeof(vgabios_pt)); > > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi intel-gfx-passthru-patch-3.patch > > For everybody''s convenience, I have attached intel-gfx-passthru-patch-3.patch and the firmware for my nVidia GeForce 8400 GS PCI Express x16 graphics card in this email. > > Please help me complete intel-gfx-passthru-patch-3.patch as I really need it. > > Thank you very much!!! > > -- > Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) > Technical Support Engineer > Information Technology Department > Asiasoft Online Pte Ltd > Tampines Central 1 #04-01 Tampines Plaza > Singapore 529541 > Republic of Singapore > Mobile: +65-9648-9798 > MSN:teoenming@hotmail.com > Alma Maters: Singapore Polytechnic, National University of Singapore >> This patch supports basic gfx passthrough on QEMU: >> - disable emulated VGA adpater if there is passthroughed gfx >> - register/unregister legacy VGA I/O ports and MMIOs for passthroughed gfx >> >> Signed-off-by: Ben Lin<ben.y.lin@intel.com> >> Signed-off-by: Weidong Han<weidong.han@intel.com> >> No virus found in this incoming message. >> Checked by AVG -www.avg.com >> Version: 8.5.409 / Virus Database: 270.13.69/2328 - Release Date: 08/27/09 >> 18:02:00 >> >> No virus found in this outgoing message. >> Checked by AVG -www.avg.com >> Version: 8.5.409 / Virus Database: 270.13.71/2330 - Release Date: 08/27/09 >> 18:02:00 >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> 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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mr. Teo En Ming (Zhang Enming)
2009-Aug-28 20:13 UTC
Re: [Xen-devel] [PATCH 2/2] graphics passthrough with VT-d
After applying the 1st and 2nd patch to xen-unstable successfully, I examined
the source codes Makefile and hvmloader.c in tools/firmware/hvmloader, compared
them to Weidong''s 3rd patch and I generated my own 3rd patch. Then I
used my own generated 3rd patch to apply patching for loading vga bios from
firmware file.
Here is my own generated 3rd patch instead of using Weidong''s 3rd
patch:
--- Makefile 2009-08-29 03:24:52.413083774 +0800
+++ Makefile 2009-08-29 03:29:12.763299633 +0800
@@ -50,6 +50,7 @@
roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \
../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h
sh ./mkhex rombios ../rombios/BIOS-bochs-latest> roms.h
+ sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin>> roms.h
sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin>>
roms.h
sh ./mkhex vgabios_cirrusvga \
../vgabios/VGABIOS-lgpl-latest.cirrus.bin>> roms.h
--- hvmloader.c 2009-08-29 03:26:06.911085797 +0800
+++ hvmloader.c 2009-08-29 03:31:43.172084995 +0800
@@ -688,9 +688,9 @@
vgabios_sz = round_option_rom(sizeof(vgabios_stdvga));
break;
case VGA_pt:
- printf("Loading VGABIOS of passthroughed gfx ...\n");
- vgabios_sz - round_option_rom((*(uint8_t
*)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512);
+ printf("Loading Gfx Video BIOS from file ...\n");
+ memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt,
sizeof(vgabios_pt));
+ vgabios_sz = round_option_rom(sizeof(vgabios_pt));
break;
default:
printf("No emulated VGA adaptor ...\n");
I can "make xen" successfully but when I proceeded to "make
tools", errors were encountered.
Please see attached error output. How can I solve this problem?
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 12:59 AM, Mr. Teo En Ming (Zhang Enming)
wrote:> OK I believe the 3rd patch is not incomplete but there''s a white
space issue when I copied the code from the mailing list into my vi.
>
> Seehttp://www.htdig.org/mail/2000/11/0167.html
>
> When I used the -l flag to patch using the 3rd patch, the number of errors
was reduced.
>
> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -l -p1<
intel-gfx-passthru-patch-3.patch
> patching file tools/firmware/hvmloader/Makefile
> patching file tools/firmware/hvmloader/hvmloader.c
> Hunk #1 FAILED at 688.
> 1 out of 1 hunk FAILED -- saving rejects to file
tools/firmware/hvmloader/hvmloader.c.rej
>
> Now patching tools/firmware/hvmloader/Makefile is successful but patching
tools/firmware/hvmloader/hvmloader.c still failed.
>
> --
> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
> Technical Support Engineer
> Information Technology Department
> Asiasoft Online Pte Ltd
> Tampines Central 1 #04-01 Tampines Plaza
> Singapore 529541
> Republic of Singapore
> Mobile: +65-9648-9798
> MSN:teoenming@hotmail.com
> Alma Maters: Singapore Polytechnic, National University of Singapore
>
>
>
> On 08/28/2009 11:55 PM, Mr. Teo En Ming (Zhang Enming) wrote:
>> Dear Weidong,
>>
>> A big big thanks for the vga passthrough patches for xen
>> 3.5-unstable!!! These are eagerly anticipated patches. As I did not
>> study computer science and computer architecture, I won''t be
able to
>> write those patches you guys at Intel wrote.
>>
>> I applied the following patches *xen-gfx-passthrough.patch
>>
<http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin>
>> and **qemu-gfx-passthrough.patch
>>
<http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin>
>> to xen 3.5-unstable without issues.*
>>
>> Then I tried to apply the 3rd patch you provided at
>>
http://lists.xensource.com/archives/html/xen-devel/2009-08/msg01047.html
>>
>> I saved the following code
>>
>> <CODE>
>> diff -r 494be76c1ad9 tools/firmware/hvmloader/Makefile
>> --- a/tools/firmware/hvmloader/Makefile Thu Aug 27 16:54:33 2009 +0800
>> +++ b/tools/firmware/hvmloader/Makefile Thu Aug 27 17:22:01 2009 +0800
>> @@ -50,6 +50,7 @@ roms.h: ../rombios/BIOS-bochs-latest ../
>> roms.h: ../rombios/BIOS-bochs-latest
../vgabios/VGABIOS-lgpl-latest.bin \
>> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h
>> sh ./mkhex rombios ../rombios/BIOS-bochs-latest> roms.h
>> + sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin>> roms.h
>> sh ./mkhex vgabios_stdvga
../vgabios/VGABIOS-lgpl-latest.bin>> roms.h
>> sh ./mkhex vgabios_cirrusvga \
>> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin>> roms.h
>> diff -r 494be76c1ad9 tools/firmware/hvmloader/hvmloader.c
>> --- a/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 16:54:33 2009
+0800
>> +++ b/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 17:23:00 2009
+0800
>> @@ -688,9 +688,9 @@ int main(void)
>> vgabios_sz = round_option_rom(sizeof(vgabios_stdvga));
>> break;
>> case VGA_pt:
>> - printf("Loading Gfx Video BIOS from 0xC0000 ...\n");
>> - vgabios_sz >> - round_option_rom((*(uint8_t
*)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512);
>> + printf("Loading Gfx Video BIOS from file ...\n");
>> + memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt,
>> sizeof(vgabios_pt));
>> + vgabios_sz = round_option_rom(sizeof(vgabios_pt));
>> break;
>> default:
>> printf("No emulated VGA adaptor ...\n");
>>
>> </CODE>
>>
>> as intel-gfx-passthru-patch-3.patch and then I tried to apply the patch
to xen 3.5-unstable. I got errors. I think it''s because the 3rd patch
you provided is incomplete.
>>
>> Here''s my patching process:
>>
>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name vgabios
>> ./tools/firmware/vgabios
>> ./.hg/store/data/tools/firmware/vgabios
>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cp
~enming/vgabios-pt.bin tools/firmware/vgabios/
>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ls
tools/firmware/vgabios/
>> biossums.c clext.c Makefile TODO vbe.h
vgabios.h vgatables.h
>> BUGS COPYING Notes vbe.c vbetables-gen.c
vgabios-pt.bin
>> ChangeLog dataseghack README vbe_display_api.txt vgabios.c
vgafonts.h
>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# pwd
>> /usr/src/xen-unstable.hg-vgapt
>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]#
wgethttp://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin
>> --2009-08-28
23:18:21--http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin
>> Resolving lists.xensource.com... 70.42.241.110
>> Connecting to lists.xensource.com|70.42.241.110|:80... connected.
>> HTTP request sent, awaiting response... 200 OK
>> Length: 12565 (12K) [application/octet-stream]
>> Saving to: `bincPiiAf0QWg.bin''
>>
>>
100%[======================================================================>]
12,565 30.7K/s in 0.4s
>>
>> 2009-08-28 23:18:22 (30.7 KB/s) - `bincPiiAf0QWg.bin'' saved
[12565/12565]
>>
>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv bincPiiAf0QWg.bin
xen-gfx-passthrough.patch
>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi
xen-gfx-passthrough.patch
>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch<
xen-gfx-passthrough.patch
>> can''t find file to patch at input line 4
>> Perhaps you should have used the -p or --strip option?
>> The text leading up to this was:
>> --------------------------
>> |diff -r 5d7e7a250267 tools/firmware/hvmloader/config.h
>> |--- a/tools/firmware/hvmloader/config.h Wed Aug 26 18:28:44 2009 +0800
>> |+++ b/tools/firmware/hvmloader/config.h Thu Aug 27 16:54:24 2009 +0800
>> --------------------------
>> File to patch: ^C
>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ex
xen-gfx-passthrough.patch
>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1<
xen-gfx-passthrough.patch
>> patching file tools/firmware/hvmloader/config.h
>> patching file tools/firmware/hvmloader/hvmloader.c
>> patching file tools/libxc/ia64/xc_ia64_hvm_build.c
>> patching file tools/libxc/xc_hvm_build.c
>> patching file tools/libxc/xc_linux.c
>> patching file tools/libxc/xenctrl.h
>> patching file tools/libxc/xenguest.h
>> patching file tools/python/xen/lowlevel/xc/xc.c
>> patching file tools/python/xen/xend/XendConfig.py
>> Hunk #1 succeeded at 174 (offset -1 lines).
>> patching file tools/python/xen/xend/image.py
>> Hunk #1 succeeded at 780 (offset -6 lines).
>> Hunk #3 succeeded at 895 (offset -6 lines).
>> patching file tools/python/xen/xm/create.py
>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]#
wgethttp://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin
>> --2009-08-28
23:21:35--http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin
>> Resolving lists.xensource.com... 70.42.241.110
>> Connecting to lists.xensource.com|70.42.241.110|:80... connected.
>> HTTP request sent, awaiting response... 200 OK
>> Length: 9841 (9.6K) [application/octet-stream]
>> Saving to: `binglLqkeq4Rj.bin''
>>
>>
100%[======================================================================>]
9,841 24.3K/s in 0.4s
>>
>> 2009-08-28 23:21:36 (24.3 KB/s) - `binglLqkeq4Rj.bin'' saved
[9841/9841]
>>
>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv binglLqkeq4Rj.bin
qemu-gfx-passthrough.patch
>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi
qemu-gfx-passthrough.patch
>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name hw
>> ./tools/ioemu-remote/hw
>> ./.hg/store/data/tools/ioemu/hw
>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv
qemu-gfx-passthrough.patch tools/ioemu-remote/
>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cd
tools/ioemu-remote/
>> [root@fedora11-x86-64-host ioemu-remote]# patch -p1< qemu-
>> qemu-aio.h qemu-img.c qemu-sockets.c
>> qemu-binfmt-conf.sh qemu-img.texi qemu-tech.texi
>> qemu-char.c qemu-lock.h qemu-timer.h
>> qemu-char.h qemu-log.h qemu-tool.c
>> qemu-common.h qemu-malloc.c qemu-xen.h
>> qemu-doc.texi qemu-nbd.c
>> qemu-gfx-passthrough.patch qemu-nbd.texi
>> [root@fedora11-x86-64-host ioemu-remote]# patch -p1<
qemu-gfx-passthrough.patch
>> patching file hw/pass-through.c
>> patching file hw/pass-through.h
>> patching file hw/pc.c
>> patching file vl.c
>> [root@fedora11-x86-64-host ioemu-remote]# cd ..
>> [root@fedora11-x86-64-host tools]# cd ..
>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi
intel-gfx-passthru-patch-3.patch
>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1<
intel-gfx-passthru-patch-3.patch
>> patching file tools/firmware/hvmloader/Makefile
>> Hunk #1 FAILED at 50.
>> 1 out of 1 hunk FAILED -- saving rejects to file
tools/firmware/hvmloader/Makefile.rej
>> patching file tools/firmware/hvmloader/hvmloader.c
>> patch: **** malformed patch at line 24: sizeof(vgabios_pt));
>>
>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi
intel-gfx-passthru-patch-3.patch
>>
>> For everybody''s convenience, I have attached
intel-gfx-passthru-patch-3.patch and the firmware for my nVidia GeForce 8400 GS
PCI Express x16 graphics card in this email.
>>
>> Please help me complete intel-gfx-passthru-patch-3.patch as I really
need it.
>>
>> Thank you very much!!!
>>
>> --
>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
>> Technical Support Engineer
>> Information Technology Department
>> Asiasoft Online Pte Ltd
>> Tampines Central 1 #04-01 Tampines Plaza
>> Singapore 529541
>> Republic of Singapore
>> Mobile: +65-9648-9798
>> MSN:teoenming@hotmail.com
>> Alma Maters: Singapore Polytechnic, National University of Singapore
>>> This patch supports basic gfx passthrough on QEMU:
>>> - disable emulated VGA adpater if there is passthroughed gfx
>>> - register/unregister legacy VGA I/O ports and MMIOs for
passthroughed gfx
>>>
>>> Signed-off-by: Ben Lin<ben.y.lin@intel.com>
>>> Signed-off-by: Weidong Han<weidong.han@intel.com>
>>> No virus found in this incoming message.
>>> Checked by AVG -www.avg.com
>>> Version: 8.5.409 / Virus Database: 270.13.69/2328 - Release Date:
08/27/09
>>> 18:02:00
>>>
>>> No virus found in this outgoing message.
>>> Checked by AVG -www.avg.com
>>> Version: 8.5.409 / Virus Database: 270.13.71/2330 - Release Date:
08/27/09
>>> 18:02:00
>>>
>>>
------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> 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
>>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Teo,
I have also performed the same exercise as yourself and I now have successfully
compiled all 3x patches into Xen, Qemu and the BIOS File Loading in the
hvmloader, this all compiles find on my system. Suggest you do a "make
clean" on the tools and start again !
After booting with the patched xen-unstable and adding the gfx-passthru=1
parameter to my HVM DomU, as I suspected - it still doesn''t work.
I have both a 9500GT and GTX260(primary) in my Intel DX58SO machine, tried
passing through either device and my primary display locks up ! (included hiding
with pci-stub)
I verified that the DomU was functional beforehand, as It also booted
successfully without the gfx-passthru parameter (and a vncviewer/cirrus display)
Unfortunately, I can''t debug further as my Primary display corrupts as
soon as the DomU starts. I did notice that in "xm debug" the
"Loading Gfx BIOS File.." message was displayed and the DomU did
continue to initialise the BIOS tables and such before finally locking. I then
(blindly) typed on a corrupt Dom0 console and managed to start kdm and login, so
the Dom0 was not completely trashed. But then after a few minutes, the machine
totally froze and had to hit the reset switch.
I`m no specialist but this looks like the VGA BIOS Re-initialisation is playing
havoc with the DomU and possibly the Dom0 graphics. I notice that both are also
using IRQ11 which could play a major part. Furthermore, there was a lot of debug
output in the qemu and xend.log indicating Base Address Register invalid access
and therefore it seems there may be a second obstacle.
Hope you have a better success than me !
For now, I would try re-compiling a fresh xen-unstable with carefully applied
patches .. oh! and don''t forget to enable the pci-stub driver for Dom0
(it''s not selected by default)
Tim
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Mr. Teo En Ming
(Zhang Enming)
Sent: 28 August 2009 21:14
To: enming.teo@asiasoftsea.net
Cc: xen-devel@lists.xensource.com; ''Lin, Ben Y'';
''Kay, Allen M''; ''Jean Guyader'';
Keir.Fraser@eu.citrix.com; weidong.han@intel.com; bengheng@eecs.umich.edu
Subject: Re: [Xen-devel] [PATCH 2/2] graphics passthrough with VT-d
After applying the 1st and 2nd patch to xen-unstable successfully, I examined
the source codes Makefile and hvmloader.c in tools/firmware/hvmloader, compared
them to Weidong''s 3rd patch and I generated my own 3rd patch. Then I
used my own generated 3rd patch to apply patching for loading vga bios from
firmware file.
Here is my own generated 3rd patch instead of using Weidong''s 3rd
patch:
--- Makefile 2009-08-29 03:24:52.413083774 +0800
+++ Makefile 2009-08-29 03:29:12.763299633 +0800
@@ -50,6 +50,7 @@
roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \
../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h
sh ./mkhex rombios ../rombios/BIOS-bochs-latest > roms.h
+ sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin >> roms.h
sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin >>
roms.h
sh ./mkhex vgabios_cirrusvga \
../vgabios/VGABIOS-lgpl-latest.cirrus.bin >> roms.h
--- hvmloader.c 2009-08-29 03:26:06.911085797 +0800
+++ hvmloader.c 2009-08-29 03:31:43.172084995 +0800
@@ -688,9 +688,9 @@
vgabios_sz = round_option_rom(sizeof(vgabios_stdvga));
break;
case VGA_pt:
- printf("Loading VGABIOS of passthroughed gfx ...\n");
- vgabios_sz
- round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512);
+ printf("Loading Gfx Video BIOS from file ...\n");
+ memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt,
sizeof(vgabios_pt));
+ vgabios_sz = round_option_rom(sizeof(vgabios_pt));
break;
default:
printf("No emulated VGA adaptor ...\n");
I can "make xen" successfully but when I proceeded to "make
tools", errors were encountered.
Please see attached error output. How can I solve this problem?
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 12:59 AM, Mr. Teo En Ming (Zhang Enming) wrote:
OK I believe the 3rd patch is not incomplete but there''s a white space
issue when I copied the code from the mailing list into my vi.
See http://www.htdig.org/mail/2000/11/0167.html
When I used the -l flag to patch using the 3rd patch, the number of errors was
reduced.
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -l -p1 <
intel-gfx-passthru-patch-3.patch
patching file tools/firmware/hvmloader/Makefile
patching file tools/firmware/hvmloader/hvmloader.c
Hunk #1 FAILED at 688.
1 out of 1 hunk FAILED -- saving rejects to file
tools/firmware/hvmloader/hvmloader.c.rej
Now patching tools/firmware/hvmloader/Makefile is successful but patching
tools/firmware/hvmloader/hvmloader.c still failed.
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/28/2009 11:55 PM, Mr. Teo En Ming (Zhang Enming) wrote:
Dear Weidong,
A big big thanks for the vga passthrough patches for xen 3.5-unstable!!! These
are eagerly anticipated patches. As I did not study computer science and
computer architecture, I won''t be able to write those patches you guys
at Intel wrote.
I applied the following patches
xen-gfx-passthrough.patch<http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin>
and
qemu-gfx-passthrough.patch<http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin>
to xen 3.5-unstable without issues.
Then I tried to apply the 3rd patch you provided at
http://lists.xensource.com/archives/html/xen-devel/2009-08/msg01047.html
I saved the following code
<CODE>
diff -r 494be76c1ad9 tools/firmware/hvmloader/Makefile
--- a/tools/firmware/hvmloader/Makefile Thu Aug 27 16:54:33 2009 +0800
+++ b/tools/firmware/hvmloader/Makefile Thu Aug 27 17:22:01 2009 +0800
@@ -50,6 +50,7 @@ roms.h: ../rombios/BIOS-bochs-latest ../
roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \
../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h
sh ./mkhex rombios ../rombios/BIOS-bochs-latest > roms.h
+ sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin >> roms.h
sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin >> roms.h
sh ./mkhex vgabios_cirrusvga \
../vgabios/VGABIOS-lgpl-latest.cirrus.bin >> roms.h
diff -r 494be76c1ad9 tools/firmware/hvmloader/hvmloader.c
--- a/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 16:54:33 2009 +0800
+++ b/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 17:23:00 2009 +0800
@@ -688,9 +688,9 @@ int main(void)
vgabios_sz = round_option_rom(sizeof(vgabios_stdvga));
break;
case VGA_pt:
- printf("Loading Gfx Video BIOS from 0xC0000 ...\n");
- vgabios_sz
- round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512);
+ printf("Loading Gfx Video BIOS from file ...\n");
+ memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt,
sizeof(vgabios_pt));
+ vgabios_sz = round_option_rom(sizeof(vgabios_pt));
break;
default:
printf("No emulated VGA adaptor ...\n");
</CODE>
as intel-gfx-passthru-patch-3.patch and then I tried to apply the patch to xen
3.5-unstable. I got errors. I think it''s because the 3rd patch you
provided is incomplete.
Here''s my patching process:
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name vgabios
./tools/firmware/vgabios
./.hg/store/data/tools/firmware/vgabios
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cp ~enming/vgabios-pt.bin
tools/firmware/vgabios/
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ls tools/firmware/vgabios/
biossums.c clext.c Makefile TODO vbe.h
vgabios.h vgatables.h
BUGS COPYING Notes vbe.c vbetables-gen.c
vgabios-pt.bin
ChangeLog dataseghack README vbe_display_api.txt vgabios.c
vgafonts.h
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# pwd
/usr/src/xen-unstable.hg-vgapt
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wget
http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin
--2009-08-28 23:18:21--
http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin
Resolving lists.xensource.com... 70.42.241.110
Connecting to lists.xensource.com|70.42.241.110|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 12565 (12K) [application/octet-stream]
Saving to: `bincPiiAf0QWg.bin''
100%[======================================================================>]
12,565 30.7K/s in 0.4s
2009-08-28 23:18:22 (30.7 KB/s) - `bincPiiAf0QWg.bin'' saved
[12565/12565]
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv bincPiiAf0QWg.bin
xen-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi xen-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch <
xen-gfx-passthrough.patch
can''t find file to patch at input line 4
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff -r 5d7e7a250267 tools/firmware/hvmloader/config.h
|--- a/tools/firmware/hvmloader/config.h Wed Aug 26 18:28:44 2009 +0800
|+++ b/tools/firmware/hvmloader/config.h Thu Aug 27 16:54:24 2009 +0800
--------------------------
File to patch: ^C
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ex xen-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1 <
xen-gfx-passthrough.patch
patching file tools/firmware/hvmloader/config.h
patching file tools/firmware/hvmloader/hvmloader.c
patching file tools/libxc/ia64/xc_ia64_hvm_build.c
patching file tools/libxc/xc_hvm_build.c
patching file tools/libxc/xc_linux.c
patching file tools/libxc/xenctrl.h
patching file tools/libxc/xenguest.h
patching file tools/python/xen/lowlevel/xc/xc.c
patching file tools/python/xen/xend/XendConfig.py
Hunk #1 succeeded at 174 (offset -1 lines).
patching file tools/python/xen/xend/image.py
Hunk #1 succeeded at 780 (offset -6 lines).
Hunk #3 succeeded at 895 (offset -6 lines).
patching file tools/python/xen/xm/create.py
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wget
http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin
--2009-08-28 23:21:35--
http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin
Resolving lists.xensource.com... 70.42.241.110
Connecting to lists.xensource.com|70.42.241.110|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9841 (9.6K) [application/octet-stream]
Saving to: `binglLqkeq4Rj.bin''
100%[======================================================================>]
9,841 24.3K/s in 0.4s
2009-08-28 23:21:36 (24.3 KB/s) - `binglLqkeq4Rj.bin'' saved [9841/9841]
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv binglLqkeq4Rj.bin
qemu-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi qemu-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name hw
./tools/ioemu-remote/hw
./.hg/store/data/tools/ioemu/hw
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv qemu-gfx-passthrough.patch
tools/ioemu-remote/
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cd tools/ioemu-remote/
[root@fedora11-x86-64-host ioemu-remote]# patch -p1 < qemu-
qemu-aio.h qemu-img.c qemu-sockets.c
qemu-binfmt-conf.sh qemu-img.texi qemu-tech.texi
qemu-char.c qemu-lock.h qemu-timer.h
qemu-char.h qemu-log.h qemu-tool.c
qemu-common.h qemu-malloc.c qemu-xen.h
qemu-doc.texi qemu-nbd.c
qemu-gfx-passthrough.patch qemu-nbd.texi
[root@fedora11-x86-64-host ioemu-remote]# patch -p1 <
qemu-gfx-passthrough.patch
patching file hw/pass-through.c
patching file hw/pass-through.h
patching file hw/pc.c
patching file vl.c
[root@fedora11-x86-64-host ioemu-remote]# cd ..
[root@fedora11-x86-64-host tools]# cd ..
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi
intel-gfx-passthru-patch-3.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1 <
intel-gfx-passthru-patch-3.patch
patching file tools/firmware/hvmloader/Makefile
Hunk #1 FAILED at 50.
1 out of 1 hunk FAILED -- saving rejects to file
tools/firmware/hvmloader/Makefile.rej
patching file tools/firmware/hvmloader/hvmloader.c
patch: **** malformed patch at line 24: sizeof(vgabios_pt));
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi
intel-gfx-passthru-patch-3.patch
For everybody''s convenience, I have attached
intel-gfx-passthru-patch-3.patch and the firmware for my nVidia GeForce 8400 GS
PCI Express x16 graphics card in this email.
Please help me complete intel-gfx-passthru-patch-3.patch as I really need it.
Thank you very much!!!
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
This patch supports basic gfx passthrough on QEMU:
- disable emulated VGA adpater if there is passthroughed gfx
- register/unregister legacy VGA I/O ports and MMIOs for passthroughed gfx
Signed-off-by: Ben Lin
<ben.y.lin@intel.com><mailto:ben.y.lin@intel.com>
Signed-off-by: Weidong Han
<weidong.han@intel.com><mailto:weidong.han@intel.com>
No virus found in this incoming message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 8.5.409 / Virus Database: 270.13.69/2328 - Release Date: 08/27/09
18:02:00
No virus found in this outgoing message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 8.5.409 / Virus Database: 270.13.71/2330 - Release Date: 08/27/09
18:02:00
________________________________
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com<mailto:Xen-devel@lists.xensource.com>
http://lists.xensource.com/xen-devel
________________________________
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com<mailto: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
Mr. Teo En Ming (Zhang Enming)
2009-Aug-29 02:17 UTC
Re: [Xen-devel] graphics passthrough with VT-d
Hi Tim, I thought it should be gfx_passthru=2 in domU config? -- Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) Technical Support Engineer Information Technology Department Asiasoft Online Pte Ltd Tampines Central 1 #04-01 Tampines Plaza Singapore 529541 Republic of Singapore Mobile: +65-9648-9798 MSN: teoenming@hotmail.com Alma Maters: Singapore Polytechnic, National University of Singapore On 08/29/2009 06:42 AM, Tim Moore wrote:> > Teo, > > I have also performed the same exercise as yourself and I now have > successfully compiled all 3x patches into Xen, Qemu and the BIOS File > Loading in the hvmloader, this all compiles find on my system. Suggest > you do a "make clean" on the tools and start again ! > > After booting with the patched xen-unstable and adding the > gfx-passthru=1 parameter to my HVM DomU, as I suspected - it still > doesn''t work. > > I have both a 9500GT and GTX260(primary) in my Intel DX58SO machine, > tried passing through either device and my primary display locks up ! > (included hiding with pci-stub) > > I verified that the DomU was functional beforehand, as It also booted > successfully without the gfx-passthru parameter (and a > vncviewer/cirrus display) > > Unfortunately, I can''t debug further as my Primary display corrupts as > soon as the DomU starts. I did notice that in "xm debug" the "Loading > Gfx BIOS File.." message was displayed and the DomU did continue to > initialise the BIOS tables and such before finally locking. I then > (blindly) typed on a corrupt Dom0 console and managed to start kdm and > login, so the Dom0 was not completely trashed. But then after a few > minutes, the machine totally froze and had to hit the reset switch. > > I`m no specialist but this looks like the VGA BIOS Re-initialisation > is playing havoc with the DomU and possibly the Dom0 graphics. I > notice that both are also using IRQ11 which could play a major part. > Furthermore, there was a lot of debug output in the qemu and xend.log > indicating Base Address Register invalid access and therefore it seems > there may be a second obstacle. > > Hope you have a better success than me ! > > For now, I would try re-compiling a fresh xen-unstable with carefully > applied patches .. oh! and don''t forget to enable the pci-stub driver > for Dom0 (it''s not selected by default) > > Tim > > *From:* xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] *On Behalf Of *Mr. Teo > En Ming (Zhang Enming) > *Sent:* 28 August 2009 21:14 > *To:* enming.teo@asiasoftsea.net > *Cc:* xen-devel@lists.xensource.com; ''Lin, Ben Y''; ''Kay, Allen M''; > ''Jean Guyader''; Keir.Fraser@eu.citrix.com; weidong.han@intel.com; > bengheng@eecs.umich.edu > *Subject:* Re: [Xen-devel] [PATCH 2/2] graphics passthrough with VT-d > > After applying the 1st and 2nd patch to xen-unstable successfully, I examined the source codes Makefile and hvmloader.c in tools/firmware/hvmloader, compared them to Weidong''s 3rd patch and I generated my own 3rd patch. Then I used my own generated 3rd patch to apply patching for loading vga bios from firmware file. > > Here is my own generated 3rd patch instead of using Weidong''s 3rd patch: > > --- Makefile 2009-08-29 03:24:52.413083774 +0800 > +++ Makefile 2009-08-29 03:29:12.763299633 +0800 > @@ -50,6 +50,7 @@ > roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \ > ../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h > sh ./mkhex rombios ../rombios/BIOS-bochs-latest> roms.h > + sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin>> roms.h > sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin>> roms.h > sh ./mkhex vgabios_cirrusvga \ > ../vgabios/VGABIOS-lgpl-latest.cirrus.bin>> roms.h > --- hvmloader.c 2009-08-29 03:26:06.911085797 +0800 > +++ hvmloader.c 2009-08-29 03:31:43.172084995 +0800 > @@ -688,9 +688,9 @@ > vgabios_sz = round_option_rom(sizeof(vgabios_stdvga)); > break; > case VGA_pt: > - printf("Loading VGABIOS of passthroughed gfx ...\n"); > - vgabios_sz > - round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512); > + printf("Loading Gfx Video BIOS from file ...\n"); > + memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt, sizeof(vgabios_pt)); > + vgabios_sz = round_option_rom(sizeof(vgabios_pt)); > break; > default: > printf("No emulated VGA adaptor ...\n"); > > > I can "make xen" successfully but when I proceeded to "make tools", errors were encountered. > > Please see attached error output. How can I solve this problem? > > > -- > Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) > Technical Support Engineer > Information Technology Department > Asiasoft Online Pte Ltd > Tampines Central 1 #04-01 Tampines Plaza > Singapore 529541 > Republic of Singapore > Mobile: +65-9648-9798 > MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> > Alma Maters: Singapore Polytechnic, National University of Singapore > > > > On 08/29/2009 12:59 AM, Mr. Teo En Ming (Zhang Enming) wrote: > > OK I believe the 3rd patch is not incomplete but there''s a white space issue when I copied the code from the mailing list into my vi. > > Seehttp://www.htdig.org/mail/2000/11/0167.html > > When I used the -l flag to patch using the 3rd patch, the number of errors was reduced. > > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -l -p1< intel-gfx-passthru-patch-3.patch > patching file tools/firmware/hvmloader/Makefile > patching file tools/firmware/hvmloader/hvmloader.c > Hunk #1 FAILED at 688. > 1 out of 1 hunk FAILED -- saving rejects to file tools/firmware/hvmloader/hvmloader.c.rej > > Now patching tools/firmware/hvmloader/Makefile is successful but patching tools/firmware/hvmloader/hvmloader.c still failed. > > -- > Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) > Technical Support Engineer > Information Technology Department > Asiasoft Online Pte Ltd > Tampines Central 1 #04-01 Tampines Plaza > Singapore 529541 > Republic of Singapore > Mobile: +65-9648-9798 > MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> > Alma Maters: Singapore Polytechnic, National University of Singapore > > > > > On 08/28/2009 11:55 PM, Mr. Teo En Ming (Zhang Enming) wrote: > > Dear Weidong, > > A big big thanks for the vga passthrough patches for xen > 3.5-unstable!!! These are eagerly anticipated patches. As I did not > study computer science and computer architecture, I won''t be able to > write those patches you guys at Intel wrote. > > I applied the following patches *xen-gfx-passthrough.patch > <http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin> > and qemu-gfx-passthrough.patch > <http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin> > to xen 3.5-unstable without issues.* > > Then I tried to apply the 3rd patch you provided at > http://lists.xensource.com/archives/html/xen-devel/2009-08/msg01047.html > > I saved the following code > > <CODE> > > diff -r 494be76c1ad9 tools/firmware/hvmloader/Makefile > --- a/tools/firmware/hvmloader/Makefile Thu Aug 27 16:54:33 2009 +0800 > +++ b/tools/firmware/hvmloader/Makefile Thu Aug 27 17:22:01 2009 +0800 > @@ -50,6 +50,7 @@ roms.h: ../rombios/BIOS-bochs-latest ../ > roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \ > ../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h > sh ./mkhex rombios ../rombios/BIOS-bochs-latest> roms.h > + sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin>> roms.h > sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin>> roms.h > sh ./mkhex vgabios_cirrusvga \ > ../vgabios/VGABIOS-lgpl-latest.cirrus.bin>> roms.h > diff -r 494be76c1ad9 tools/firmware/hvmloader/hvmloader.c > --- a/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 16:54:33 2009 +0800 > +++ b/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 17:23:00 2009 +0800 > @@ -688,9 +688,9 @@ int main(void) > vgabios_sz = round_option_rom(sizeof(vgabios_stdvga)); > break; > case VGA_pt: > - printf("Loading Gfx Video BIOS from 0xC0000 ...\n"); > - vgabios_sz > - round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512); > + printf("Loading Gfx Video BIOS from file ...\n"); > + memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt, > sizeof(vgabios_pt)); > + vgabios_sz = round_option_rom(sizeof(vgabios_pt)); > break; > default: > printf("No emulated VGA adaptor ...\n"); > > </CODE> > > as intel-gfx-passthru-patch-3.patch and then I tried to apply the patch to xen 3.5-unstable. I got errors. I think it''s because the 3rd patch you provided is incomplete. > > Here''s my patching process: > > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name vgabios > ./tools/firmware/vgabios > ./.hg/store/data/tools/firmware/vgabios > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cp ~enming/vgabios-pt.bin tools/firmware/vgabios/ > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ls tools/firmware/vgabios/ > biossums.c clext.c Makefile TODO vbe.h vgabios.h vgatables.h > BUGS COPYING Notes vbe.c vbetables-gen.c vgabios-pt.bin > ChangeLog dataseghack README vbe_display_api.txt vgabios.c vgafonts.h > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# pwd > /usr/src/xen-unstable.hg-vgapt > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wgethttp://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin > --2009-08-28 23:18:21--http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin > Resolving lists.xensource.com... 70.42.241.110 > Connecting to lists.xensource.com|70.42.241.110|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 12565 (12K) [application/octet-stream] > Saving to: `bincPiiAf0QWg.bin'' > > 100%[======================================================================>] 12,565 30.7K/s in 0.4s > > 2009-08-28 23:18:22 (30.7 KB/s) - `bincPiiAf0QWg.bin'' saved [12565/12565] > > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv bincPiiAf0QWg.bin xen-gfx-passthrough.patch > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi xen-gfx-passthrough.patch > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch< xen-gfx-passthrough.patch > can''t find file to patch at input line 4 > Perhaps you should have used the -p or --strip option? > The text leading up to this was: > -------------------------- > |diff -r 5d7e7a250267 tools/firmware/hvmloader/config.h > |--- a/tools/firmware/hvmloader/config.h Wed Aug 26 18:28:44 2009 +0800 > |+++ b/tools/firmware/hvmloader/config.h Thu Aug 27 16:54:24 2009 +0800 > -------------------------- > File to patch: ^C > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ex xen-gfx-passthrough.patch > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1< xen-gfx-passthrough.patch > patching file tools/firmware/hvmloader/config.h > patching file tools/firmware/hvmloader/hvmloader.c > patching file tools/libxc/ia64/xc_ia64_hvm_build.c > patching file tools/libxc/xc_hvm_build.c > patching file tools/libxc/xc_linux.c > patching file tools/libxc/xenctrl.h > patching file tools/libxc/xenguest.h > patching file tools/python/xen/lowlevel/xc/xc.c > patching file tools/python/xen/xend/XendConfig.py > Hunk #1 succeeded at 174 (offset -1 lines). > patching file tools/python/xen/xend/image.py > Hunk #1 succeeded at 780 (offset -6 lines). > Hunk #3 succeeded at 895 (offset -6 lines). > patching file tools/python/xen/xm/create.py > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wgethttp://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin > --2009-08-28 23:21:35--http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin > Resolving lists.xensource.com... 70.42.241.110 > Connecting to lists.xensource.com|70.42.241.110|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 9841 (9.6K) [application/octet-stream] > Saving to: `binglLqkeq4Rj.bin'' > > 100%[======================================================================>] 9,841 24.3K/s in 0.4s > > 2009-08-28 23:21:36 (24.3 KB/s) - `binglLqkeq4Rj.bin'' saved [9841/9841] > > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv binglLqkeq4Rj.bin qemu-gfx-passthrough.patch > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi qemu-gfx-passthrough.patch > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name hw > ./tools/ioemu-remote/hw > ./.hg/store/data/tools/ioemu/hw > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv qemu-gfx-passthrough.patch tools/ioemu-remote/ > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cd tools/ioemu-remote/ > [root@fedora11-x86-64-host ioemu-remote]# patch -p1< qemu- > qemu-aio.h qemu-img.c qemu-sockets.c > qemu-binfmt-conf.sh qemu-img.texi qemu-tech.texi > qemu-char.c qemu-lock.h qemu-timer.h > qemu-char.h qemu-log.h qemu-tool.c > qemu-common.h qemu-malloc.c qemu-xen.h > qemu-doc.texi qemu-nbd.c > qemu-gfx-passthrough.patch qemu-nbd.texi > [root@fedora11-x86-64-host ioemu-remote]# patch -p1< qemu-gfx-passthrough.patch > patching file hw/pass-through.c > patching file hw/pass-through.h > patching file hw/pc.c > patching file vl.c > [root@fedora11-x86-64-host ioemu-remote]# cd .. > [root@fedora11-x86-64-host tools]# cd .. > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi intel-gfx-passthru-patch-3.patch > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1< intel-gfx-passthru-patch-3.patch > patching file tools/firmware/hvmloader/Makefile > Hunk #1 FAILED at 50. > 1 out of 1 hunk FAILED -- saving rejects to file tools/firmware/hvmloader/Makefile.rej > patching file tools/firmware/hvmloader/hvmloader.c > patch: **** malformed patch at line 24: sizeof(vgabios_pt)); > > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi intel-gfx-passthru-patch-3.patch > > For everybody''s convenience, I have attached intel-gfx-passthru-patch-3.patch and the firmware for my nVidia GeForce 8400 GS PCI Express x16 graphics card in this email. > > Please help me complete intel-gfx-passthru-patch-3.patch as I really need it. > > Thank you very much!!! > > -- > Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) > Technical Support Engineer > Information Technology Department > Asiasoft Online Pte Ltd > Tampines Central 1 #04-01 Tampines Plaza > Singapore 529541 > Republic of Singapore > Mobile: +65-9648-9798 > MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> > Alma Maters: Singapore Polytechnic, National University of Singapore > > This patch supports basic gfx passthrough on QEMU: > > - disable emulated VGA adpater if there is passthroughed gfx > > - register/unregister legacy VGA I/O ports and MMIOs for passthroughed gfx > > > > Signed-off-by: Ben Lin<ben.y.lin@intel.com> <mailto:ben.y.lin@intel.com> > > Signed-off-by: Weidong Han<weidong.han@intel.com> <mailto:weidong.han@intel.com> > > No virus found in this incoming message. > > Checked by AVG -www.avg.com <http://www.avg.com> > > Version: 8.5.409 / Virus Database: 270.13.69/2328 - Release Date: 08/27/09 > > 18:02:00 > > > > No virus found in this outgoing message. > > Checked by AVG -www.avg.com <http://www.avg.com> > > Version: 8.5.409 / Virus Database: 270.13.71/2330 - Release Date: 08/27/09 > > 18:02:00 > > > > ------------------------------------------------------------------------ > > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com <mailto:Xen-devel@lists.xensource.com> > > http://lists.xensource.com/xen-devel > > > > > > ------------------------------------------------------------------------ > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com <mailto: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
Mr. Teo En Ming (Zhang Enming)
2009-Aug-29 03:48 UTC
Re: [Xen-devel] graphics passthrough with VT-d
Dear All, After applying Intel VGA passthrough patches 1, 2 and 3, I have no problems with "make xen", and "make install-xen". However, I have errors with "make tools". Here is the error output: msoft-float -I. -I.. -I../../../../tools/include -c -o build.o build.c build.c: In function ''construct_secondary_tables'': build.c:194: error: ''AmlCode_TPM'' undeclared (first use in this function) build.c:194: error: (Each undeclared identifier is reported only once build.c:194: error: for each function it appears in.) make[8]: *** [build.o] Error 1 make[8]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader/acpi'' make[7]: *** [subdir-all-acpi] Error 2 make[7]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader'' make[6]: *** [subdirs-all] Error 2 make[6]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader'' make[5]: *** [subdir-all-hvmloader] Error 2 make[5]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'' make[4]: *** [subdirs-all] Error 2 make[4]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'' make[3]: *** [all] Error 2 make[3]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'' make[2]: *** [subdir-install-firmware] Error 2 make[2]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools'' make[1]: *** [subdirs-install] Error 2 make[1]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools'' make: *** [install-tools] Error 2 There is an undeclared identifier in tools/firmware/hvmloader/acpi/build.c source code. Could you guys help me resolve this issue? I had no problems compiling xen 3.5-unstable before applying the Intel vga passthrough patches and before installing the Intel ACPI Component Architecture compiler. I have also attached Intel graphics passthrough patches 1, 2 and 3 for your convenience here. Thank you very much. Hope I can get this working during the weekends. -- Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) Technical Support Engineer Information Technology Department Asiasoft Online Pte Ltd Tampines Central 1 #04-01 Tampines Plaza Singapore 529541 Republic of Singapore Company Website: http://www.asiasoft.sg/ Mobile: +65-9648-9798 MSN: teoenming@hotmail.com Alma Maters: Singapore Polytechnic, National University of Singapore On 08/29/2009 10:17 AM, Mr. Teo En Ming (Zhang Enming) wrote:> Hi Tim, > > I thought it should be gfx_passthru=2 in domU config? > -- > Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) > Technical Support Engineer > Information Technology Department > Asiasoft Online Pte Ltd > Tampines Central 1 #04-01 Tampines Plaza > Singapore 529541 > Republic of Singapore > Mobile: +65-9648-9798 > MSN:teoenming@hotmail.com > Alma Maters: Singapore Polytechnic, National University of Singapore > > > On 08/29/2009 06:42 AM, Tim Moore wrote: >> >> Teo, >> >> I have also performed the same exercise as yourself and I now have >> successfully compiled all 3x patches into Xen, Qemu and the BIOS File >> Loading in the hvmloader, this all compiles find on my system. >> Suggest you do a "make clean" on the tools and start again ! >> >> After booting with the patched xen-unstable and adding the >> gfx-passthru=1 parameter to my HVM DomU, as I suspected - it still >> doesn''t work. >> >> I have both a 9500GT and GTX260(primary) in my Intel DX58SO machine, >> tried passing through either device and my primary display locks up ! >> (included hiding with pci-stub) >> >> I verified that the DomU was functional beforehand, as It also booted >> successfully without the gfx-passthru parameter (and a >> vncviewer/cirrus display) >> >> Unfortunately, I can''t debug further as my Primary display corrupts >> as soon as the DomU starts. I did notice that in "xm debug" the >> "Loading Gfx BIOS File.." message was displayed and the DomU did >> continue to initialise the BIOS tables and such before finally >> locking. I then (blindly) typed on a corrupt Dom0 console and managed >> to start kdm and login, so the Dom0 was not completely trashed. But >> then after a few minutes, the machine totally froze and had to hit >> the reset switch. >> >> I`m no specialist but this looks like the VGA BIOS Re-initialisation >> is playing havoc with the DomU and possibly the Dom0 graphics. I >> notice that both are also using IRQ11 which could play a major part. >> Furthermore, there was a lot of debug output in the qemu and xend.log >> indicating Base Address Register invalid access and therefore it >> seems there may be a second obstacle. >> >> Hope you have a better success than me ! >> >> For now, I would try re-compiling a fresh xen-unstable with carefully >> applied patches .. oh! and don''t forget to enable the pci-stub driver >> for Dom0 (it''s not selected by default) >> >> Tim >> >> *From:* xen-devel-bounces@lists.xensource.com >> [mailto:xen-devel-bounces@lists.xensource.com] *On Behalf Of *Mr. Teo >> En Ming (Zhang Enming) >> *Sent:* 28 August 2009 21:14 >> *To:* enming.teo@asiasoftsea.net >> *Cc:* xen-devel@lists.xensource.com; ''Lin, Ben Y''; ''Kay, Allen M''; >> ''Jean Guyader''; Keir.Fraser@eu.citrix.com; weidong.han@intel.com; >> bengheng@eecs.umich.edu >> *Subject:* Re: [Xen-devel] [PATCH 2/2] graphics passthrough with VT-d >> >> After applying the 1st and 2nd patch to xen-unstable successfully, I examined the source codes Makefile and hvmloader.c in tools/firmware/hvmloader, compared them to Weidong''s 3rd patch and I generated my own 3rd patch. Then I used my own generated 3rd patch to apply patching for loading vga bios from firmware file. >> >> Here is my own generated 3rd patch instead of using Weidong''s 3rd patch: >> >> --- Makefile 2009-08-29 03:24:52.413083774 +0800 >> +++ Makefile 2009-08-29 03:29:12.763299633 +0800 >> @@ -50,6 +50,7 @@ >> roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \ >> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h >> sh ./mkhex rombios ../rombios/BIOS-bochs-latest> roms.h >> + sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin>> roms.h >> sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin>> roms.h >> sh ./mkhex vgabios_cirrusvga \ >> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin>> roms.h >> --- hvmloader.c 2009-08-29 03:26:06.911085797 +0800 >> +++ hvmloader.c 2009-08-29 03:31:43.172084995 +0800 >> @@ -688,9 +688,9 @@ >> vgabios_sz = round_option_rom(sizeof(vgabios_stdvga)); >> break; >> case VGA_pt: >> - printf("Loading VGABIOS of passthroughed gfx ...\n"); >> - vgabios_sz >> - round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512); >> + printf("Loading Gfx Video BIOS from file ...\n"); >> + memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt, sizeof(vgabios_pt)); >> + vgabios_sz = round_option_rom(sizeof(vgabios_pt)); >> break; >> default: >> printf("No emulated VGA adaptor ...\n"); >> >> >> I can "make xen" successfully but when I proceeded to "make tools", errors were encountered. >> >> Please see attached error output. How can I solve this problem? >> >> >> -- >> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >> Technical Support Engineer >> Information Technology Department >> Asiasoft Online Pte Ltd >> Tampines Central 1 #04-01 Tampines Plaza >> Singapore 529541 >> Republic of Singapore >> Mobile: +65-9648-9798 >> MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> >> Alma Maters: Singapore Polytechnic, National University of Singapore >> >> >> >> On 08/29/2009 12:59 AM, Mr. Teo En Ming (Zhang Enming) wrote: >> >> OK I believe the 3rd patch is not incomplete but there''s a white space issue when I copied the code from the mailing list into my vi. >> >> Seehttp://www.htdig.org/mail/2000/11/0167.html >> >> When I used the -l flag to patch using the 3rd patch, the number of errors was reduced. >> >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -l -p1< intel-gfx-passthru-patch-3.patch >> patching file tools/firmware/hvmloader/Makefile >> patching file tools/firmware/hvmloader/hvmloader.c >> Hunk #1 FAILED at 688. >> 1 out of 1 hunk FAILED -- saving rejects to file tools/firmware/hvmloader/hvmloader.c.rej >> >> Now patching tools/firmware/hvmloader/Makefile is successful but patching tools/firmware/hvmloader/hvmloader.c still failed. >> >> -- >> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >> Technical Support Engineer >> Information Technology Department >> Asiasoft Online Pte Ltd >> Tampines Central 1 #04-01 Tampines Plaza >> Singapore 529541 >> Republic of Singapore >> Mobile: +65-9648-9798 >> MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> >> Alma Maters: Singapore Polytechnic, National University of Singapore >> >> >> >> >> On 08/28/2009 11:55 PM, Mr. Teo En Ming (Zhang Enming) wrote: >> >> Dear Weidong, >> >> A big big thanks for the vga passthrough patches for xen >> 3.5-unstable!!! These are eagerly anticipated patches. As I did not >> study computer science and computer architecture, I won''t be able to >> write those patches you guys at Intel wrote. >> >> I applied the following patches *xen-gfx-passthrough.patch >> <http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin> >> and qemu-gfx-passthrough.patch >> <http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin> >> to xen 3.5-unstable without issues.* >> >> Then I tried to apply the 3rd patch you provided at >> http://lists.xensource.com/archives/html/xen-devel/2009-08/msg01047.html >> >> I saved the following code >> >> <CODE> >> >> diff -r 494be76c1ad9 tools/firmware/hvmloader/Makefile >> --- a/tools/firmware/hvmloader/Makefile Thu Aug 27 16:54:33 2009 +0800 >> +++ b/tools/firmware/hvmloader/Makefile Thu Aug 27 17:22:01 2009 +0800 >> @@ -50,6 +50,7 @@ roms.h: ../rombios/BIOS-bochs-latest ../ >> roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \ >> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h >> sh ./mkhex rombios ../rombios/BIOS-bochs-latest> roms.h >> + sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin>> roms.h >> sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin>> roms.h >> sh ./mkhex vgabios_cirrusvga \ >> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin>> roms.h >> diff -r 494be76c1ad9 tools/firmware/hvmloader/hvmloader.c >> --- a/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 16:54:33 2009 +0800 >> +++ b/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 17:23:00 2009 +0800 >> @@ -688,9 +688,9 @@ int main(void) >> vgabios_sz = round_option_rom(sizeof(vgabios_stdvga)); >> break; >> case VGA_pt: >> - printf("Loading Gfx Video BIOS from 0xC0000 ...\n"); >> - vgabios_sz >> - round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512); >> + printf("Loading Gfx Video BIOS from file ...\n"); >> + memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt, >> sizeof(vgabios_pt)); >> + vgabios_sz = round_option_rom(sizeof(vgabios_pt)); >> break; >> default: >> printf("No emulated VGA adaptor ...\n"); >> >> </CODE> >> >> as intel-gfx-passthru-patch-3.patch and then I tried to apply the patch to xen 3.5-unstable. I got errors. I think it''s because the 3rd patch you provided is incomplete. >> >> Here''s my patching process: >> >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name vgabios >> ./tools/firmware/vgabios >> ./.hg/store/data/tools/firmware/vgabios >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cp ~enming/vgabios-pt.bin tools/firmware/vgabios/ >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ls tools/firmware/vgabios/ >> biossums.c clext.c Makefile TODO vbe.h vgabios.h vgatables.h >> BUGS COPYING Notes vbe.c vbetables-gen.c vgabios-pt.bin >> ChangeLog dataseghack README vbe_display_api.txt vgabios.c vgafonts.h >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# pwd >> /usr/src/xen-unstable.hg-vgapt >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wgethttp://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin >> --2009-08-28 23:18:21--http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin >> Resolving lists.xensource.com... 70.42.241.110 >> Connecting to lists.xensource.com|70.42.241.110|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 12565 (12K) [application/octet-stream] >> Saving to: `bincPiiAf0QWg.bin'' >> >> 100%[======================================================================>] 12,565 30.7K/s in 0.4s >> >> 2009-08-28 23:18:22 (30.7 KB/s) - `bincPiiAf0QWg.bin'' saved [12565/12565] >> >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv bincPiiAf0QWg.bin xen-gfx-passthrough.patch >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi xen-gfx-passthrough.patch >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch< xen-gfx-passthrough.patch >> can''t find file to patch at input line 4 >> Perhaps you should have used the -p or --strip option? >> The text leading up to this was: >> -------------------------- >> |diff -r 5d7e7a250267 tools/firmware/hvmloader/config.h >> |--- a/tools/firmware/hvmloader/config.h Wed Aug 26 18:28:44 2009 +0800 >> |+++ b/tools/firmware/hvmloader/config.h Thu Aug 27 16:54:24 2009 +0800 >> -------------------------- >> File to patch: ^C >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ex xen-gfx-passthrough.patch >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1< xen-gfx-passthrough.patch >> patching file tools/firmware/hvmloader/config.h >> patching file tools/firmware/hvmloader/hvmloader.c >> patching file tools/libxc/ia64/xc_ia64_hvm_build.c >> patching file tools/libxc/xc_hvm_build.c >> patching file tools/libxc/xc_linux.c >> patching file tools/libxc/xenctrl.h >> patching file tools/libxc/xenguest.h >> patching file tools/python/xen/lowlevel/xc/xc.c >> patching file tools/python/xen/xend/XendConfig.py >> Hunk #1 succeeded at 174 (offset -1 lines). >> patching file tools/python/xen/xend/image.py >> Hunk #1 succeeded at 780 (offset -6 lines). >> Hunk #3 succeeded at 895 (offset -6 lines). >> patching file tools/python/xen/xm/create.py >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wgethttp://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin >> --2009-08-28 23:21:35--http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin >> Resolving lists.xensource.com... 70.42.241.110 >> Connecting to lists.xensource.com|70.42.241.110|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 9841 (9.6K) [application/octet-stream] >> Saving to: `binglLqkeq4Rj.bin'' >> >> 100%[======================================================================>] 9,841 24.3K/s in 0.4s >> >> 2009-08-28 23:21:36 (24.3 KB/s) - `binglLqkeq4Rj.bin'' saved [9841/9841] >> >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv binglLqkeq4Rj.bin qemu-gfx-passthrough.patch >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi qemu-gfx-passthrough.patch >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name hw >> ./tools/ioemu-remote/hw >> ./.hg/store/data/tools/ioemu/hw >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv qemu-gfx-passthrough.patch tools/ioemu-remote/ >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cd tools/ioemu-remote/ >> [root@fedora11-x86-64-host ioemu-remote]# patch -p1< qemu- >> qemu-aio.h qemu-img.c qemu-sockets.c >> qemu-binfmt-conf.sh qemu-img.texi qemu-tech.texi >> qemu-char.c qemu-lock.h qemu-timer.h >> qemu-char.h qemu-log.h qemu-tool.c >> qemu-common.h qemu-malloc.c qemu-xen.h >> qemu-doc.texi qemu-nbd.c >> qemu-gfx-passthrough.patch qemu-nbd.texi >> [root@fedora11-x86-64-host ioemu-remote]# patch -p1< qemu-gfx-passthrough.patch >> patching file hw/pass-through.c >> patching file hw/pass-through.h >> patching file hw/pc.c >> patching file vl.c >> [root@fedora11-x86-64-host ioemu-remote]# cd .. >> [root@fedora11-x86-64-host tools]# cd .. >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi intel-gfx-passthru-patch-3.patch >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1< intel-gfx-passthru-patch-3.patch >> patching file tools/firmware/hvmloader/Makefile >> Hunk #1 FAILED at 50. >> 1 out of 1 hunk FAILED -- saving rejects to file tools/firmware/hvmloader/Makefile.rej >> patching file tools/firmware/hvmloader/hvmloader.c >> patch: **** malformed patch at line 24: sizeof(vgabios_pt)); >> >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi intel-gfx-passthru-patch-3.patch >> >> For everybody''s convenience, I have attached intel-gfx-passthru-patch-3.patch and the firmware for my nVidia GeForce 8400 GS PCI Express x16 graphics card in this email. >> >> Please help me complete intel-gfx-passthru-patch-3.patch as I really need it. >> >> Thank you very much!!! >> >> -- >> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >> Technical Support Engineer >> Information Technology Department >> Asiasoft Online Pte Ltd >> Tampines Central 1 #04-01 Tampines Plaza >> Singapore 529541 >> Republic of Singapore >> Mobile: +65-9648-9798 >> MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> >> Alma Maters: Singapore Polytechnic, National University of Singapore >> >> This patch supports basic gfx passthrough on QEMU: >> >> - disable emulated VGA adpater if there is passthroughed gfx >> >> - register/unregister legacy VGA I/O ports and MMIOs for passthroughed gfx >> >> >> >> Signed-off-by: Ben Lin<ben.y.lin@intel.com> <mailto:ben.y.lin@intel.com> >> >> Signed-off-by: Weidong Han<weidong.han@intel.com> <mailto:weidong.han@intel.com> >> >> No virus found in this incoming message. >> >> Checked by AVG -www.avg.com <http://www.avg.com> >> >> Version: 8.5.409 / Virus Database: 270.13.69/2328 - Release Date: 08/27/09 >> >> 18:02:00 >> >> >> >> No virus found in this outgoing message. >> >> Checked by AVG -www.avg.com <http://www.avg.com> >> >> Version: 8.5.409 / Virus Database: 270.13.71/2330 - Release Date: 08/27/09 >> >> 18:02:00 >> >> >> >> ------------------------------------------------------------------------ >> >> >> >> >> >> >> _______________________________________________ >> >> Xen-devel mailing list >> >> Xen-devel@lists.xensource.com <mailto:Xen-devel@lists.xensource.com> >> >> http://lists.xensource.com/xen-devel >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com <mailto: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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mr. Teo En Ming (Zhang Enming)
2009-Aug-29 06:58 UTC
Re: [Xen-devel] graphics passthrough with VT-d
Hi Anybody available today? I know it''s Saturday. :-) -- Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) Technical Support Engineer Information Technology Department Asiasoft Online Pte Ltd Tampines Central 1 #04-01 Tampines Plaza Singapore 529541 Republic of Singapore Company Website: http://www.asiasoft.sg/ Mobile: +65-9648-9798 MSN: teoenming@hotmail.com Alma Maters: Singapore Polytechnic, National University of Singapore On 08/29/2009 11:48 AM, Mr. Teo En Ming (Zhang Enming) wrote:> > Dear All, > > After applying Intel VGA passthrough patches 1, 2 and 3, I have no problems with "make xen", and "make install-xen". However, I have errors with "make tools". > > Here is the error output: > > msoft-float -I. -I.. -I../../../../tools/include -c -o build.o build.c > build.c: In function ''construct_secondary_tables'': > build.c:194: error: ''AmlCode_TPM'' undeclared (first use in this function) > build.c:194: error: (Each undeclared identifier is reported only once > build.c:194: error: for each function it appears in.) > make[8]: *** [build.o] Error 1 > make[8]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader/acpi'' > make[7]: *** [subdir-all-acpi] Error 2 > make[7]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader'' > make[6]: *** [subdirs-all] Error 2 > make[6]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader'' > make[5]: *** [subdir-all-hvmloader] Error 2 > make[5]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'' > make[4]: *** [subdirs-all] Error 2 > make[4]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'' > make[3]: *** [all] Error 2 > make[3]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'' > make[2]: *** [subdir-install-firmware] Error 2 > make[2]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools'' > make[1]: *** [subdirs-install] Error 2 > make[1]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools'' > make: *** [install-tools] Error 2 > > There is an undeclared identifier in tools/firmware/hvmloader/acpi/build.c source code. Could you guys help me resolve this issue? > > I had no problems compiling xen 3.5-unstable before applying the Intel vga passthrough patches and before installing the Intel ACPI Component Architecture compiler. > > I have also attached Intel graphics passthrough patches 1, 2 and 3 for your convenience here. > > Thank you very much. > > Hope I can get this working during the weekends. > > -- > Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) > Technical Support Engineer > Information Technology Department > Asiasoft Online Pte Ltd > Tampines Central 1 #04-01 Tampines Plaza > Singapore 529541 > Republic of Singapore > Company Website:http://www.asiasoft.sg/ > Mobile: +65-9648-9798 > MSN:teoenming@hotmail.com > Alma Maters: Singapore Polytechnic, National University of Singapore > > > On 08/29/2009 10:17 AM, Mr. Teo En Ming (Zhang Enming) wrote: >> Hi Tim, >> >> I thought it should be gfx_passthru=2 in domU config? >> -- >> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >> Technical Support Engineer >> Information Technology Department >> Asiasoft Online Pte Ltd >> Tampines Central 1 #04-01 Tampines Plaza >> Singapore 529541 >> Republic of Singapore >> Mobile: +65-9648-9798 >> MSN:teoenming@hotmail.com >> Alma Maters: Singapore Polytechnic, National University of Singapore >> >> >> On 08/29/2009 06:42 AM, Tim Moore wrote: >>> >>> Teo, >>> >>> I have also performed the same exercise as yourself and I now have >>> successfully compiled all 3x patches into Xen, Qemu and the BIOS >>> File Loading in the hvmloader, this all compiles find on my system. >>> Suggest you do a "make clean" on the tools and start again ! >>> >>> After booting with the patched xen-unstable and adding the >>> gfx-passthru=1 parameter to my HVM DomU, as I suspected - it still >>> doesn''t work. >>> >>> I have both a 9500GT and GTX260(primary) in my Intel DX58SO machine, >>> tried passing through either device and my primary display locks up >>> ! (included hiding with pci-stub) >>> >>> I verified that the DomU was functional beforehand, as It also >>> booted successfully without the gfx-passthru parameter (and a >>> vncviewer/cirrus display) >>> >>> Unfortunately, I can''t debug further as my Primary display corrupts >>> as soon as the DomU starts. I did notice that in "xm debug" the >>> "Loading Gfx BIOS File.." message was displayed and the DomU did >>> continue to initialise the BIOS tables and such before finally >>> locking. I then (blindly) typed on a corrupt Dom0 console and >>> managed to start kdm and login, so the Dom0 was not completely >>> trashed. But then after a few minutes, the machine totally froze and >>> had to hit the reset switch. >>> >>> I`m no specialist but this looks like the VGA BIOS Re-initialisation >>> is playing havoc with the DomU and possibly the Dom0 graphics. I >>> notice that both are also using IRQ11 which could play a major part. >>> Furthermore, there was a lot of debug output in the qemu and >>> xend.log indicating Base Address Register invalid access and >>> therefore it seems there may be a second obstacle. >>> >>> Hope you have a better success than me ! >>> >>> For now, I would try re-compiling a fresh xen-unstable with >>> carefully applied patches .. oh! and don''t forget to enable the >>> pci-stub driver for Dom0 (it''s not selected by default) >>> >>> Tim >>> >>> *From:* xen-devel-bounces@lists.xensource.com >>> [mailto:xen-devel-bounces@lists.xensource.com] *On Behalf Of *Mr. >>> Teo En Ming (Zhang Enming) >>> *Sent:* 28 August 2009 21:14 >>> *To:* enming.teo@asiasoftsea.net >>> *Cc:* xen-devel@lists.xensource.com; ''Lin, Ben Y''; ''Kay, Allen M''; >>> ''Jean Guyader''; Keir.Fraser@eu.citrix.com; weidong.han@intel.com; >>> bengheng@eecs.umich.edu >>> *Subject:* Re: [Xen-devel] [PATCH 2/2] graphics passthrough with VT-d >>> >>> After applying the 1st and 2nd patch to xen-unstable successfully, I examined the source codes Makefile and hvmloader.c in tools/firmware/hvmloader, compared them to Weidong''s 3rd patch and I generated my own 3rd patch. Then I used my own generated 3rd patch to apply patching for loading vga bios from firmware file. >>> >>> Here is my own generated 3rd patch instead of using Weidong''s 3rd patch: >>> >>> --- Makefile 2009-08-29 03:24:52.413083774 +0800 >>> +++ Makefile 2009-08-29 03:29:12.763299633 +0800 >>> @@ -50,6 +50,7 @@ >>> roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \ >>> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h >>> sh ./mkhex rombios ../rombios/BIOS-bochs-latest> roms.h >>> + sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin>> roms.h >>> sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin>> roms.h >>> sh ./mkhex vgabios_cirrusvga \ >>> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin>> roms.h >>> --- hvmloader.c 2009-08-29 03:26:06.911085797 +0800 >>> +++ hvmloader.c 2009-08-29 03:31:43.172084995 +0800 >>> @@ -688,9 +688,9 @@ >>> vgabios_sz = round_option_rom(sizeof(vgabios_stdvga)); >>> break; >>> case VGA_pt: >>> - printf("Loading VGABIOS of passthroughed gfx ...\n"); >>> - vgabios_sz >>> - round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512); >>> + printf("Loading Gfx Video BIOS from file ...\n"); >>> + memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt, sizeof(vgabios_pt)); >>> + vgabios_sz = round_option_rom(sizeof(vgabios_pt)); >>> break; >>> default: >>> printf("No emulated VGA adaptor ...\n"); >>> >>> >>> I can "make xen" successfully but when I proceeded to "make tools", errors were encountered. >>> >>> Please see attached error output. How can I solve this problem? >>> >>> >>> -- >>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>> Technical Support Engineer >>> Information Technology Department >>> Asiasoft Online Pte Ltd >>> Tampines Central 1 #04-01 Tampines Plaza >>> Singapore 529541 >>> Republic of Singapore >>> Mobile: +65-9648-9798 >>> MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> >>> Alma Maters: Singapore Polytechnic, National University of Singapore >>> >>> >>> >>> On 08/29/2009 12:59 AM, Mr. Teo En Ming (Zhang Enming) wrote: >>> >>> OK I believe the 3rd patch is not incomplete but there''s a white space issue when I copied the code from the mailing list into my vi. >>> >>> Seehttp://www.htdig.org/mail/2000/11/0167.html >>> >>> When I used the -l flag to patch using the 3rd patch, the number of errors was reduced. >>> >>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -l -p1< intel-gfx-passthru-patch-3.patch >>> patching file tools/firmware/hvmloader/Makefile >>> patching file tools/firmware/hvmloader/hvmloader.c >>> Hunk #1 FAILED at 688. >>> 1 out of 1 hunk FAILED -- saving rejects to file tools/firmware/hvmloader/hvmloader.c.rej >>> >>> Now patching tools/firmware/hvmloader/Makefile is successful but patching tools/firmware/hvmloader/hvmloader.c still failed. >>> >>> -- >>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>> Technical Support Engineer >>> Information Technology Department >>> Asiasoft Online Pte Ltd >>> Tampines Central 1 #04-01 Tampines Plaza >>> Singapore 529541 >>> Republic of Singapore >>> Mobile: +65-9648-9798 >>> MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> >>> Alma Maters: Singapore Polytechnic, National University of Singapore >>> >>> >>> >>> >>> On 08/28/2009 11:55 PM, Mr. Teo En Ming (Zhang Enming) wrote: >>> >>> Dear Weidong, >>> >>> A big big thanks for the vga passthrough patches for xen >>> 3.5-unstable!!! These are eagerly anticipated patches. As I did not >>> study computer science and computer architecture, I won''t be able to >>> write those patches you guys at Intel wrote. >>> >>> I applied the following patches *xen-gfx-passthrough.patch >>> <http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin> >>> and qemu-gfx-passthrough.patch >>> <http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin> >>> to xen 3.5-unstable without issues.* >>> >>> Then I tried to apply the 3rd patch you provided at >>> http://lists.xensource.com/archives/html/xen-devel/2009-08/msg01047.html >>> >>> I saved the following code >>> >>> <CODE> >>> >>> diff -r 494be76c1ad9 tools/firmware/hvmloader/Makefile >>> --- a/tools/firmware/hvmloader/Makefile Thu Aug 27 16:54:33 2009 +0800 >>> +++ b/tools/firmware/hvmloader/Makefile Thu Aug 27 17:22:01 2009 +0800 >>> @@ -50,6 +50,7 @@ roms.h: ../rombios/BIOS-bochs-latest ../ >>> roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \ >>> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h >>> sh ./mkhex rombios ../rombios/BIOS-bochs-latest> roms.h >>> + sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin>> roms.h >>> sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin>> roms.h >>> sh ./mkhex vgabios_cirrusvga \ >>> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin>> roms.h >>> diff -r 494be76c1ad9 tools/firmware/hvmloader/hvmloader.c >>> --- a/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 16:54:33 2009 +0800 >>> +++ b/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 17:23:00 2009 +0800 >>> @@ -688,9 +688,9 @@ int main(void) >>> vgabios_sz = round_option_rom(sizeof(vgabios_stdvga)); >>> break; >>> case VGA_pt: >>> - printf("Loading Gfx Video BIOS from 0xC0000 ...\n"); >>> - vgabios_sz >>> - round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512); >>> + printf("Loading Gfx Video BIOS from file ...\n"); >>> + memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt, >>> sizeof(vgabios_pt)); >>> + vgabios_sz = round_option_rom(sizeof(vgabios_pt)); >>> break; >>> default: >>> printf("No emulated VGA adaptor ...\n"); >>> >>> </CODE> >>> >>> as intel-gfx-passthru-patch-3.patch and then I tried to apply the patch to xen 3.5-unstable. I got errors. I think it''s because the 3rd patch you provided is incomplete. >>> >>> Here''s my patching process: >>> >>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name vgabios >>> ./tools/firmware/vgabios >>> ./.hg/store/data/tools/firmware/vgabios >>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cp ~enming/vgabios-pt.bin tools/firmware/vgabios/ >>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ls tools/firmware/vgabios/ >>> biossums.c clext.c Makefile TODO vbe.h vgabios.h vgatables.h >>> BUGS COPYING Notes vbe.c vbetables-gen.c vgabios-pt.bin >>> ChangeLog dataseghack README vbe_display_api.txt vgabios.c vgafonts.h >>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# pwd >>> /usr/src/xen-unstable.hg-vgapt >>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wgethttp://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin >>> --2009-08-28 23:18:21--http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin >>> Resolving lists.xensource.com... 70.42.241.110 >>> Connecting to lists.xensource.com|70.42.241.110|:80... connected. >>> HTTP request sent, awaiting response... 200 OK >>> Length: 12565 (12K) [application/octet-stream] >>> Saving to: `bincPiiAf0QWg.bin'' >>> >>> 100%[======================================================================>] 12,565 30.7K/s in 0.4s >>> >>> 2009-08-28 23:18:22 (30.7 KB/s) - `bincPiiAf0QWg.bin'' saved [12565/12565] >>> >>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv bincPiiAf0QWg.bin xen-gfx-passthrough.patch >>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi xen-gfx-passthrough.patch >>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch< xen-gfx-passthrough.patch >>> can''t find file to patch at input line 4 >>> Perhaps you should have used the -p or --strip option? >>> The text leading up to this was: >>> -------------------------- >>> |diff -r 5d7e7a250267 tools/firmware/hvmloader/config.h >>> |--- a/tools/firmware/hvmloader/config.h Wed Aug 26 18:28:44 2009 +0800 >>> |+++ b/tools/firmware/hvmloader/config.h Thu Aug 27 16:54:24 2009 +0800 >>> -------------------------- >>> File to patch: ^C >>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ex xen-gfx-passthrough.patch >>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1< xen-gfx-passthrough.patch >>> patching file tools/firmware/hvmloader/config.h >>> patching file tools/firmware/hvmloader/hvmloader.c >>> patching file tools/libxc/ia64/xc_ia64_hvm_build.c >>> patching file tools/libxc/xc_hvm_build.c >>> patching file tools/libxc/xc_linux.c >>> patching file tools/libxc/xenctrl.h >>> patching file tools/libxc/xenguest.h >>> patching file tools/python/xen/lowlevel/xc/xc.c >>> patching file tools/python/xen/xend/XendConfig.py >>> Hunk #1 succeeded at 174 (offset -1 lines). >>> patching file tools/python/xen/xend/image.py >>> Hunk #1 succeeded at 780 (offset -6 lines). >>> Hunk #3 succeeded at 895 (offset -6 lines). >>> patching file tools/python/xen/xm/create.py >>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wgethttp://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin >>> --2009-08-28 23:21:35--http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin >>> Resolving lists.xensource.com... 70.42.241.110 >>> Connecting to lists.xensource.com|70.42.241.110|:80... connected. >>> HTTP request sent, awaiting response... 200 OK >>> Length: 9841 (9.6K) [application/octet-stream] >>> Saving to: `binglLqkeq4Rj.bin'' >>> >>> 100%[======================================================================>] 9,841 24.3K/s in 0.4s >>> >>> 2009-08-28 23:21:36 (24.3 KB/s) - `binglLqkeq4Rj.bin'' saved [9841/9841] >>> >>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv binglLqkeq4Rj.bin qemu-gfx-passthrough.patch >>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi qemu-gfx-passthrough.patch >>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name hw >>> ./tools/ioemu-remote/hw >>> ./.hg/store/data/tools/ioemu/hw >>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv qemu-gfx-passthrough.patch tools/ioemu-remote/ >>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cd tools/ioemu-remote/ >>> [root@fedora11-x86-64-host ioemu-remote]# patch -p1< qemu- >>> qemu-aio.h qemu-img.c qemu-sockets.c >>> qemu-binfmt-conf.sh qemu-img.texi qemu-tech.texi >>> qemu-char.c qemu-lock.h qemu-timer.h >>> qemu-char.h qemu-log.h qemu-tool.c >>> qemu-common.h qemu-malloc.c qemu-xen.h >>> qemu-doc.texi qemu-nbd.c >>> qemu-gfx-passthrough.patch qemu-nbd.texi >>> [root@fedora11-x86-64-host ioemu-remote]# patch -p1< qemu-gfx-passthrough.patch >>> patching file hw/pass-through.c >>> patching file hw/pass-through.h >>> patching file hw/pc.c >>> patching file vl.c >>> [root@fedora11-x86-64-host ioemu-remote]# cd .. >>> [root@fedora11-x86-64-host tools]# cd .. >>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi intel-gfx-passthru-patch-3.patch >>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1< intel-gfx-passthru-patch-3.patch >>> patching file tools/firmware/hvmloader/Makefile >>> Hunk #1 FAILED at 50. >>> 1 out of 1 hunk FAILED -- saving rejects to file tools/firmware/hvmloader/Makefile.rej >>> patching file tools/firmware/hvmloader/hvmloader.c >>> patch: **** malformed patch at line 24: sizeof(vgabios_pt)); >>> >>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi intel-gfx-passthru-patch-3.patch >>> >>> For everybody''s convenience, I have attached intel-gfx-passthru-patch-3.patch and the firmware for my nVidia GeForce 8400 GS PCI Express x16 graphics card in this email. >>> >>> Please help me complete intel-gfx-passthru-patch-3.patch as I really need it. >>> >>> Thank you very much!!! >>> >>> -- >>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>> Technical Support Engineer >>> Information Technology Department >>> Asiasoft Online Pte Ltd >>> Tampines Central 1 #04-01 Tampines Plaza >>> Singapore 529541 >>> Republic of Singapore >>> Mobile: +65-9648-9798 >>> MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> >>> Alma Maters: Singapore Polytechnic, National University of Singapore >>> >>> This patch supports basic gfx passthrough on QEMU: >>> >>> - disable emulated VGA adpater if there is passthroughed gfx >>> >>> - register/unregister legacy VGA I/O ports and MMIOs for passthroughed gfx >>> >>> >>> >>> Signed-off-by: Ben Lin<ben.y.lin@intel.com> <mailto:ben.y.lin@intel.com> >>> >>> Signed-off-by: Weidong Han<weidong.han@intel.com> <mailto:weidong.han@intel.com> >>> >>> No virus found in this incoming message. >>> >>> Checked by AVG -www.avg.com <http://www.avg.com> >>> >>> Version: 8.5.409 / Virus Database: 270.13.69/2328 - Release Date: 08/27/09 >>> >>> 18:02:00 >>> >>> >>> >>> No virus found in this outgoing message. >>> >>> Checked by AVG -www.avg.com <http://www.avg.com> >>> >>> Version: 8.5.409 / Virus Database: 270.13.71/2330 - Release Date: 08/27/09 >>> >>> 18:02:00 >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> >>> Xen-devel mailing list >>> >>> Xen-devel@lists.xensource.com <mailto:Xen-devel@lists.xensource.com> >>> >>> http://lists.xensource.com/xen-devel >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xensource.com <mailto: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 >> > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Boris Derzhavets
2009-Aug-29 10:41 UTC
[Xen-devel] Failure when "make tools" via xen-3.4.1 tarball on Ubuntu 9.10 Server ALPHA 4
make xen OK
make stubtom OK
make tools :-
. . . . . .
gcc -O2 -fomit-frame-pointer -m64 -fno-strict-aliasing -std=gnu99 -Wall
-Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement
-D__XEN_TOOLS__ -MMD -MF .xc_core.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_GNU_SOURCE -I../../xen/common/libelf -Werror -Wmissing-prototypes -I.
-I../xenstore -I../include -c -o xc_core.o xc_core.c
cc1: warnings being treated as errors
In file included from /usr/include/string.h:640,
from xg_private.h:9,
from xc_core.c:52:
In function ‘memset’,
inlined from ‘xc_domain_dumpcore_via_callback’ at xc_core.c:324:
/usr/include/bits/string3.h:82: error: call to ‘__warn_memset_zero_len’ declared
with attribute warning: memset used with constant zero length parameter; this
could be due to transposed parameters
make[4]: *** [xc_core.o] Error 1
make[4]: Leaving directory `/usr/src/xen-3.4.1/tools/libxc''
make[3]: *** [build] Error 2
make[3]: Leaving directory `/usr/src/xen-3.4.1/tools/libxc''
make[2]: *** [subdir-install-libxc] Error 2
make[2]: Leaving directory `/usr/src/xen-3.4.1/tools''
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/usr/src/xen-3.4.1/tools''
make: *** [install-tools] Error 2
Boris.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Mr. Teo En Ming (Zhang Enming)
2009-Aug-29 11:03 UTC
Re: [Xen-devel] graphics passthrough with VT-d
Hi, I cloned http://xenbits.xensource.com/xen-unstable.hg again today. I tried applying the three Intel gfx passthrough patches to xen-unstable. When I "make tools", I get the same error again: make[7]: Entering directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader'' make -C acpi all get-path: will use #!/usr/bin/python2.6 for python programs make[8]: Entering directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' make iasl get-path: will use #!/usr/bin/python2.6 for python programs make[9]: Entering directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' make[9]: `/usr/local/bin/iasl'' is up to date. make[9]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' iasl -tc ssdt_tpm.asl Intel ACPI Component Architecture ASL Optimizing Compiler version 20090730 [Aug 29 2009] Copyright (C) 2000 - 2009 Intel Corporation Supports ACPI Specification Revision 4.0 ASL Input: ssdt_tpm.asl - 31 lines, 1111 bytes, 3 keywords AML Output: SSDT_TPM.aml - 76 bytes, 3 named objects, 0 executable opcodes Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 0 Optimizations mv ssdt_tpm.hex ssdt_tpm.h rm -f *.aml make iasl get-path: will use #!/usr/bin/python2.6 for python programs make[9]: Entering directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' make[9]: `/usr/local/bin/iasl'' is up to date. make[9]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' iasl -tc ssdt_pm.asl Intel ACPI Component Architecture ASL Optimizing Compiler version 20090730 [Aug 29 2009] Copyright (C) 2000 - 2009 Intel Corporation Supports ACPI Specification Revision 4.0 ASL Input: ssdt_pm.asl - 425 lines, 12754 bytes, 192 keywords AML Output: SSDT_PM.aml - 1494 bytes, 64 named objects, 128 executable opcodes Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 31 Optimizations mv ssdt_pm.hex ssdt_pm.h rm -f *.aml gcc -O1 -fno-omit-frame-pointer -fno-optimize-sibling-calls -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .build.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs -Werror -fno-stack-protector -fno-builtin -msoft-float -I. -I.. -I../../../../tools/include -c -o build.o build.c In file included from build.c:21: ssdt_pm.h:13: error: redefinition of ''AmlCode'' ssdt_tpm.h:13: note: previous definition of ''AmlCode'' was here build.c: In function ''construct_secondary_tables'': build.c:184: error: ''AmlCode_PM'' undeclared (first use in this function) build.c:184: error: (Each undeclared identifier is reported only once build.c:184: error: for each function it appears in.) build.c:194: error: ''AmlCode_TPM'' undeclared (first use in this function) make[8]: *** [build.o] Error 1 make[8]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' make[7]: *** [subdir-all-acpi] Error 2 make[7]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader'' make[6]: *** [subdirs-all] Error 2 make[6]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader'' make[5]: *** [subdir-all-hvmloader] Error 2 make[5]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware'' make[4]: *** [subdirs-all] Error 2 make[4]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware'' make[3]: *** [all] Error 2 make[3]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware'' make[2]: *** [subdir-install-firmware] Error 2 make[2]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools'' make[1]: *** [subdirs-install] Error 2 make[1]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools'' make: *** [install-tools] Error 2 Any ideas about this Advanced Configuration and Power Interface code? -- Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) Technical Support Engineer Information Technology Department Asiasoft Online Pte Ltd Tampines Central 1 #04-01 Tampines Plaza Singapore 529541 Republic of Singapore Company Website: http://www.asiasoft.sg/ Mobile: +65-9648-9798 MSN: teoenming@hotmail.com Alma Maters: Singapore Polytechnic, National University of Singapore On 08/29/2009 02:58 PM, Mr. Teo En Ming (Zhang Enming) wrote:> Hi > > Anybody available today? I know it''s Saturday. :-) > > -- > Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) > Technical Support Engineer > Information Technology Department > Asiasoft Online Pte Ltd > Tampines Central 1 #04-01 Tampines Plaza > Singapore 529541 > Republic of Singapore > Company Website:http://www.asiasoft.sg/ > Mobile: +65-9648-9798 > MSN:teoenming@hotmail.com > Alma Maters: Singapore Polytechnic, National University of Singapore > > > On 08/29/2009 11:48 AM, Mr. Teo En Ming (Zhang Enming) wrote: >> >> Dear All, >> >> After applying Intel VGA passthrough patches 1, 2 and 3, I have no problems with "make xen", and "make install-xen". However, I have errors with "make tools". >> >> Here is the error output: >> >> msoft-float -I. -I.. -I../../../../tools/include -c -o build.o build.c >> build.c: In function ''construct_secondary_tables'': >> build.c:194: error: ''AmlCode_TPM'' undeclared (first use in this function) >> build.c:194: error: (Each undeclared identifier is reported only once >> build.c:194: error: for each function it appears in.) >> make[8]: *** [build.o] Error 1 >> make[8]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader/acpi'' >> make[7]: *** [subdir-all-acpi] Error 2 >> make[7]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader'' >> make[6]: *** [subdirs-all] Error 2 >> make[6]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader'' >> make[5]: *** [subdir-all-hvmloader] Error 2 >> make[5]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'' >> make[4]: *** [subdirs-all] Error 2 >> make[4]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'' >> make[3]: *** [all] Error 2 >> make[3]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'' >> make[2]: *** [subdir-install-firmware] Error 2 >> make[2]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools'' >> make[1]: *** [subdirs-install] Error 2 >> make[1]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools'' >> make: *** [install-tools] Error 2 >> >> There is an undeclared identifier in tools/firmware/hvmloader/acpi/build.c source code. Could you guys help me resolve this issue? >> >> I had no problems compiling xen 3.5-unstable before applying the Intel vga passthrough patches and before installing the Intel ACPI Component Architecture compiler. >> >> I have also attached Intel graphics passthrough patches 1, 2 and 3 for your convenience here. >> >> Thank you very much. >> >> Hope I can get this working during the weekends. >> >> -- >> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >> Technical Support Engineer >> Information Technology Department >> Asiasoft Online Pte Ltd >> Tampines Central 1 #04-01 Tampines Plaza >> Singapore 529541 >> Republic of Singapore >> Company Website:http://www.asiasoft.sg/ >> Mobile: +65-9648-9798 >> MSN:teoenming@hotmail.com >> Alma Maters: Singapore Polytechnic, National University of Singapore >> >> >> On 08/29/2009 10:17 AM, Mr. Teo En Ming (Zhang Enming) wrote: >>> Hi Tim, >>> >>> I thought it should be gfx_passthru=2 in domU config? >>> -- >>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>> Technical Support Engineer >>> Information Technology Department >>> Asiasoft Online Pte Ltd >>> Tampines Central 1 #04-01 Tampines Plaza >>> Singapore 529541 >>> Republic of Singapore >>> Mobile: +65-9648-9798 >>> MSN:teoenming@hotmail.com >>> Alma Maters: Singapore Polytechnic, National University of Singapore >>> >>> >>> On 08/29/2009 06:42 AM, Tim Moore wrote: >>>> >>>> Teo, >>>> >>>> I have also performed the same exercise as yourself and I now have >>>> successfully compiled all 3x patches into Xen, Qemu and the BIOS >>>> File Loading in the hvmloader, this all compiles find on my system. >>>> Suggest you do a "make clean" on the tools and start again ! >>>> >>>> After booting with the patched xen-unstable and adding the >>>> gfx-passthru=1 parameter to my HVM DomU, as I suspected - it still >>>> doesn''t work. >>>> >>>> I have both a 9500GT and GTX260(primary) in my Intel DX58SO >>>> machine, tried passing through either device and my primary display >>>> locks up ! (included hiding with pci-stub) >>>> >>>> I verified that the DomU was functional beforehand, as It also >>>> booted successfully without the gfx-passthru parameter (and a >>>> vncviewer/cirrus display) >>>> >>>> Unfortunately, I can''t debug further as my Primary display corrupts >>>> as soon as the DomU starts. I did notice that in "xm debug" the >>>> "Loading Gfx BIOS File.." message was displayed and the DomU did >>>> continue to initialise the BIOS tables and such before finally >>>> locking. I then (blindly) typed on a corrupt Dom0 console and >>>> managed to start kdm and login, so the Dom0 was not completely >>>> trashed. But then after a few minutes, the machine totally froze >>>> and had to hit the reset switch. >>>> >>>> I`m no specialist but this looks like the VGA BIOS >>>> Re-initialisation is playing havoc with the DomU and possibly the >>>> Dom0 graphics. I notice that both are also using IRQ11 which could >>>> play a major part. Furthermore, there was a lot of debug output in >>>> the qemu and xend.log indicating Base Address Register invalid >>>> access and therefore it seems there may be a second obstacle. >>>> >>>> Hope you have a better success than me ! >>>> >>>> For now, I would try re-compiling a fresh xen-unstable with >>>> carefully applied patches .. oh! and don''t forget to enable the >>>> pci-stub driver for Dom0 (it''s not selected by default) >>>> >>>> Tim >>>> >>>> *From:* xen-devel-bounces@lists.xensource.com >>>> [mailto:xen-devel-bounces@lists.xensource.com] *On Behalf Of *Mr. >>>> Teo En Ming (Zhang Enming) >>>> *Sent:* 28 August 2009 21:14 >>>> *To:* enming.teo@asiasoftsea.net >>>> *Cc:* xen-devel@lists.xensource.com; ''Lin, Ben Y''; ''Kay, Allen M''; >>>> ''Jean Guyader''; Keir.Fraser@eu.citrix.com; weidong.han@intel.com; >>>> bengheng@eecs.umich.edu >>>> *Subject:* Re: [Xen-devel] [PATCH 2/2] graphics passthrough with VT-d >>>> >>>> After applying the 1st and 2nd patch to xen-unstable successfully, I examined the source codes Makefile and hvmloader.c in tools/firmware/hvmloader, compared them to Weidong''s 3rd patch and I generated my own 3rd patch. Then I used my own generated 3rd patch to apply patching for loading vga bios from firmware file. >>>> >>>> Here is my own generated 3rd patch instead of using Weidong''s 3rd patch: >>>> >>>> --- Makefile 2009-08-29 03:24:52.413083774 +0800 >>>> +++ Makefile 2009-08-29 03:29:12.763299633 +0800 >>>> @@ -50,6 +50,7 @@ >>>> roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \ >>>> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h >>>> sh ./mkhex rombios ../rombios/BIOS-bochs-latest> roms.h >>>> + sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin>> roms.h >>>> sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin>> roms.h >>>> sh ./mkhex vgabios_cirrusvga \ >>>> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin>> roms.h >>>> --- hvmloader.c 2009-08-29 03:26:06.911085797 +0800 >>>> +++ hvmloader.c 2009-08-29 03:31:43.172084995 +0800 >>>> @@ -688,9 +688,9 @@ >>>> vgabios_sz = round_option_rom(sizeof(vgabios_stdvga)); >>>> break; >>>> case VGA_pt: >>>> - printf("Loading VGABIOS of passthroughed gfx ...\n"); >>>> - vgabios_sz >>>> - round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512); >>>> + printf("Loading Gfx Video BIOS from file ...\n"); >>>> + memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt, sizeof(vgabios_pt)); >>>> + vgabios_sz = round_option_rom(sizeof(vgabios_pt)); >>>> break; >>>> default: >>>> printf("No emulated VGA adaptor ...\n"); >>>> >>>> >>>> I can "make xen" successfully but when I proceeded to "make tools", errors were encountered. >>>> >>>> Please see attached error output. How can I solve this problem? >>>> >>>> >>>> -- >>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>>> Technical Support Engineer >>>> Information Technology Department >>>> Asiasoft Online Pte Ltd >>>> Tampines Central 1 #04-01 Tampines Plaza >>>> Singapore 529541 >>>> Republic of Singapore >>>> Mobile: +65-9648-9798 >>>> MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> >>>> Alma Maters: Singapore Polytechnic, National University of Singapore >>>> >>>> >>>> >>>> On 08/29/2009 12:59 AM, Mr. Teo En Ming (Zhang Enming) wrote: >>>> >>>> OK I believe the 3rd patch is not incomplete but there''s a white space issue when I copied the code from the mailing list into my vi. >>>> >>>> Seehttp://www.htdig.org/mail/2000/11/0167.html >>>> >>>> When I used the -l flag to patch using the 3rd patch, the number of errors was reduced. >>>> >>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -l -p1< intel-gfx-passthru-patch-3.patch >>>> patching file tools/firmware/hvmloader/Makefile >>>> patching file tools/firmware/hvmloader/hvmloader.c >>>> Hunk #1 FAILED at 688. >>>> 1 out of 1 hunk FAILED -- saving rejects to file tools/firmware/hvmloader/hvmloader.c.rej >>>> >>>> Now patching tools/firmware/hvmloader/Makefile is successful but patching tools/firmware/hvmloader/hvmloader.c still failed. >>>> >>>> -- >>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>>> Technical Support Engineer >>>> Information Technology Department >>>> Asiasoft Online Pte Ltd >>>> Tampines Central 1 #04-01 Tampines Plaza >>>> Singapore 529541 >>>> Republic of Singapore >>>> Mobile: +65-9648-9798 >>>> MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> >>>> Alma Maters: Singapore Polytechnic, National University of Singapore >>>> >>>> >>>> >>>> >>>> On 08/28/2009 11:55 PM, Mr. Teo En Ming (Zhang Enming) wrote: >>>> >>>> Dear Weidong, >>>> >>>> A big big thanks for the vga passthrough patches for xen >>>> 3.5-unstable!!! These are eagerly anticipated patches. As I did not >>>> study computer science and computer architecture, I won''t be able >>>> to write those patches you guys at Intel wrote. >>>> >>>> I applied the following patches *xen-gfx-passthrough.patch >>>> <http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin> >>>> and qemu-gfx-passthrough.patch >>>> <http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin> >>>> to xen 3.5-unstable without issues.* >>>> >>>> Then I tried to apply the 3rd patch you provided at >>>> http://lists.xensource.com/archives/html/xen-devel/2009-08/msg01047.html >>>> >>>> I saved the following code >>>> >>>> <CODE> >>>> >>>> diff -r 494be76c1ad9 tools/firmware/hvmloader/Makefile >>>> --- a/tools/firmware/hvmloader/Makefile Thu Aug 27 16:54:33 2009 +0800 >>>> +++ b/tools/firmware/hvmloader/Makefile Thu Aug 27 17:22:01 2009 +0800 >>>> @@ -50,6 +50,7 @@ roms.h: ../rombios/BIOS-bochs-latest ../ >>>> roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \ >>>> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h >>>> sh ./mkhex rombios ../rombios/BIOS-bochs-latest> roms.h >>>> + sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin>> roms.h >>>> sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin>> roms.h >>>> sh ./mkhex vgabios_cirrusvga \ >>>> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin>> roms.h >>>> diff -r 494be76c1ad9 tools/firmware/hvmloader/hvmloader.c >>>> --- a/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 16:54:33 2009 +0800 >>>> +++ b/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 17:23:00 2009 +0800 >>>> @@ -688,9 +688,9 @@ int main(void) >>>> vgabios_sz = round_option_rom(sizeof(vgabios_stdvga)); >>>> break; >>>> case VGA_pt: >>>> - printf("Loading Gfx Video BIOS from 0xC0000 ...\n"); >>>> - vgabios_sz >>>> - round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512); >>>> + printf("Loading Gfx Video BIOS from file ...\n"); >>>> + memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt, >>>> sizeof(vgabios_pt)); >>>> + vgabios_sz = round_option_rom(sizeof(vgabios_pt)); >>>> break; >>>> default: >>>> printf("No emulated VGA adaptor ...\n"); >>>> >>>> </CODE> >>>> >>>> as intel-gfx-passthru-patch-3.patch and then I tried to apply the patch to xen 3.5-unstable. I got errors. I think it''s because the 3rd patch you provided is incomplete. >>>> >>>> Here''s my patching process: >>>> >>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name vgabios >>>> ./tools/firmware/vgabios >>>> ./.hg/store/data/tools/firmware/vgabios >>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cp ~enming/vgabios-pt.bin tools/firmware/vgabios/ >>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ls tools/firmware/vgabios/ >>>> biossums.c clext.c Makefile TODO vbe.h vgabios.h vgatables.h >>>> BUGS COPYING Notes vbe.c vbetables-gen.c vgabios-pt.bin >>>> ChangeLog dataseghack README vbe_display_api.txt vgabios.c vgafonts.h >>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# pwd >>>> /usr/src/xen-unstable.hg-vgapt >>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wgethttp://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin >>>> --2009-08-28 23:18:21--http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin >>>> Resolving lists.xensource.com... 70.42.241.110 >>>> Connecting to lists.xensource.com|70.42.241.110|:80... connected. >>>> HTTP request sent, awaiting response... 200 OK >>>> Length: 12565 (12K) [application/octet-stream] >>>> Saving to: `bincPiiAf0QWg.bin'' >>>> >>>> 100%[======================================================================>] 12,565 30.7K/s in 0.4s >>>> >>>> 2009-08-28 23:18:22 (30.7 KB/s) - `bincPiiAf0QWg.bin'' saved [12565/12565] >>>> >>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv bincPiiAf0QWg.bin xen-gfx-passthrough.patch >>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi xen-gfx-passthrough.patch >>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch< xen-gfx-passthrough.patch >>>> can''t find file to patch at input line 4 >>>> Perhaps you should have used the -p or --strip option? >>>> The text leading up to this was: >>>> -------------------------- >>>> |diff -r 5d7e7a250267 tools/firmware/hvmloader/config.h >>>> |--- a/tools/firmware/hvmloader/config.h Wed Aug 26 18:28:44 2009 +0800 >>>> |+++ b/tools/firmware/hvmloader/config.h Thu Aug 27 16:54:24 2009 +0800 >>>> -------------------------- >>>> File to patch: ^C >>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ex xen-gfx-passthrough.patch >>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1< xen-gfx-passthrough.patch >>>> patching file tools/firmware/hvmloader/config.h >>>> patching file tools/firmware/hvmloader/hvmloader.c >>>> patching file tools/libxc/ia64/xc_ia64_hvm_build.c >>>> patching file tools/libxc/xc_hvm_build.c >>>> patching file tools/libxc/xc_linux.c >>>> patching file tools/libxc/xenctrl.h >>>> patching file tools/libxc/xenguest.h >>>> patching file tools/python/xen/lowlevel/xc/xc.c >>>> patching file tools/python/xen/xend/XendConfig.py >>>> Hunk #1 succeeded at 174 (offset -1 lines). >>>> patching file tools/python/xen/xend/image.py >>>> Hunk #1 succeeded at 780 (offset -6 lines). >>>> Hunk #3 succeeded at 895 (offset -6 lines). >>>> patching file tools/python/xen/xm/create.py >>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wgethttp://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin >>>> --2009-08-28 23:21:35--http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin >>>> Resolving lists.xensource.com... 70.42.241.110 >>>> Connecting to lists.xensource.com|70.42.241.110|:80... connected. >>>> HTTP request sent, awaiting response... 200 OK >>>> Length: 9841 (9.6K) [application/octet-stream] >>>> Saving to: `binglLqkeq4Rj.bin'' >>>> >>>> 100%[======================================================================>] 9,841 24.3K/s in 0.4s >>>> >>>> 2009-08-28 23:21:36 (24.3 KB/s) - `binglLqkeq4Rj.bin'' saved [9841/9841] >>>> >>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv binglLqkeq4Rj.bin qemu-gfx-passthrough.patch >>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi qemu-gfx-passthrough.patch >>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name hw >>>> ./tools/ioemu-remote/hw >>>> ./.hg/store/data/tools/ioemu/hw >>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv qemu-gfx-passthrough.patch tools/ioemu-remote/ >>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cd tools/ioemu-remote/ >>>> [root@fedora11-x86-64-host ioemu-remote]# patch -p1< qemu- >>>> qemu-aio.h qemu-img.c qemu-sockets.c >>>> qemu-binfmt-conf.sh qemu-img.texi qemu-tech.texi >>>> qemu-char.c qemu-lock.h qemu-timer.h >>>> qemu-char.h qemu-log.h qemu-tool.c >>>> qemu-common.h qemu-malloc.c qemu-xen.h >>>> qemu-doc.texi qemu-nbd.c >>>> qemu-gfx-passthrough.patch qemu-nbd.texi >>>> [root@fedora11-x86-64-host ioemu-remote]# patch -p1< qemu-gfx-passthrough.patch >>>> patching file hw/pass-through.c >>>> patching file hw/pass-through.h >>>> patching file hw/pc.c >>>> patching file vl.c >>>> [root@fedora11-x86-64-host ioemu-remote]# cd .. >>>> [root@fedora11-x86-64-host tools]# cd .. >>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi intel-gfx-passthru-patch-3.patch >>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1< intel-gfx-passthru-patch-3.patch >>>> patching file tools/firmware/hvmloader/Makefile >>>> Hunk #1 FAILED at 50. >>>> 1 out of 1 hunk FAILED -- saving rejects to file tools/firmware/hvmloader/Makefile.rej >>>> patching file tools/firmware/hvmloader/hvmloader.c >>>> patch: **** malformed patch at line 24: sizeof(vgabios_pt)); >>>> >>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi intel-gfx-passthru-patch-3.patch >>>> >>>> For everybody''s convenience, I have attached intel-gfx-passthru-patch-3.patch and the firmware for my nVidia GeForce 8400 GS PCI Express x16 graphics card in this email. >>>> >>>> Please help me complete intel-gfx-passthru-patch-3.patch as I really need it. >>>> >>>> Thank you very much!!! >>>> >>>> -- >>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>>> Technical Support Engineer >>>> Information Technology Department >>>> Asiasoft Online Pte Ltd >>>> Tampines Central 1 #04-01 Tampines Plaza >>>> Singapore 529541 >>>> Republic of Singapore >>>> Mobile: +65-9648-9798 >>>> MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> >>>> Alma Maters: Singapore Polytechnic, National University of Singapore >>>> >>>> This patch supports basic gfx passthrough on QEMU: >>>> >>>> - disable emulated VGA adpater if there is passthroughed gfx >>>> >>>> - register/unregister legacy VGA I/O ports and MMIOs for passthroughed gfx >>>> >>>> >>>> >>>> Signed-off-by: Ben Lin<ben.y.lin@intel.com> <mailto:ben.y.lin@intel.com> >>>> >>>> Signed-off-by: Weidong Han<weidong.han@intel.com> <mailto:weidong.han@intel.com> >>>> >>>> No virus found in this incoming message. >>>> >>>> Checked by AVG -www.avg.com <http://www.avg.com> >>>> >>>> Version: 8.5.409 / Virus Database: 270.13.69/2328 - Release Date: 08/27/09 >>>> >>>> 18:02:00 >>>> >>>> >>>> >>>> No virus found in this outgoing message. >>>> >>>> Checked by AVG -www.avg.com <http://www.avg.com> >>>> >>>> Version: 8.5.409 / Virus Database: 270.13.71/2330 - Release Date: 08/27/09 >>>> >>>> 18:02:00 >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> Xen-devel mailing list >>>> >>>> Xen-devel@lists.xensource.com <mailto:Xen-devel@lists.xensource.com> >>>> >>>> http://lists.xensource.com/xen-devel >>>> >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Xen-devel mailing list >>>> Xen-devel@lists.xensource.com <mailto: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 >>> >> >> >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Boris Derzhavets
2009-Aug-29 11:05 UTC
Re: [Xen-devel] Failure when "make tools" via xen-3.4.1 tarball on Ubuntu 9.10 Server ALPHA 4
I just commented out line 354 - memset (....) in xc_core.c and was able to
build tools. Not sure was it acceptable step or no.
Boris.
--- On Sat, 8/29/09, Boris Derzhavets <bderzhavets@yahoo.com> wrote:
From: Boris Derzhavets <bderzhavets@yahoo.com>
Subject: [Xen-devel] Failure when "make tools" via xen-3.4.1 tarball
on Ubuntu 9.10 Server ALPHA 4
To: "xen-devel@lists.xensource.com"
<xen-devel@lists.xensource.com>
Date: Saturday, August 29, 2009, 6:41 AM
make xen OK
make stubtom OK
make tools :-
. . . . . .
gcc -O2 -fomit-frame-pointer -m64 -fno-strict-aliasing -std=gnu99 -Wall
-Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement
-D__XEN_TOOLS__ -MMD -MF .xc_core.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_GNU_SOURCE -I../../xen/common/libelf -Werror -Wmissing-prototypes -I.
-I../xenstore -I../include -c -o xc_core.o xc_core.c
cc1: warnings being treated as errors
In file included from /usr/include/string.h:640,
from xg_private.h:9,
from xc_core.c:52:
In function ‘memset’,
inlined from ‘xc_domain_dumpcore_via_callback’ at
xc_core.c:324:
/usr/include/bits/string3.h:82: error: call to ‘__warn_memset_zero_len’ declared
with attribute warning: memset used with constant zero length parameter; this
could be due to transposed parameters
make[4]: *** [xc_core.o] Error 1
make[4]: Leaving directory `/usr/src/xen-3.4.1/tools/libxc''
make[3]: *** [build] Error 2
make[3]: Leaving directory `/usr/src/xen-3.4.1/tools/libxc''
make[2]: *** [subdir-install-libxc] Error 2
make[2]: Leaving directory `/usr/src/xen-3.4.1/tools''
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/usr/src/xen-3.4.1/tools''
make: *** [install-tools] Error 2
Boris.
-----Inline Attachment Follows-----
_______________________________________________
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
Mr. Teo En Ming (Zhang Enming)
2009-Aug-29 12:25 UTC
Re: [Xen-devel] graphics passthrough with VT-d
Hi All,
I have solved the problem encountered below when building tools for xen
3.5-unstable. The compile problem exists because I downloaded and
compiled the latest version of Intel ACPI Component Architecture
compiler version 20090730. And I used this latest compiler during "make
tools" for xen-unstable.
In original xen-unstable source codes cloned from xensoure mercurial
repository, the header files ssdt_pm.h and ssdt_tpm.h in source
directory tools/firmware/hvmloader/acpi/ are generated by
/*
*
* Intel ACPI Component Architecture
* ASL Optimizing Compiler version 20061109 [May 18 2007]
* Copyright (C) 2000 - 2006 Intel Corporation
* Supports ACPI Specification Revision 3.0a
*
* Compilation of "ssdt_pm.asl" - Sun Oct 12 23:57:51 2008
*
* C source code output
*
*/
In original ssdt_pm.h, it has "unsigned char AmlCode_PM[] =".
In original ssdt_tpm.h, it has "unsigned char AmlCode_TPM[] =".
Hence there was no problem with "make tools".
But, I downloaded, compiled and used
/*
*
* Intel ACPI Component Architecture
* ASL Optimizing Compiler version 20090730 [Aug 29 2009]
* Copyright (C) 2000 - 2009 Intel Corporation
* Supports ACPI Specification Revision 4.0
*
* Compilation of "ssdt_pm.asl" - Sat Aug 29 18:55:40 2009
*
* C source code output
*
*/
So the *new* ssdt_pm.h contains:
/*
*
* Intel ACPI Component Architecture
* ASL Optimizing Compiler version 20090730 [Aug 29 2009]
* Copyright (C) 2000 - 2009 Intel Corporation
* Supports ACPI Specification Revision 4.0
*
* Compilation of "ssdt_pm.asl" - Sat Aug 29 18:55:40 2009
*
* C source code output
*
*/
unsigned char AmlCode[] {
0x53,0x53,0x44,0x54,0xD6,0x05,0x00,0x00, /* 00000000
"SSDT...." */
0x02,0xB9,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008
"..Xen..." */
0x48,0x56,0x4D,0x00,0x00,0x00,0x00,0x00, /* 00000010
"HVM....." */
0x00,0x00,0x00,0x00,0x49,0x4E,0x54,0x4C, /* 00000018
"....INTL" */
0x30,0x07,0x09,0x20,0x10,0x41,0x5B,0x5C, /* 00000020 "0..
.A[\" */
0x5F,0x53,0x42,0x5F,0x5B,0x80,0x44,0x42, /* 00000028
"_SB_[.DB" */
0x47,0x41,0x01,0x0B,0x40,0xB0,0x01,0x5B, /* 00000030
"GA..@..[" */
0x81,0x0B,0x44,0x42,0x47,0x41,0x01,0x44, /* 00000038
"..DBGA.D" */
0x42,0x47,0x31,0x08,0x5B,0x80,0x44,0x42, /* 00000040
"BG1.[.DB" */
0x47,0x42,0x01,0x0B,0x44,0xB0,0x01,0x5B, /* 00000048
"GB..D..[" */
0x81,0x0B,0x44,0x42,0x47,0x42,0x01,0x44, /* 00000050
"..DBGB.D" */
0x42,0x47,0x32,0x08,0x5B,0x80,0x44,0x42, /* 00000058
"BG2.[.DB" */
0x47,0x43,0x01,0x0B,0x46,0xB0,0x01,0x5B, /* 00000060
"GC..F..[" */
0x81,0x0B,0x44,0x42,0x47,0x43,0x01,0x44, /* 00000068
"..DBGC.D" */
0x42,0x47,0x33,0x08,0x5B,0x80,0x44,0x42, /* 00000070
"BG3.[.DB" */
0x47,0x44,0x01,0x0B,0x48,0xB0,0x01,0x5B, /* 00000078
"GD..H..[" */
0x81,0x0B,0x44,0x42,0x47,0x44,0x01,0x44, /* 00000080
"..DBGD.D" */
0x42,0x47,0x34,0x08,0x5B,0x80,0x50,0x52, /* 00000088
"BG4.[.PR" */
0x54,0x31,0x01,0x0A,0xB2,0x0A,0x02,0x5B, /* 00000090
"T1.....[" */
0x81,0x10,0x50,0x52,0x54,0x31,0x01,0x50, /* 00000098
"..PRT1.P" */
0x42,0x32,0x5F,0x08,0x50,0x42,0x32,0x41, /* 000000A0
"B2_.PB2A" */
0x08,0x5B,0x80,0x50,0x52,0x54,0x32,0x01, /* 000000A8
".[.PRT2." */
0x0A,0x86,0x01,0x5B,0x81,0x0B,0x50,0x52, /* 000000B0
"...[..PR" */
0x54,0x32,0x01,0x50,0x38,0x36,0x5F,0x08, /* 000000B8
"T2.P86_." */
0x5B,0x80,0x50,0x52,0x54,0x33,0x01,0x0A, /* 000000C0
"[.PRT3.." */
0x88,0x01,0x5B,0x81,0x0B,0x50,0x52,0x54, /* 000000C8
"..[..PRT" */
0x33,0x01,0x50,0x38,0x38,0x5F,0x08,0x5B, /* 000000D0
"3.P88_.[" */
0x01,0x53,0x59,0x4E,0x43,0x01,0x08,0x42, /* 000000D8
".SYNC..B" */
0x55,0x46,0x30,0x11,0x04,0x0B,0x00,0x01, /* 000000E0
"UF0....." */
0x08,0x42,0x55,0x46,0x31,0x11,0x03,0x0A, /* 000000E8
".BUF1..." */
0x08,0x8B,0x42,0x55,0x46,0x31,0x00,0x42, /* 000000F0
"..BUF1.B" */
0x55,0x46,0x41,0x8B,0x42,0x55,0x46,0x31, /* 000000F8
"UFA.BUF1" */
0x0A,0x04,0x42,0x55,0x46,0x42,0x14,0x14, /* 00000100
"..BUFB.." */
And the *new* ssdt_tpm.h contains:
/*
*
* Intel ACPI Component Architecture
* ASL Optimizing Compiler version 20090730 [Aug 29 2009]
* Copyright (C) 2000 - 2009 Intel Corporation
* Supports ACPI Specification Revision 4.0
*
* Compilation of "ssdt_tpm.asl" - Sat Aug 29 18:55:40 2009
*
* C source code output
*
*/
unsigned char AmlCode[] {
0x53,0x53,0x44,0x54,0x4C,0x00,0x00,0x00, /* 00000000
"SSDTL..." */
0x02,0x2A,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008
".*Xen..." */
0x48,0x56,0x4D,0x00,0x00,0x00,0x00,0x00, /* 00000010
"HVM....." */
0x00,0x00,0x00,0x00,0x49,0x4E,0x54,0x4C, /* 00000018
"....INTL" */
0x30,0x07,0x09,0x20,0x5B,0x82,0x26,0x54, /* 00000020 "0..
[.&T" */
0x50,0x4D,0x5F,0x08,0x5F,0x48,0x49,0x44, /* 00000028
"PM_._HID" */
0x0C,0x41,0xD0,0x0C,0x31,0x08,0x5F,0x43, /* 00000030
".A..1._C" */
0x52,0x53,0x11,0x11,0x0A,0x0E,0x86,0x09, /* 00000038
"RS......" */
0x00,0x01,0x00,0x00,0xD4,0xFE,0x00,0x50, /* 00000040
".......P" */
0x00,0x00,0x79,0x00,
};
which are both wrong.
In ssdt_pm.h, I have to change "unsigned char AmlCode[]" to
"unsigned
char AmlCode_PM[]".
In ssdt_tpm.h, I have to change "unsigned char AmlCode[]" to
"unsigned
char AmlCode_TPM[]".
Then "make tools" is able to complete successfully.
I have created a patch for anybody who may be using the *latest* version
of Intel ACPI CA compiler version 20090730 and attached it here.
Patch file filename enming-patch04.patch:
<CODE>
Patch created by Teo En Ming (Zhang Enming) on 29 August 2009 Saturday
at 8:00 P.M. Singapore Time
Email #1: enming.teo@asiasoftsea.net
Email #2: space.time.universe@gmail.com
MSN: teoenming@hotmail.com
Mobile Phone: +65-9648-9798
--- ssdt_pm.h 2009-08-29 19:54:52.653088000 +0800
+++ ssdt_pm.h 2009-08-29 19:56:51.813088550 +0800
@@ -10,7 +10,7 @@
* C source code output
*
*/
-unsigned char AmlCode[] +unsigned char AmlCode_PM[] {
0x53,0x53,0x44,0x54,0xD6,0x05,0x00,0x00, /* 00000000
"SSDT...." */
0x02,0xB9,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008
"..Xen..." */
--- ssdt_tpm.h 2009-08-29 19:55:44.578738954 +0800
+++ ssdt_tpm.h 2009-08-29 19:57:27.896638884 +0800
@@ -10,7 +10,7 @@
* C source code output
*
*/
-unsigned char AmlCode[] +unsigned char AmlCode_TPM[] {
0x53,0x53,0x44,0x54,0x4C,0x00,0x00,0x00, /* 00000000
"SSDTL..." */
0x02,0x2A,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008
".*Xen..." */
</CODE>
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Company Website: http://www.asiasoft.sg/
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 07:03 PM, Mr. Teo En Ming (Zhang Enming)
wrote:> Hi,
>
> I clonedhttp://xenbits.xensource.com/xen-unstable.hg again today. I tried
applying the three Intel gfx passthrough patches to xen-unstable. When I
"make tools", I get the same error again:
>
> make[7]: Entering directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader''
> make -C acpi all
> get-path: will use #!/usr/bin/python2.6 for python programs
> make[8]: Entering directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi''
> make iasl
> get-path: will use #!/usr/bin/python2.6 for python programs
> make[9]: Entering directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi''
> make[9]: `/usr/local/bin/iasl'' is up to date.
> make[9]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi''
> iasl -tc ssdt_tpm.asl
>
> Intel ACPI Component Architecture
> ASL Optimizing Compiler version 20090730 [Aug 29 2009]
> Copyright (C) 2000 - 2009 Intel Corporation
> Supports ACPI Specification Revision 4.0
>
> ASL Input: ssdt_tpm.asl - 31 lines, 1111 bytes, 3 keywords
> AML Output: SSDT_TPM.aml - 76 bytes, 3 named objects, 0 executable opcodes
>
> Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 0 Optimizations
> mv ssdt_tpm.hex ssdt_tpm.h
> rm -f *.aml
> make iasl
> get-path: will use #!/usr/bin/python2.6 for python programs
> make[9]: Entering directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi''
> make[9]: `/usr/local/bin/iasl'' is up to date.
> make[9]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi''
> iasl -tc ssdt_pm.asl
>
> Intel ACPI Component Architecture
> ASL Optimizing Compiler version 20090730 [Aug 29 2009]
> Copyright (C) 2000 - 2009 Intel Corporation
> Supports ACPI Specification Revision 4.0
>
> ASL Input: ssdt_pm.asl - 425 lines, 12754 bytes, 192 keywords
> AML Output: SSDT_PM.aml - 1494 bytes, 64 named objects, 128 executable
opcodes
>
> Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 31 Optimizations
> mv ssdt_pm.hex ssdt_pm.h
> rm -f *.aml
> gcc -O1 -fno-omit-frame-pointer -fno-optimize-sibling-calls -m32
-march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes
-Wno-unused-value -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF
.build.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs
-Werror -fno-stack-protector -fno-builtin -msoft-float -I. -I..
-I../../../../tools/include -c -o build.o build.c
> In file included from build.c:21:
> ssdt_pm.h:13: error: redefinition of ''AmlCode''
> ssdt_tpm.h:13: note: previous definition of ''AmlCode'' was
here
> build.c: In function ''construct_secondary_tables'':
> build.c:184: error: ''AmlCode_PM'' undeclared (first use in
this function)
> build.c:184: error: (Each undeclared identifier is reported only once
> build.c:184: error: for each function it appears in.)
> build.c:194: error: ''AmlCode_TPM'' undeclared (first use
in this function)
> make[8]: *** [build.o] Error 1
> make[8]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi''
> make[7]: *** [subdir-all-acpi] Error 2
> make[7]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader''
> make[6]: *** [subdirs-all] Error 2
> make[6]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader''
> make[5]: *** [subdir-all-hvmloader] Error 2
> make[5]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware''
> make[4]: *** [subdirs-all] Error 2
> make[4]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware''
> make[3]: *** [all] Error 2
> make[3]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware''
> make[2]: *** [subdir-install-firmware] Error 2
> make[2]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools''
> make[1]: *** [subdirs-install] Error 2
> make[1]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools''
> make: *** [install-tools] Error 2
>
> Any ideas about this Advanced Configuration and Power Interface code?
>
> --
> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
> Technical Support Engineer
> Information Technology Department
> Asiasoft Online Pte Ltd
> Tampines Central 1 #04-01 Tampines Plaza
> Singapore 529541
> Republic of Singapore
> Company Website:http://www.asiasoft.sg/
> Mobile: +65-9648-9798
> MSN:teoenming@hotmail.com
> Alma Maters: Singapore Polytechnic, National University of Singapore
>
>
> On 08/29/2009 02:58 PM, Mr. Teo En Ming (Zhang Enming) wrote:
>> Hi
>>
>> Anybody available today? I know it''s Saturday. :-)
>>
>> --
>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
>> Technical Support Engineer
>> Information Technology Department
>> Asiasoft Online Pte Ltd
>> Tampines Central 1 #04-01 Tampines Plaza
>> Singapore 529541
>> Republic of Singapore
>> Company Website:http://www.asiasoft.sg/
>> Mobile: +65-9648-9798
>> MSN:teoenming@hotmail.com
>> Alma Maters: Singapore Polytechnic, National University of Singapore
>>
>>
>> On 08/29/2009 11:48 AM, Mr. Teo En Ming (Zhang Enming) wrote:
>>>
>>> Dear All,
>>>
>>> After applying Intel VGA passthrough patches 1, 2 and 3, I have no
problems with "make xen", and "make install-xen". However, I
have errors with "make tools".
>>>
>>> Here is the error output:
>>>
>>> msoft-float -I. -I.. -I../../../../tools/include -c -o build.o
build.c
>>> build.c: In function
''construct_secondary_tables'':
>>> build.c:194: error: ''AmlCode_TPM'' undeclared
(first use in this function)
>>> build.c:194: error: (Each undeclared identifier is reported only
once
>>> build.c:194: error: for each function it appears in.)
>>> make[8]: *** [build.o] Error 1
>>> make[8]: Leaving directory
`/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader/acpi''
>>> make[7]: *** [subdir-all-acpi] Error 2
>>> make[7]: Leaving directory
`/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader''
>>> make[6]: *** [subdirs-all] Error 2
>>> make[6]: Leaving directory
`/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader''
>>> make[5]: *** [subdir-all-hvmloader] Error 2
>>> make[5]: Leaving directory
`/usr/src/xen-unstable.hg-vgapt/tools/firmware''
>>> make[4]: *** [subdirs-all] Error 2
>>> make[4]: Leaving directory
`/usr/src/xen-unstable.hg-vgapt/tools/firmware''
>>> make[3]: *** [all] Error 2
>>> make[3]: Leaving directory
`/usr/src/xen-unstable.hg-vgapt/tools/firmware''
>>> make[2]: *** [subdir-install-firmware] Error 2
>>> make[2]: Leaving directory
`/usr/src/xen-unstable.hg-vgapt/tools''
>>> make[1]: *** [subdirs-install] Error 2
>>> make[1]: Leaving directory
`/usr/src/xen-unstable.hg-vgapt/tools''
>>> make: *** [install-tools] Error 2
>>>
>>> There is an undeclared identifier in
tools/firmware/hvmloader/acpi/build.c source code. Could you guys help me
resolve this issue?
>>>
>>> I had no problems compiling xen 3.5-unstable before applying the
Intel vga passthrough patches and before installing the Intel ACPI Component
Architecture compiler.
>>>
>>> I have also attached Intel graphics passthrough patches 1, 2 and 3
for your convenience here.
>>>
>>> Thank you very much.
>>>
>>> Hope I can get this working during the weekends.
>>>
>>> --
>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
>>> Technical Support Engineer
>>> Information Technology Department
>>> Asiasoft Online Pte Ltd
>>> Tampines Central 1 #04-01 Tampines Plaza
>>> Singapore 529541
>>> Republic of Singapore
>>> Company Website:http://www.asiasoft.sg/
>>> Mobile: +65-9648-9798
>>> MSN:teoenming@hotmail.com
>>> Alma Maters: Singapore Polytechnic, National University of
Singapore
>>>
>>>
>>> On 08/29/2009 10:17 AM, Mr. Teo En Ming (Zhang Enming) wrote:
>>>> Hi Tim,
>>>>
>>>> I thought it should be gfx_passthru=2 in domU config?
>>>> --
>>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
>>>> Technical Support Engineer
>>>> Information Technology Department
>>>> Asiasoft Online Pte Ltd
>>>> Tampines Central 1 #04-01 Tampines Plaza
>>>> Singapore 529541
>>>> Republic of Singapore
>>>> Mobile: +65-9648-9798
>>>> MSN:teoenming@hotmail.com
>>>> Alma Maters: Singapore Polytechnic, National University of
Singapore
>>>>
>>>>
>>>> On 08/29/2009 06:42 AM, Tim Moore wrote:
>>>>>
>>>>> Teo,
>>>>>
>>>>> I have also performed the same exercise as yourself and I
now have
>>>>> successfully compiled all 3x patches into Xen, Qemu and the
BIOS
>>>>> File Loading in the hvmloader, this all compiles find on my
>>>>> system. Suggest you do a "make clean" on the
tools and start again !
>>>>>
>>>>> After booting with the patched xen-unstable and adding the
>>>>> gfx-passthru=1 parameter to my HVM DomU, as I suspected -
it still
>>>>> doesn''t work.
>>>>>
>>>>> I have both a 9500GT and GTX260(primary) in my Intel DX58SO
>>>>> machine, tried passing through either device and my primary
>>>>> display locks up ! (included hiding with pci-stub)
>>>>>
>>>>> I verified that the DomU was functional beforehand, as It
also
>>>>> booted successfully without the gfx-passthru parameter (and
a
>>>>> vncviewer/cirrus display)
>>>>>
>>>>> Unfortunately, I can''t debug further as my Primary
display
>>>>> corrupts as soon as the DomU starts. I did notice that in
"xm
>>>>> debug" the "Loading Gfx BIOS File.." message
was displayed and the
>>>>> DomU did continue to initialise the BIOS tables and such
before
>>>>> finally locking. I then (blindly) typed on a corrupt Dom0
console
>>>>> and managed to start kdm and login, so the Dom0 was not
completely
>>>>> trashed. But then after a few minutes, the machine totally
froze
>>>>> and had to hit the reset switch.
>>>>>
>>>>> I`m no specialist but this looks like the VGA BIOS
>>>>> Re-initialisation is playing havoc with the DomU and
possibly the
>>>>> Dom0 graphics. I notice that both are also using IRQ11
which could
>>>>> play a major part. Furthermore, there was a lot of debug
output in
>>>>> the qemu and xend.log indicating Base Address Register
invalid
>>>>> access and therefore it seems there may be a second
obstacle.
>>>>>
>>>>> Hope you have a better success than me !
>>>>>
>>>>> For now, I would try re-compiling a fresh xen-unstable with
>>>>> carefully applied patches .. oh! and don''t forget
to enable the
>>>>> pci-stub driver for Dom0 (it''s not selected by
default)
>>>>>
>>>>> Tim
>>>>>
>>>>> *From:* xen-devel-bounces@lists.xensource.com
>>>>> [mailto:xen-devel-bounces@lists.xensource.com] *On Behalf
Of *Mr.
>>>>> Teo En Ming (Zhang Enming)
>>>>> *Sent:* 28 August 2009 21:14
>>>>> *To:* enming.teo@asiasoftsea.net
>>>>> *Cc:* xen-devel@lists.xensource.com; ''Lin, Ben
Y''; ''Kay, Allen M'';
>>>>> ''Jean Guyader'';
Keir.Fraser@eu.citrix.com; weidong.han@intel.com;
>>>>> bengheng@eecs.umich.edu
>>>>> *Subject:* Re: [Xen-devel] [PATCH 2/2] graphics passthrough
with VT-d
>>>>>
>>>>> After applying the 1st and 2nd patch to xen-unstable
successfully, I examined the source codes Makefile and hvmloader.c in
tools/firmware/hvmloader, compared them to Weidong''s 3rd patch and I
generated my own 3rd patch. Then I used my own generated 3rd patch to apply
patching for loading vga bios from firmware file.
>>>>>
>>>>> Here is my own generated 3rd patch instead of using
Weidong''s 3rd patch:
>>>>>
>>>>> --- Makefile 2009-08-29 03:24:52.413083774 +0800
>>>>> +++ Makefile 2009-08-29 03:29:12.763299633 +0800
>>>>> @@ -50,6 +50,7 @@
>>>>> roms.h: ../rombios/BIOS-bochs-latest
../vgabios/VGABIOS-lgpl-latest.bin \
>>>>> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin
../etherboot/eb-roms.h
>>>>> sh ./mkhex rombios
../rombios/BIOS-bochs-latest> roms.h
>>>>> + sh ./mkhex vgabios_pt
../vgabios/vgabios-pt.bin>> roms.h
>>>>> sh ./mkhex vgabios_stdvga
../vgabios/VGABIOS-lgpl-latest.bin>> roms.h
>>>>> sh ./mkhex vgabios_cirrusvga \
>>>>>
../vgabios/VGABIOS-lgpl-latest.cirrus.bin>> roms.h
>>>>> --- hvmloader.c 2009-08-29 03:26:06.911085797 +0800
>>>>> +++ hvmloader.c 2009-08-29 03:31:43.172084995 +0800
>>>>> @@ -688,9 +688,9 @@
>>>>> vgabios_sz =
round_option_rom(sizeof(vgabios_stdvga));
>>>>> break;
>>>>> case VGA_pt:
>>>>> - printf("Loading VGABIOS of passthroughed gfx
...\n");
>>>>> - vgabios_sz >>>>> -
round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512);
>>>>> + printf("Loading Gfx Video BIOS from file
...\n");
>>>>> + memcpy((void *)VGABIOS_PHYSICAL_ADDRESS,
vgabios_pt, sizeof(vgabios_pt));
>>>>> + vgabios_sz = round_option_rom(sizeof(vgabios_pt));
>>>>> break;
>>>>> default:
>>>>> printf("No emulated VGA adaptor
...\n");
>>>>>
>>>>>
>>>>> I can "make xen" successfully but when I
proceeded to "make tools", errors were encountered.
>>>>>
>>>>> Please see attached error output. How can I solve this
problem?
>>>>>
>>>>>
>>>>> --
>>>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics
Engineering) BEng(Hons)(Mechanical Engineering)
>>>>> Technical Support Engineer
>>>>> Information Technology Department
>>>>> Asiasoft Online Pte Ltd
>>>>> Tampines Central 1 #04-01 Tampines Plaza
>>>>> Singapore 529541
>>>>> Republic of Singapore
>>>>> Mobile: +65-9648-9798
>>>>> MSN:teoenming@hotmail.com
<mailto:teoenming@hotmail.com>
>>>>> Alma Maters: Singapore Polytechnic, National University of
Singapore
>>>>>
>>>>>
>>>>>
>>>>> On 08/29/2009 12:59 AM, Mr. Teo En Ming (Zhang Enming)
wrote:
>>>>>
>>>>> OK I believe the 3rd patch is not incomplete but
there''s a white space issue when I copied the code from the mailing
list into my vi.
>>>>>
>>>>> Seehttp://www.htdig.org/mail/2000/11/0167.html
>>>>>
>>>>> When I used the -l flag to patch using the 3rd patch, the
number of errors was reduced.
>>>>>
>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -l
-p1< intel-gfx-passthru-patch-3.patch
>>>>> patching file tools/firmware/hvmloader/Makefile
>>>>> patching file tools/firmware/hvmloader/hvmloader.c
>>>>> Hunk #1 FAILED at 688.
>>>>> 1 out of 1 hunk FAILED -- saving rejects to file
tools/firmware/hvmloader/hvmloader.c.rej
>>>>>
>>>>> Now patching tools/firmware/hvmloader/Makefile is
successful but patching tools/firmware/hvmloader/hvmloader.c still failed.
>>>>>
>>>>> --
>>>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics
Engineering) BEng(Hons)(Mechanical Engineering)
>>>>> Technical Support Engineer
>>>>> Information Technology Department
>>>>> Asiasoft Online Pte Ltd
>>>>> Tampines Central 1 #04-01 Tampines Plaza
>>>>> Singapore 529541
>>>>> Republic of Singapore
>>>>> Mobile: +65-9648-9798
>>>>> MSN:teoenming@hotmail.com
<mailto:teoenming@hotmail.com>
>>>>> Alma Maters: Singapore Polytechnic, National University of
Singapore
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 08/28/2009 11:55 PM, Mr. Teo En Ming (Zhang Enming)
wrote:
>>>>>
>>>>> Dear Weidong,
>>>>>
>>>>> A big big thanks for the vga passthrough patches for xen
>>>>> 3.5-unstable!!! These are eagerly anticipated patches. As I
did
>>>>> not study computer science and computer architecture, I
won''t be
>>>>> able to write those patches you guys at Intel wrote.
>>>>>
>>>>> I applied the following patches *xen-gfx-passthrough.patch
>>>>>
<http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin>
>>>>> and qemu-gfx-passthrough.patch
>>>>>
<http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin>
>>>>> to xen 3.5-unstable without issues.*
>>>>>
>>>>> Then I tried to apply the 3rd patch you provided at
>>>>>
http://lists.xensource.com/archives/html/xen-devel/2009-08/msg01047.html
>>>>>
>>>>> I saved the following code
>>>>>
>>>>> <CODE>
>>>>>
>>>>> diff -r 494be76c1ad9 tools/firmware/hvmloader/Makefile
>>>>> --- a/tools/firmware/hvmloader/Makefile Thu Aug 27 16:54:33
2009 +0800
>>>>> +++ b/tools/firmware/hvmloader/Makefile Thu Aug 27 17:22:01
2009 +0800
>>>>> @@ -50,6 +50,7 @@ roms.h: ../rombios/BIOS-bochs-latest ../
>>>>> roms.h: ../rombios/BIOS-bochs-latest
../vgabios/VGABIOS-lgpl-latest.bin \
>>>>> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin
../etherboot/eb-roms.h
>>>>> sh ./mkhex rombios ../rombios/BIOS-bochs-latest>
roms.h
>>>>> + sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin>>
roms.h
>>>>> sh ./mkhex vgabios_stdvga
../vgabios/VGABIOS-lgpl-latest.bin>> roms.h
>>>>> sh ./mkhex vgabios_cirrusvga \
>>>>> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin>>
roms.h
>>>>> diff -r 494be76c1ad9 tools/firmware/hvmloader/hvmloader.c
>>>>> --- a/tools/firmware/hvmloader/hvmloader.c Thu Aug 27
16:54:33 2009 +0800
>>>>> +++ b/tools/firmware/hvmloader/hvmloader.c Thu Aug 27
17:23:00 2009 +0800
>>>>> @@ -688,9 +688,9 @@ int main(void)
>>>>> vgabios_sz =
round_option_rom(sizeof(vgabios_stdvga));
>>>>> break;
>>>>> case VGA_pt:
>>>>> - printf("Loading Gfx Video BIOS from 0xC0000
...\n");
>>>>> - vgabios_sz >>>>> -
round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512);
>>>>> + printf("Loading Gfx Video BIOS from file
...\n");
>>>>> + memcpy((void *)VGABIOS_PHYSICAL_ADDRESS,
vgabios_pt,
>>>>> sizeof(vgabios_pt));
>>>>> + vgabios_sz =
round_option_rom(sizeof(vgabios_pt));
>>>>> break;
>>>>> default:
>>>>> printf("No emulated VGA adaptor
...\n");
>>>>>
>>>>> </CODE>
>>>>>
>>>>> as intel-gfx-passthru-patch-3.patch and then I tried to
apply the patch to xen 3.5-unstable. I got errors. I think it''s because
the 3rd patch you provided is incomplete.
>>>>>
>>>>> Here''s my patching process:
>>>>>
>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find .
-name vgabios
>>>>> ./tools/firmware/vgabios
>>>>> ./.hg/store/data/tools/firmware/vgabios
>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cp
~enming/vgabios-pt.bin tools/firmware/vgabios/
>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ls
tools/firmware/vgabios/
>>>>> biossums.c clext.c Makefile TODO
vbe.h vgabios.h vgatables.h
>>>>> BUGS COPYING Notes vbe.c
vbetables-gen.c vgabios-pt.bin
>>>>> ChangeLog dataseghack README vbe_display_api.txt
vgabios.c vgafonts.h
>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# pwd
>>>>> /usr/src/xen-unstable.hg-vgapt
>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]#
wgethttp://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin
>>>>> --2009-08-28
23:18:21--http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin
>>>>> Resolving lists.xensource.com... 70.42.241.110
>>>>> Connecting to lists.xensource.com|70.42.241.110|:80...
connected.
>>>>> HTTP request sent, awaiting response... 200 OK
>>>>> Length: 12565 (12K) [application/octet-stream]
>>>>> Saving to: `bincPiiAf0QWg.bin''
>>>>>
>>>>>
100%[======================================================================>]
12,565 30.7K/s in 0.4s
>>>>>
>>>>> 2009-08-28 23:18:22 (30.7 KB/s) -
`bincPiiAf0QWg.bin'' saved [12565/12565]
>>>>>
>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv
bincPiiAf0QWg.bin xen-gfx-passthrough.patch
>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi
xen-gfx-passthrough.patch
>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]#
patch< xen-gfx-passthrough.patch
>>>>> can''t find file to patch at input line 4
>>>>> Perhaps you should have used the -p or --strip option?
>>>>> The text leading up to this was:
>>>>> --------------------------
>>>>> |diff -r 5d7e7a250267 tools/firmware/hvmloader/config.h
>>>>> |--- a/tools/firmware/hvmloader/config.h Wed Aug 26
18:28:44 2009 +0800
>>>>> |+++ b/tools/firmware/hvmloader/config.h Thu Aug 27
16:54:24 2009 +0800
>>>>> --------------------------
>>>>> File to patch: ^C
>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ex
xen-gfx-passthrough.patch
>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch
-p1< xen-gfx-passthrough.patch
>>>>> patching file tools/firmware/hvmloader/config.h
>>>>> patching file tools/firmware/hvmloader/hvmloader.c
>>>>> patching file tools/libxc/ia64/xc_ia64_hvm_build.c
>>>>> patching file tools/libxc/xc_hvm_build.c
>>>>> patching file tools/libxc/xc_linux.c
>>>>> patching file tools/libxc/xenctrl.h
>>>>> patching file tools/libxc/xenguest.h
>>>>> patching file tools/python/xen/lowlevel/xc/xc.c
>>>>> patching file tools/python/xen/xend/XendConfig.py
>>>>> Hunk #1 succeeded at 174 (offset -1 lines).
>>>>> patching file tools/python/xen/xend/image.py
>>>>> Hunk #1 succeeded at 780 (offset -6 lines).
>>>>> Hunk #3 succeeded at 895 (offset -6 lines).
>>>>> patching file tools/python/xen/xm/create.py
>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]#
wgethttp://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin
>>>>> --2009-08-28
23:21:35--http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin
>>>>> Resolving lists.xensource.com... 70.42.241.110
>>>>> Connecting to lists.xensource.com|70.42.241.110|:80...
connected.
>>>>> HTTP request sent, awaiting response... 200 OK
>>>>> Length: 9841 (9.6K) [application/octet-stream]
>>>>> Saving to: `binglLqkeq4Rj.bin''
>>>>>
>>>>>
100%[======================================================================>]
9,841 24.3K/s in 0.4s
>>>>>
>>>>> 2009-08-28 23:21:36 (24.3 KB/s) -
`binglLqkeq4Rj.bin'' saved [9841/9841]
>>>>>
>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv
binglLqkeq4Rj.bin qemu-gfx-passthrough.patch
>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi
qemu-gfx-passthrough.patch
>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find .
-name hw
>>>>> ./tools/ioemu-remote/hw
>>>>> ./.hg/store/data/tools/ioemu/hw
>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv
qemu-gfx-passthrough.patch tools/ioemu-remote/
>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cd
tools/ioemu-remote/
>>>>> [root@fedora11-x86-64-host ioemu-remote]# patch -p1<
qemu-
>>>>> qemu-aio.h qemu-img.c
qemu-sockets.c
>>>>> qemu-binfmt-conf.sh qemu-img.texi
qemu-tech.texi
>>>>> qemu-char.c qemu-lock.h
qemu-timer.h
>>>>> qemu-char.h qemu-log.h
qemu-tool.c
>>>>> qemu-common.h qemu-malloc.c
qemu-xen.h
>>>>> qemu-doc.texi qemu-nbd.c
>>>>> qemu-gfx-passthrough.patch qemu-nbd.texi
>>>>> [root@fedora11-x86-64-host ioemu-remote]# patch -p1<
qemu-gfx-passthrough.patch
>>>>> patching file hw/pass-through.c
>>>>> patching file hw/pass-through.h
>>>>> patching file hw/pc.c
>>>>> patching file vl.c
>>>>> [root@fedora11-x86-64-host ioemu-remote]# cd ..
>>>>> [root@fedora11-x86-64-host tools]# cd ..
>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi
intel-gfx-passthru-patch-3.patch
>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch
-p1< intel-gfx-passthru-patch-3.patch
>>>>> patching file tools/firmware/hvmloader/Makefile
>>>>> Hunk #1 FAILED at 50.
>>>>> 1 out of 1 hunk FAILED -- saving rejects to file
tools/firmware/hvmloader/Makefile.rej
>>>>> patching file tools/firmware/hvmloader/hvmloader.c
>>>>> patch: **** malformed patch at line 24:
sizeof(vgabios_pt));
>>>>>
>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi
intel-gfx-passthru-patch-3.patch
>>>>>
>>>>> For everybody''s convenience, I have attached
intel-gfx-passthru-patch-3.patch and the firmware for my nVidia GeForce 8400 GS
PCI Express x16 graphics card in this email.
>>>>>
>>>>> Please help me complete intel-gfx-passthru-patch-3.patch as
I really need it.
>>>>>
>>>>> Thank you very much!!!
>>>>>
>>>>> --
>>>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics
Engineering) BEng(Hons)(Mechanical Engineering)
>>>>> Technical Support Engineer
>>>>> Information Technology Department
>>>>> Asiasoft Online Pte Ltd
>>>>> Tampines Central 1 #04-01 Tampines Plaza
>>>>> Singapore 529541
>>>>> Republic of Singapore
>>>>> Mobile: +65-9648-9798
>>>>> MSN:teoenming@hotmail.com
<mailto:teoenming@hotmail.com>
>>>>> Alma Maters: Singapore Polytechnic, National University of
Singapore
>>>>>
>>>>> This patch supports basic gfx passthrough on QEMU:
>>>>>
>>>>> - disable emulated VGA adpater if there is
passthroughed gfx
>>>>>
>>>>> - register/unregister legacy VGA I/O ports and MMIOs
for passthroughed gfx
>>>>>
>>>>>
>>>>>
>>>>> Signed-off-by: Ben Lin<ben.y.lin@intel.com>
<mailto:ben.y.lin@intel.com>
>>>>>
>>>>> Signed-off-by: Weidong Han<weidong.han@intel.com>
<mailto:weidong.han@intel.com>
>>>>>
>>>>> No virus found in this incoming message.
>>>>>
>>>>> Checked by AVG -www.avg.com <http://www.avg.com>
>>>>>
>>>>> Version: 8.5.409 / Virus Database: 270.13.69/2328 -
Release Date: 08/27/09
>>>>>
>>>>> 18:02:00
>>>>>
>>>>>
>>>>>
>>>>> No virus found in this outgoing message.
>>>>>
>>>>> Checked by AVG -www.avg.com <http://www.avg.com>
>>>>>
>>>>> Version: 8.5.409 / Virus Database: 270.13.71/2330 -
Release Date: 08/27/09
>>>>>
>>>>> 18:02:00
>>>>>
>>>>>
>>>>>
>>>>>
------------------------------------------------------------------------
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>> Xen-devel mailing list
>>>>>
>>>>> Xen-devel@lists.xensource.com
<mailto:Xen-devel@lists.xensource.com>
>>>>>
>>>>> http://lists.xensource.com/xen-devel
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
------------------------------------------------------------------------
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Xen-devel mailing list
>>>>> Xen-devel@lists.xensource.com
<mailto: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
>>>>
>>>
>>>
>>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Mr. Teo En Ming (Zhang Enming)
2009-Aug-29 13:20 UTC
Re: [Xen-devel] graphics passthrough with VT-d
Dear All, I have applied the following patches to xen 3.5-unstable 1) intel-gfx-passthru-patch01.patch 2) intel-gfx-passthru-patch02.patch 3) intel-gfx-passthru-patch03.patch 4) enming-patch04.patch and compiled xen 3.5-unstable successfully (both hypervisor and tools). i rebooted into this newly compiled Xen hypervisor which supports loading vga bios from firmware file of nVidia Geforce 8400 GS PCI Express x16. After dom0 has booted up, I executed the following script to hide nVidia Geforce 8400 GS from dom0. [enming@fedora11-x86-64-host scripts]$ cat bind-devices-pci-stub.sh #!/bin/sh echo "10de 06e4" > /sys/bus/pci/drivers/pci-stub/new_id echo "0000:01:00.0" > /sys/bus/pci/devices/0000:01:00.0/driver/unbind echo "0000:01:00.0" > /sys/bus/pci/drivers/pci-stub/bind I also assigned the nVidia Geforce 8400 GS to my Windows XP Home HVM domU. pci = [ ''01:00.0'' ] I also specified gfx_passthru=2. Do note that I booted up with onboard Intel GMA4500 as the primary video adapter. Hence dom 0 has onboard graphics and Windows XP HVM domU has nvidia graphics. Then I started Windows XP Home HVM DomU. Very soon, my Dom 0''s display was garbaged and X server on Dom 0 totally froze and became unresponsive. I cannot switch to any ttys. However, I was still able to vnc into my Windows XP Home HVM Dom U. I had earlier installed a VNC server into my Windows XP guest. After remoting in to my Windows XP DomU through vnc, I found that NVIDIA Geforce 8400 GS cannot be initialized and no resources are available for this graphics card. -- Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) Technical Support Engineer Information Technology Department Asiasoft Online Pte Ltd Tampines Central 1 #04-01 Tampines Plaza Singapore 529541 Republic of Singapore Company Website: http://www.asiasoft.sg/ Mobile: +65-9648-9798 MSN: teoenming@hotmail.com Alma Maters: Singapore Polytechnic, National University of Singapore On 08/29/2009 08:25 PM, Mr. Teo En Ming (Zhang Enming) wrote:> Hi All, > > I have solved the problem encountered below when building tools for > xen 3.5-unstable. The compile problem exists because I downloaded and > compiled the latest version of Intel ACPI Component Architecture > compiler version 20090730. And I used this latest compiler during > "make tools" for xen-unstable. > > In original xen-unstable source codes cloned from xensoure mercurial > repository, the header files ssdt_pm.h and ssdt_tpm.h in source > directory tools/firmware/hvmloader/acpi/ are generated by > > /* > * > * Intel ACPI Component Architecture > * ASL Optimizing Compiler version 20061109 [May 18 2007] > * Copyright (C) 2000 - 2006 Intel Corporation > * Supports ACPI Specification Revision 3.0a > * > * Compilation of "ssdt_pm.asl" - Sun Oct 12 23:57:51 2008 > * > * C source code output > * > */ > > In original ssdt_pm.h, it has "unsigned char AmlCode_PM[] =". > > In original ssdt_tpm.h, it has "unsigned char AmlCode_TPM[] =". > > Hence there was no problem with "make tools". > > But, I downloaded, compiled and used > > /* > * > * Intel ACPI Component Architecture > * ASL Optimizing Compiler version 20090730 [Aug 29 2009] > * Copyright (C) 2000 - 2009 Intel Corporation > * Supports ACPI Specification Revision 4.0 > * > * Compilation of "ssdt_pm.asl" - Sat Aug 29 18:55:40 2009 > * > * C source code output > * > */ > > So the *new* ssdt_pm.h contains: > > /* > * > * Intel ACPI Component Architecture > * ASL Optimizing Compiler version 20090730 [Aug 29 2009] > * Copyright (C) 2000 - 2009 Intel Corporation > * Supports ACPI Specification Revision 4.0 > * > * Compilation of "ssdt_pm.asl" - Sat Aug 29 18:55:40 2009 > * > * C source code output > * > */ > unsigned char AmlCode[] > { > 0x53,0x53,0x44,0x54,0xD6,0x05,0x00,0x00, /* 00000000 "SSDT...." */ > 0x02,0xB9,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008 "..Xen..." */ > 0x48,0x56,0x4D,0x00,0x00,0x00,0x00,0x00, /* 00000010 "HVM....." */ > 0x00,0x00,0x00,0x00,0x49,0x4E,0x54,0x4C, /* 00000018 "....INTL" */ > 0x30,0x07,0x09,0x20,0x10,0x41,0x5B,0x5C, /* 00000020 "0.. .A[\" */ > 0x5F,0x53,0x42,0x5F,0x5B,0x80,0x44,0x42, /* 00000028 "_SB_[.DB" */ > 0x47,0x41,0x01,0x0B,0x40,0xB0,0x01,0x5B, /* 00000030 "GA..@..[" */ > 0x81,0x0B,0x44,0x42,0x47,0x41,0x01,0x44, /* 00000038 "..DBGA.D" */ > 0x42,0x47,0x31,0x08,0x5B,0x80,0x44,0x42, /* 00000040 "BG1.[.DB" */ > 0x47,0x42,0x01,0x0B,0x44,0xB0,0x01,0x5B, /* 00000048 "GB..D..[" */ > 0x81,0x0B,0x44,0x42,0x47,0x42,0x01,0x44, /* 00000050 "..DBGB.D" */ > 0x42,0x47,0x32,0x08,0x5B,0x80,0x44,0x42, /* 00000058 "BG2.[.DB" */ > 0x47,0x43,0x01,0x0B,0x46,0xB0,0x01,0x5B, /* 00000060 "GC..F..[" */ > 0x81,0x0B,0x44,0x42,0x47,0x43,0x01,0x44, /* 00000068 "..DBGC.D" */ > 0x42,0x47,0x33,0x08,0x5B,0x80,0x44,0x42, /* 00000070 "BG3.[.DB" */ > 0x47,0x44,0x01,0x0B,0x48,0xB0,0x01,0x5B, /* 00000078 "GD..H..[" */ > 0x81,0x0B,0x44,0x42,0x47,0x44,0x01,0x44, /* 00000080 "..DBGD.D" */ > 0x42,0x47,0x34,0x08,0x5B,0x80,0x50,0x52, /* 00000088 "BG4.[.PR" */ > 0x54,0x31,0x01,0x0A,0xB2,0x0A,0x02,0x5B, /* 00000090 "T1.....[" */ > 0x81,0x10,0x50,0x52,0x54,0x31,0x01,0x50, /* 00000098 "..PRT1.P" */ > 0x42,0x32,0x5F,0x08,0x50,0x42,0x32,0x41, /* 000000A0 "B2_.PB2A" */ > 0x08,0x5B,0x80,0x50,0x52,0x54,0x32,0x01, /* 000000A8 ".[.PRT2." */ > 0x0A,0x86,0x01,0x5B,0x81,0x0B,0x50,0x52, /* 000000B0 "...[..PR" */ > 0x54,0x32,0x01,0x50,0x38,0x36,0x5F,0x08, /* 000000B8 "T2.P86_." */ > 0x5B,0x80,0x50,0x52,0x54,0x33,0x01,0x0A, /* 000000C0 "[.PRT3.." */ > 0x88,0x01,0x5B,0x81,0x0B,0x50,0x52,0x54, /* 000000C8 "..[..PRT" */ > 0x33,0x01,0x50,0x38,0x38,0x5F,0x08,0x5B, /* 000000D0 "3.P88_.[" */ > 0x01,0x53,0x59,0x4E,0x43,0x01,0x08,0x42, /* 000000D8 ".SYNC..B" */ > 0x55,0x46,0x30,0x11,0x04,0x0B,0x00,0x01, /* 000000E0 "UF0....." */ > 0x08,0x42,0x55,0x46,0x31,0x11,0x03,0x0A, /* 000000E8 ".BUF1..." */ > 0x08,0x8B,0x42,0x55,0x46,0x31,0x00,0x42, /* 000000F0 "..BUF1.B" */ > 0x55,0x46,0x41,0x8B,0x42,0x55,0x46,0x31, /* 000000F8 "UFA.BUF1" */ > 0x0A,0x04,0x42,0x55,0x46,0x42,0x14,0x14, /* 00000100 "..BUFB.." */ > > And the *new* ssdt_tpm.h contains: > > /* > * > * Intel ACPI Component Architecture > * ASL Optimizing Compiler version 20090730 [Aug 29 2009] > * Copyright (C) 2000 - 2009 Intel Corporation > * Supports ACPI Specification Revision 4.0 > * > * Compilation of "ssdt_tpm.asl" - Sat Aug 29 18:55:40 2009 > * > * C source code output > * > */ > unsigned char AmlCode[] > { > 0x53,0x53,0x44,0x54,0x4C,0x00,0x00,0x00, /* 00000000 "SSDTL..." */ > 0x02,0x2A,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008 ".*Xen..." */ > 0x48,0x56,0x4D,0x00,0x00,0x00,0x00,0x00, /* 00000010 "HVM....." */ > 0x00,0x00,0x00,0x00,0x49,0x4E,0x54,0x4C, /* 00000018 "....INTL" */ > 0x30,0x07,0x09,0x20,0x5B,0x82,0x26,0x54, /* 00000020 "0.. [.&T" */ > 0x50,0x4D,0x5F,0x08,0x5F,0x48,0x49,0x44, /* 00000028 "PM_._HID" */ > 0x0C,0x41,0xD0,0x0C,0x31,0x08,0x5F,0x43, /* 00000030 ".A..1._C" */ > 0x52,0x53,0x11,0x11,0x0A,0x0E,0x86,0x09, /* 00000038 "RS......" */ > 0x00,0x01,0x00,0x00,0xD4,0xFE,0x00,0x50, /* 00000040 ".......P" */ > 0x00,0x00,0x79,0x00, > }; > > which are both wrong. > > In ssdt_pm.h, I have to change "unsigned char AmlCode[]" to "unsigned > char AmlCode_PM[]". > > In ssdt_tpm.h, I have to change "unsigned char AmlCode[]" to "unsigned > char AmlCode_TPM[]". > > Then "make tools" is able to complete successfully. > > I have created a patch for anybody who may be using the *latest* > version of Intel ACPI CA compiler version 20090730 and attached it here. > > Patch file filename enming-patch04.patch: > > <CODE> > > Patch created by Teo En Ming (Zhang Enming) on 29 August 2009 Saturday > at 8:00 P.M. Singapore Time > Email #1: enming.teo@asiasoftsea.net > Email #2: space.time.universe@gmail.com > MSN: teoenming@hotmail.com > Mobile Phone: +65-9648-9798 > > --- ssdt_pm.h 2009-08-29 19:54:52.653088000 +0800 > +++ ssdt_pm.h 2009-08-29 19:56:51.813088550 +0800 > @@ -10,7 +10,7 @@ > * C source code output > * > */ > -unsigned char AmlCode[] > +unsigned char AmlCode_PM[] > { > 0x53,0x53,0x44,0x54,0xD6,0x05,0x00,0x00, /* 00000000 > "SSDT...." */ > 0x02,0xB9,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008 > "..Xen..." */ > --- ssdt_tpm.h 2009-08-29 19:55:44.578738954 +0800 > +++ ssdt_tpm.h 2009-08-29 19:57:27.896638884 +0800 > @@ -10,7 +10,7 @@ > * C source code output > * > */ > -unsigned char AmlCode[] > +unsigned char AmlCode_TPM[] > { > 0x53,0x53,0x44,0x54,0x4C,0x00,0x00,0x00, /* 00000000 > "SSDTL..." */ > 0x02,0x2A,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008 > ".*Xen..." */ > > </CODE> > > -- > Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) > Technical Support Engineer > Information Technology Department > Asiasoft Online Pte Ltd > Tampines Central 1 #04-01 Tampines Plaza > Singapore 529541 > Republic of Singapore > Company Website:http://www.asiasoft.sg/ > Mobile: +65-9648-9798 > MSN:teoenming@hotmail.com > Alma Maters: Singapore Polytechnic, National University of Singapore > > > On 08/29/2009 07:03 PM, Mr. Teo En Ming (Zhang Enming) wrote: >> Hi, >> >> I clonedhttp://xenbits.xensource.com/xen-unstable.hg again today. I tried applying the three Intel gfx passthrough patches to xen-unstable. When I "make tools", I get the same error again: >> >> make[7]: Entering directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader'' >> make -C acpi all >> get-path: will use #!/usr/bin/python2.6 for python programs >> make[8]: Entering directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' >> make iasl >> get-path: will use #!/usr/bin/python2.6 for python programs >> make[9]: Entering directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' >> make[9]: `/usr/local/bin/iasl'' is up to date. >> make[9]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' >> iasl -tc ssdt_tpm.asl >> >> Intel ACPI Component Architecture >> ASL Optimizing Compiler version 20090730 [Aug 29 2009] >> Copyright (C) 2000 - 2009 Intel Corporation >> Supports ACPI Specification Revision 4.0 >> >> ASL Input: ssdt_tpm.asl - 31 lines, 1111 bytes, 3 keywords >> AML Output: SSDT_TPM.aml - 76 bytes, 3 named objects, 0 executable opcodes >> >> Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 0 Optimizations >> mv ssdt_tpm.hex ssdt_tpm.h >> rm -f *.aml >> make iasl >> get-path: will use #!/usr/bin/python2.6 for python programs >> make[9]: Entering directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' >> make[9]: `/usr/local/bin/iasl'' is up to date. >> make[9]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' >> iasl -tc ssdt_pm.asl >> >> Intel ACPI Component Architecture >> ASL Optimizing Compiler version 20090730 [Aug 29 2009] >> Copyright (C) 2000 - 2009 Intel Corporation >> Supports ACPI Specification Revision 4.0 >> >> ASL Input: ssdt_pm.asl - 425 lines, 12754 bytes, 192 keywords >> AML Output: SSDT_PM.aml - 1494 bytes, 64 named objects, 128 executable opcodes >> >> Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 31 Optimizations >> mv ssdt_pm.hex ssdt_pm.h >> rm -f *.aml >> gcc -O1 -fno-omit-frame-pointer -fno-optimize-sibling-calls -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .build.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs -Werror -fno-stack-protector -fno-builtin -msoft-float -I. -I.. -I../../../../tools/include -c -o build.o build.c >> In file included from build.c:21: >> ssdt_pm.h:13: error: redefinition of ''AmlCode'' >> ssdt_tpm.h:13: note: previous definition of ''AmlCode'' was here >> build.c: In function ''construct_secondary_tables'': >> build.c:184: error: ''AmlCode_PM'' undeclared (first use in this function) >> build.c:184: error: (Each undeclared identifier is reported only once >> build.c:184: error: for each function it appears in.) >> build.c:194: error: ''AmlCode_TPM'' undeclared (first use in this function) >> make[8]: *** [build.o] Error 1 >> make[8]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' >> make[7]: *** [subdir-all-acpi] Error 2 >> make[7]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader'' >> make[6]: *** [subdirs-all] Error 2 >> make[6]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader'' >> make[5]: *** [subdir-all-hvmloader] Error 2 >> make[5]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware'' >> make[4]: *** [subdirs-all] Error 2 >> make[4]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware'' >> make[3]: *** [all] Error 2 >> make[3]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware'' >> make[2]: *** [subdir-install-firmware] Error 2 >> make[2]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools'' >> make[1]: *** [subdirs-install] Error 2 >> make[1]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools'' >> make: *** [install-tools] Error 2 >> >> Any ideas about this Advanced Configuration and Power Interface code? >> >> -- >> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >> Technical Support Engineer >> Information Technology Department >> Asiasoft Online Pte Ltd >> Tampines Central 1 #04-01 Tampines Plaza >> Singapore 529541 >> Republic of Singapore >> Company Website:http://www.asiasoft.sg/ >> Mobile: +65-9648-9798 >> MSN:teoenming@hotmail.com >> Alma Maters: Singapore Polytechnic, National University of Singapore >> >> >> On 08/29/2009 02:58 PM, Mr. Teo En Ming (Zhang Enming) wrote: >>> Hi >>> >>> Anybody available today? I know it''s Saturday. :-) >>> >>> -- >>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>> Technical Support Engineer >>> Information Technology Department >>> Asiasoft Online Pte Ltd >>> Tampines Central 1 #04-01 Tampines Plaza >>> Singapore 529541 >>> Republic of Singapore >>> Company Website:http://www.asiasoft.sg/ >>> Mobile: +65-9648-9798 >>> MSN:teoenming@hotmail.com >>> Alma Maters: Singapore Polytechnic, National University of Singapore >>> >>> >>> On 08/29/2009 11:48 AM, Mr. Teo En Ming (Zhang Enming) wrote: >>>> >>>> Dear All, >>>> >>>> After applying Intel VGA passthrough patches 1, 2 and 3, I have no problems with "make xen", and "make install-xen". However, I have errors with "make tools". >>>> >>>> Here is the error output: >>>> >>>> msoft-float -I. -I.. -I../../../../tools/include -c -o build.o build.c >>>> build.c: In function ''construct_secondary_tables'': >>>> build.c:194: error: ''AmlCode_TPM'' undeclared (first use in this function) >>>> build.c:194: error: (Each undeclared identifier is reported only once >>>> build.c:194: error: for each function it appears in.) >>>> make[8]: *** [build.o] Error 1 >>>> make[8]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader/acpi'' >>>> make[7]: *** [subdir-all-acpi] Error 2 >>>> make[7]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader'' >>>> make[6]: *** [subdirs-all] Error 2 >>>> make[6]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader'' >>>> make[5]: *** [subdir-all-hvmloader] Error 2 >>>> make[5]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'' >>>> make[4]: *** [subdirs-all] Error 2 >>>> make[4]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'' >>>> make[3]: *** [all] Error 2 >>>> make[3]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'' >>>> make[2]: *** [subdir-install-firmware] Error 2 >>>> make[2]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools'' >>>> make[1]: *** [subdirs-install] Error 2 >>>> make[1]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools'' >>>> make: *** [install-tools] Error 2 >>>> >>>> There is an undeclared identifier in tools/firmware/hvmloader/acpi/build.c source code. Could you guys help me resolve this issue? >>>> >>>> I had no problems compiling xen 3.5-unstable before applying the Intel vga passthrough patches and before installing the Intel ACPI Component Architecture compiler. >>>> >>>> I have also attached Intel graphics passthrough patches 1, 2 and 3 for your convenience here. >>>> >>>> Thank you very much. >>>> >>>> Hope I can get this working during the weekends. >>>> >>>> -- >>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>>> Technical Support Engineer >>>> Information Technology Department >>>> Asiasoft Online Pte Ltd >>>> Tampines Central 1 #04-01 Tampines Plaza >>>> Singapore 529541 >>>> Republic of Singapore >>>> Company Website:http://www.asiasoft.sg/ >>>> Mobile: +65-9648-9798 >>>> MSN:teoenming@hotmail.com >>>> Alma Maters: Singapore Polytechnic, National University of Singapore >>>> >>>> >>>> On 08/29/2009 10:17 AM, Mr. Teo En Ming (Zhang Enming) wrote: >>>>> Hi Tim, >>>>> >>>>> I thought it should be gfx_passthru=2 in domU config? >>>>> -- >>>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>>>> Technical Support Engineer >>>>> Information Technology Department >>>>> Asiasoft Online Pte Ltd >>>>> Tampines Central 1 #04-01 Tampines Plaza >>>>> Singapore 529541 >>>>> Republic of Singapore >>>>> Mobile: +65-9648-9798 >>>>> MSN:teoenming@hotmail.com >>>>> Alma Maters: Singapore Polytechnic, National University of Singapore >>>>> >>>>> >>>>> On 08/29/2009 06:42 AM, Tim Moore wrote: >>>>>> >>>>>> Teo, >>>>>> >>>>>> I have also performed the same exercise as yourself and I now >>>>>> have successfully compiled all 3x patches into Xen, Qemu and the >>>>>> BIOS File Loading in the hvmloader, this all compiles find on my >>>>>> system. Suggest you do a "make clean" on the tools and start again ! >>>>>> >>>>>> After booting with the patched xen-unstable and adding the >>>>>> gfx-passthru=1 parameter to my HVM DomU, as I suspected - it >>>>>> still doesn''t work. >>>>>> >>>>>> I have both a 9500GT and GTX260(primary) in my Intel DX58SO >>>>>> machine, tried passing through either device and my primary >>>>>> display locks up ! (included hiding with pci-stub) >>>>>> >>>>>> I verified that the DomU was functional beforehand, as It also >>>>>> booted successfully without the gfx-passthru parameter (and a >>>>>> vncviewer/cirrus display) >>>>>> >>>>>> Unfortunately, I can''t debug further as my Primary display >>>>>> corrupts as soon as the DomU starts. I did notice that in "xm >>>>>> debug" the "Loading Gfx BIOS File.." message was displayed and >>>>>> the DomU did continue to initialise the BIOS tables and such >>>>>> before finally locking. I then (blindly) typed on a corrupt Dom0 >>>>>> console and managed to start kdm and login, so the Dom0 was not >>>>>> completely trashed. But then after a few minutes, the machine >>>>>> totally froze and had to hit the reset switch. >>>>>> >>>>>> I`m no specialist but this looks like the VGA BIOS >>>>>> Re-initialisation is playing havoc with the DomU and possibly the >>>>>> Dom0 graphics. I notice that both are also using IRQ11 which >>>>>> could play a major part. Furthermore, there was a lot of debug >>>>>> output in the qemu and xend.log indicating Base Address Register >>>>>> invalid access and therefore it seems there may be a second obstacle. >>>>>> >>>>>> Hope you have a better success than me ! >>>>>> >>>>>> For now, I would try re-compiling a fresh xen-unstable with >>>>>> carefully applied patches .. oh! and don''t forget to enable the >>>>>> pci-stub driver for Dom0 (it''s not selected by default) >>>>>> >>>>>> Tim >>>>>> >>>>>> *From:* xen-devel-bounces@lists.xensource.com >>>>>> [mailto:xen-devel-bounces@lists.xensource.com] *On Behalf Of *Mr. >>>>>> Teo En Ming (Zhang Enming) >>>>>> *Sent:* 28 August 2009 21:14 >>>>>> *To:* enming.teo@asiasoftsea.net >>>>>> *Cc:* xen-devel@lists.xensource.com; ''Lin, Ben Y''; ''Kay, Allen >>>>>> M''; ''Jean Guyader''; Keir.Fraser@eu.citrix.com; >>>>>> weidong.han@intel.com; bengheng@eecs.umich.edu >>>>>> *Subject:* Re: [Xen-devel] [PATCH 2/2] graphics passthrough with VT-d >>>>>> >>>>>> After applying the 1st and 2nd patch to xen-unstable successfully, I examined the source codes Makefile and hvmloader.c in tools/firmware/hvmloader, compared them to Weidong''s 3rd patch and I generated my own 3rd patch. Then I used my own generated 3rd patch to apply patching for loading vga bios from firmware file. >>>>>> >>>>>> Here is my own generated 3rd patch instead of using Weidong''s 3rd patch: >>>>>> >>>>>> --- Makefile 2009-08-29 03:24:52.413083774 +0800 >>>>>> +++ Makefile 2009-08-29 03:29:12.763299633 +0800 >>>>>> @@ -50,6 +50,7 @@ >>>>>> roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \ >>>>>> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h >>>>>> sh ./mkhex rombios ../rombios/BIOS-bochs-latest> roms.h >>>>>> + sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin>> roms.h >>>>>> sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin>> roms.h >>>>>> sh ./mkhex vgabios_cirrusvga \ >>>>>> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin>> roms.h >>>>>> --- hvmloader.c 2009-08-29 03:26:06.911085797 +0800 >>>>>> +++ hvmloader.c 2009-08-29 03:31:43.172084995 +0800 >>>>>> @@ -688,9 +688,9 @@ >>>>>> vgabios_sz = round_option_rom(sizeof(vgabios_stdvga)); >>>>>> break; >>>>>> case VGA_pt: >>>>>> - printf("Loading VGABIOS of passthroughed gfx ...\n"); >>>>>> - vgabios_sz >>>>>> - round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512); >>>>>> + printf("Loading Gfx Video BIOS from file ...\n"); >>>>>> + memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt, sizeof(vgabios_pt)); >>>>>> + vgabios_sz = round_option_rom(sizeof(vgabios_pt)); >>>>>> break; >>>>>> default: >>>>>> printf("No emulated VGA adaptor ...\n"); >>>>>> >>>>>> >>>>>> I can "make xen" successfully but when I proceeded to "make tools", errors were encountered. >>>>>> >>>>>> Please see attached error output. How can I solve this problem? >>>>>> >>>>>> >>>>>> -- >>>>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>>>>> Technical Support Engineer >>>>>> Information Technology Department >>>>>> Asiasoft Online Pte Ltd >>>>>> Tampines Central 1 #04-01 Tampines Plaza >>>>>> Singapore 529541 >>>>>> Republic of Singapore >>>>>> Mobile: +65-9648-9798 >>>>>> MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> >>>>>> Alma Maters: Singapore Polytechnic, National University of Singapore >>>>>> >>>>>> >>>>>> >>>>>> On 08/29/2009 12:59 AM, Mr. Teo En Ming (Zhang Enming) wrote: >>>>>> >>>>>> OK I believe the 3rd patch is not incomplete but there''s a white space issue when I copied the code from the mailing list into my vi. >>>>>> >>>>>> Seehttp://www.htdig.org/mail/2000/11/0167.html >>>>>> >>>>>> When I used the -l flag to patch using the 3rd patch, the number of errors was reduced. >>>>>> >>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -l -p1< intel-gfx-passthru-patch-3.patch >>>>>> patching file tools/firmware/hvmloader/Makefile >>>>>> patching file tools/firmware/hvmloader/hvmloader.c >>>>>> Hunk #1 FAILED at 688. >>>>>> 1 out of 1 hunk FAILED -- saving rejects to file tools/firmware/hvmloader/hvmloader.c.rej >>>>>> >>>>>> Now patching tools/firmware/hvmloader/Makefile is successful but patching tools/firmware/hvmloader/hvmloader.c still failed. >>>>>> >>>>>> -- >>>>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>>>>> Technical Support Engineer >>>>>> Information Technology Department >>>>>> Asiasoft Online Pte Ltd >>>>>> Tampines Central 1 #04-01 Tampines Plaza >>>>>> Singapore 529541 >>>>>> Republic of Singapore >>>>>> Mobile: +65-9648-9798 >>>>>> MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> >>>>>> Alma Maters: Singapore Polytechnic, National University of Singapore >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 08/28/2009 11:55 PM, Mr. Teo En Ming (Zhang Enming) wrote: >>>>>> >>>>>> Dear Weidong, >>>>>> >>>>>> A big big thanks for the vga passthrough patches for xen >>>>>> 3.5-unstable!!! These are eagerly anticipated patches. As I did >>>>>> not study computer science and computer architecture, I won''t be >>>>>> able to write those patches you guys at Intel wrote. >>>>>> >>>>>> I applied the following patches *xen-gfx-passthrough.patch >>>>>> <http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin> >>>>>> and qemu-gfx-passthrough.patch >>>>>> <http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin> >>>>>> to xen 3.5-unstable without issues.* >>>>>> >>>>>> Then I tried to apply the 3rd patch you provided at >>>>>> http://lists.xensource.com/archives/html/xen-devel/2009-08/msg01047.html >>>>>> >>>>>> I saved the following code >>>>>> >>>>>> <CODE> >>>>>> >>>>>> diff -r 494be76c1ad9 tools/firmware/hvmloader/Makefile >>>>>> --- a/tools/firmware/hvmloader/Makefile Thu Aug 27 16:54:33 2009 +0800 >>>>>> +++ b/tools/firmware/hvmloader/Makefile Thu Aug 27 17:22:01 2009 +0800 >>>>>> @@ -50,6 +50,7 @@ roms.h: ../rombios/BIOS-bochs-latest ../ >>>>>> roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \ >>>>>> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h >>>>>> sh ./mkhex rombios ../rombios/BIOS-bochs-latest> roms.h >>>>>> + sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin>> roms.h >>>>>> sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin>> roms.h >>>>>> sh ./mkhex vgabios_cirrusvga \ >>>>>> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin>> roms.h >>>>>> diff -r 494be76c1ad9 tools/firmware/hvmloader/hvmloader.c >>>>>> --- a/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 16:54:33 2009 +0800 >>>>>> +++ b/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 17:23:00 2009 +0800 >>>>>> @@ -688,9 +688,9 @@ int main(void) >>>>>> vgabios_sz = round_option_rom(sizeof(vgabios_stdvga)); >>>>>> break; >>>>>> case VGA_pt: >>>>>> - printf("Loading Gfx Video BIOS from 0xC0000 ...\n"); >>>>>> - vgabios_sz >>>>>> - round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512); >>>>>> + printf("Loading Gfx Video BIOS from file ...\n"); >>>>>> + memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt, >>>>>> sizeof(vgabios_pt)); >>>>>> + vgabios_sz = round_option_rom(sizeof(vgabios_pt)); >>>>>> break; >>>>>> default: >>>>>> printf("No emulated VGA adaptor ...\n"); >>>>>> >>>>>> </CODE> >>>>>> >>>>>> as intel-gfx-passthru-patch-3.patch and then I tried to apply the patch to xen 3.5-unstable. I got errors. I think it''s because the 3rd patch you provided is incomplete. >>>>>> >>>>>> Here''s my patching process: >>>>>> >>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name vgabios >>>>>> ./tools/firmware/vgabios >>>>>> ./.hg/store/data/tools/firmware/vgabios >>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cp ~enming/vgabios-pt.bin tools/firmware/vgabios/ >>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ls tools/firmware/vgabios/ >>>>>> biossums.c clext.c Makefile TODO vbe.h vgabios.h vgatables.h >>>>>> BUGS COPYING Notes vbe.c vbetables-gen.c vgabios-pt.bin >>>>>> ChangeLog dataseghack README vbe_display_api.txt vgabios.c vgafonts.h >>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# pwd >>>>>> /usr/src/xen-unstable.hg-vgapt >>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wgethttp://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin >>>>>> --2009-08-28 23:18:21--http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin >>>>>> Resolving lists.xensource.com... 70.42.241.110 >>>>>> Connecting to lists.xensource.com|70.42.241.110|:80... connected. >>>>>> HTTP request sent, awaiting response... 200 OK >>>>>> Length: 12565 (12K) [application/octet-stream] >>>>>> Saving to: `bincPiiAf0QWg.bin'' >>>>>> >>>>>> 100%[======================================================================>] 12,565 30.7K/s in 0.4s >>>>>> >>>>>> 2009-08-28 23:18:22 (30.7 KB/s) - `bincPiiAf0QWg.bin'' saved [12565/12565] >>>>>> >>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv bincPiiAf0QWg.bin xen-gfx-passthrough.patch >>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi xen-gfx-passthrough.patch >>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch< xen-gfx-passthrough.patch >>>>>> can''t find file to patch at input line 4 >>>>>> Perhaps you should have used the -p or --strip option? >>>>>> The text leading up to this was: >>>>>> -------------------------- >>>>>> |diff -r 5d7e7a250267 tools/firmware/hvmloader/config.h >>>>>> |--- a/tools/firmware/hvmloader/config.h Wed Aug 26 18:28:44 2009 +0800 >>>>>> |+++ b/tools/firmware/hvmloader/config.h Thu Aug 27 16:54:24 2009 +0800 >>>>>> -------------------------- >>>>>> File to patch: ^C >>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ex xen-gfx-passthrough.patch >>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1< xen-gfx-passthrough.patch >>>>>> patching file tools/firmware/hvmloader/config.h >>>>>> patching file tools/firmware/hvmloader/hvmloader.c >>>>>> patching file tools/libxc/ia64/xc_ia64_hvm_build.c >>>>>> patching file tools/libxc/xc_hvm_build.c >>>>>> patching file tools/libxc/xc_linux.c >>>>>> patching file tools/libxc/xenctrl.h >>>>>> patching file tools/libxc/xenguest.h >>>>>> patching file tools/python/xen/lowlevel/xc/xc.c >>>>>> patching file tools/python/xen/xend/XendConfig.py >>>>>> Hunk #1 succeeded at 174 (offset -1 lines). >>>>>> patching file tools/python/xen/xend/image.py >>>>>> Hunk #1 succeeded at 780 (offset -6 lines). >>>>>> Hunk #3 succeeded at 895 (offset -6 lines). >>>>>> patching file tools/python/xen/xm/create.py >>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wgethttp://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin >>>>>> --2009-08-28 23:21:35--http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin >>>>>> Resolving lists.xensource.com... 70.42.241.110 >>>>>> Connecting to lists.xensource.com|70.42.241.110|:80... connected. >>>>>> HTTP request sent, awaiting response... 200 OK >>>>>> Length: 9841 (9.6K) [application/octet-stream] >>>>>> Saving to: `binglLqkeq4Rj.bin'' >>>>>> >>>>>> 100%[======================================================================>] 9,841 24.3K/s in 0.4s >>>>>> >>>>>> 2009-08-28 23:21:36 (24.3 KB/s) - `binglLqkeq4Rj.bin'' saved [9841/9841] >>>>>> >>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv binglLqkeq4Rj.bin qemu-gfx-passthrough.patch >>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi qemu-gfx-passthrough.patch >>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name hw >>>>>> ./tools/ioemu-remote/hw >>>>>> ./.hg/store/data/tools/ioemu/hw >>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv qemu-gfx-passthrough.patch tools/ioemu-remote/ >>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cd tools/ioemu-remote/ >>>>>> [root@fedora11-x86-64-host ioemu-remote]# patch -p1< qemu- >>>>>> qemu-aio.h qemu-img.c qemu-sockets.c >>>>>> qemu-binfmt-conf.sh qemu-img.texi qemu-tech.texi >>>>>> qemu-char.c qemu-lock.h qemu-timer.h >>>>>> qemu-char.h qemu-log.h qemu-tool.c >>>>>> qemu-common.h qemu-malloc.c qemu-xen.h >>>>>> qemu-doc.texi qemu-nbd.c >>>>>> qemu-gfx-passthrough.patch qemu-nbd.texi >>>>>> [root@fedora11-x86-64-host ioemu-remote]# patch -p1< qemu-gfx-passthrough.patch >>>>>> patching file hw/pass-through.c >>>>>> patching file hw/pass-through.h >>>>>> patching file hw/pc.c >>>>>> patching file vl.c >>>>>> [root@fedora11-x86-64-host ioemu-remote]# cd .. >>>>>> [root@fedora11-x86-64-host tools]# cd .. >>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi intel-gfx-passthru-patch-3.patch >>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1< intel-gfx-passthru-patch-3.patch >>>>>> patching file tools/firmware/hvmloader/Makefile >>>>>> Hunk #1 FAILED at 50. >>>>>> 1 out of 1 hunk FAILED -- saving rejects to file tools/firmware/hvmloader/Makefile.rej >>>>>> patching file tools/firmware/hvmloader/hvmloader.c >>>>>> patch: **** malformed patch at line 24: sizeof(vgabios_pt)); >>>>>> >>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi intel-gfx-passthru-patch-3.patch >>>>>> >>>>>> For everybody''s convenience, I have attached intel-gfx-passthru-patch-3.patch and the firmware for my nVidia GeForce 8400 GS PCI Express x16 graphics card in this email. >>>>>> >>>>>> Please help me complete intel-gfx-passthru-patch-3.patch as I really need it. >>>>>> >>>>>> Thank you very much!!! >>>>>> >>>>>> -- >>>>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>>>>> Technical Support Engineer >>>>>> Information Technology Department >>>>>> Asiasoft Online Pte Ltd >>>>>> Tampines Central 1 #04-01 Tampines Plaza >>>>>> Singapore 529541 >>>>>> Republic of Singapore >>>>>> Mobile: +65-9648-9798 >>>>>> MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> >>>>>> Alma Maters: Singapore Polytechnic, National University of Singapore >>>>>> >>>>>> This patch supports basic gfx passthrough on QEMU: >>>>>> >>>>>> - disable emulated VGA adpater if there is passthroughed gfx >>>>>> >>>>>> - register/unregister legacy VGA I/O ports and MMIOs for passthroughed gfx >>>>>> >>>>>> >>>>>> >>>>>> Signed-off-by: Ben Lin<ben.y.lin@intel.com> <mailto:ben.y.lin@intel.com> >>>>>> >>>>>> Signed-off-by: Weidong Han<weidong.han@intel.com> <mailto:weidong.han@intel.com> >>>>>> >>>>>> No virus found in this incoming message. >>>>>> >>>>>> Checked by AVG -www.avg.com <http://www.avg.com> >>>>>> >>>>>> Version: 8.5.409 / Virus Database: 270.13.69/2328 - Release Date: 08/27/09 >>>>>> >>>>>> 18:02:00 >>>>>> >>>>>> >>>>>> >>>>>> No virus found in this outgoing message. >>>>>> >>>>>> Checked by AVG -www.avg.com <http://www.avg.com> >>>>>> >>>>>> Version: 8.5.409 / Virus Database: 270.13.71/2330 - Release Date: 08/27/09 >>>>>> >>>>>> 18:02:00 >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> >>>>>> Xen-devel mailing list >>>>>> >>>>>> Xen-devel@lists.xensource.com <mailto:Xen-devel@lists.xensource.com> >>>>>> >>>>>> http://lists.xensource.com/xen-devel >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Xen-devel mailing list >>>>>> Xen-devel@lists.xensource.com <mailto: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 >>>>> >>>> >>>> >>> >> >> > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Teo,
Did you rename your Nvidia BIOS and copy it into the hvmloader source tree as
required ?
It should get compiled into roms.h in the hvmloader folder - I made sure it was
there as the xen buildroot seems to delete it randomly ...
I think we are now up against the Base Address Register issue where the Nvidia
driver is expecting to see the card at the Physical BAR Addresses and in the
DomU these are re-mapped to different address space ... this is a problem with
the Nvidia binary driver and therefore a workaround in xen is maybe needed.
That said, I''m not sure if the Nvidia BIOS likes to be re-executed and
may also be an issue ...
Tim
From: Mr. Teo En Ming (Zhang Enming) [mailto:enming.teo@asiasoftsea.net]
Sent: 29 August 2009 14:21
To: enming.teo@asiasoftsea.net
Cc: Tim Moore; xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] graphics passthrough with VT-d
Dear All,
I have applied the following patches to xen 3.5-unstable
1) intel-gfx-passthru-patch01.patch
2) intel-gfx-passthru-patch02.patch
3) intel-gfx-passthru-patch03.patch
4) enming-patch04.patch
and compiled xen 3.5-unstable successfully (both hypervisor and tools).
i rebooted into this newly compiled Xen hypervisor which supports loading vga
bios from firmware file of nVidia Geforce 8400 GS PCI Express x16.
After dom0 has booted up, I executed the following script to hide nVidia Geforce
8400 GS from dom0.
[enming@fedora11-x86-64-host scripts]$ cat bind-devices-pci-stub.sh
#!/bin/sh
echo "10de 06e4" > /sys/bus/pci/drivers/pci-stub/new_id
echo "0000:01:00.0" >
/sys/bus/pci/devices/0000:01:00.0/driver/unbind
echo "0000:01:00.0" > /sys/bus/pci/drivers/pci-stub/bind
I also assigned the nVidia Geforce 8400 GS to my Windows XP Home HVM domU.
pci = [ ''01:00.0'' ]
I also specified gfx_passthru=2.
Do note that I booted up with onboard Intel GMA4500 as the primary video
adapter. Hence dom 0 has onboard graphics and Windows XP HVM domU has nvidia
graphics.
Then I started Windows XP Home HVM DomU.
Very soon, my Dom 0''s display was garbaged and X server on Dom 0
totally froze and became unresponsive. I cannot switch to any ttys.
However, I was still able to vnc into my Windows XP Home HVM Dom U. I had
earlier installed a VNC server into my Windows XP guest. After remoting in to my
Windows XP DomU through vnc, I found that NVIDIA Geforce 8400 GS cannot be
initialized and no resources are available for this graphics card.
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Company Website: http://www.asiasoft.sg/
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 08:25 PM, Mr. Teo En Ming (Zhang Enming) wrote:
Hi All,
I have solved the problem encountered below when building tools for xen
3.5-unstable. The compile problem exists because I downloaded and compiled the
latest version of Intel ACPI Component Architecture compiler version 20090730.
And I used this latest compiler during "make tools" for xen-unstable.
In original xen-unstable source codes cloned from xensoure mercurial repository,
the header files ssdt_pm.h and ssdt_tpm.h in source directory
tools/firmware/hvmloader/acpi/ are generated by
/*
*
* Intel ACPI Component Architecture
* ASL Optimizing Compiler version 20061109 [May 18 2007]
* Copyright (C) 2000 - 2006 Intel Corporation
* Supports ACPI Specification Revision 3.0a
*
* Compilation of "ssdt_pm.asl" - Sun Oct 12 23:57:51 2008
*
* C source code output
*
*/
In original ssdt_pm.h, it has "unsigned char AmlCode_PM[] =".
In original ssdt_tpm.h, it has "unsigned char AmlCode_TPM[] =".
Hence there was no problem with "make tools".
But, I downloaded, compiled and used
/*
*
* Intel ACPI Component Architecture
* ASL Optimizing Compiler version 20090730 [Aug 29 2009]
* Copyright (C) 2000 - 2009 Intel Corporation
* Supports ACPI Specification Revision 4.0
*
* Compilation of "ssdt_pm.asl" - Sat Aug 29 18:55:40 2009
*
* C source code output
*
*/
So the *new* ssdt_pm.h contains:
/*
*
* Intel ACPI Component Architecture
* ASL Optimizing Compiler version 20090730 [Aug 29 2009]
* Copyright (C) 2000 - 2009 Intel Corporation
* Supports ACPI Specification Revision 4.0
*
* Compilation of "ssdt_pm.asl" - Sat Aug 29 18:55:40 2009
*
* C source code output
*
*/
unsigned char AmlCode[] {
0x53,0x53,0x44,0x54,0xD6,0x05,0x00,0x00, /* 00000000
"SSDT...." */
0x02,0xB9,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008
"..Xen..." */
0x48,0x56,0x4D,0x00,0x00,0x00,0x00,0x00, /* 00000010
"HVM....." */
0x00,0x00,0x00,0x00,0x49,0x4E,0x54,0x4C, /* 00000018
"....INTL" */
0x30,0x07,0x09,0x20,0x10,0x41,0x5B,0x5C, /* 00000020 "0..
.A[\" */
0x5F,0x53,0x42,0x5F,0x5B,0x80,0x44,0x42, /* 00000028
"_SB_[.DB" */
0x47,0x41,0x01,0x0B,0x40,0xB0,0x01,0x5B, /* 00000030
"GA..@..["<mailto:GA..@..%5B> */
0x81,0x0B,0x44,0x42,0x47,0x41,0x01,0x44, /* 00000038
"..DBGA.D" */
0x42,0x47,0x31,0x08,0x5B,0x80,0x44,0x42, /* 00000040
"BG1.[.DB" */
0x47,0x42,0x01,0x0B,0x44,0xB0,0x01,0x5B, /* 00000048
"GB..D..[" */
0x81,0x0B,0x44,0x42,0x47,0x42,0x01,0x44, /* 00000050
"..DBGB.D" */
0x42,0x47,0x32,0x08,0x5B,0x80,0x44,0x42, /* 00000058
"BG2.[.DB" */
0x47,0x43,0x01,0x0B,0x46,0xB0,0x01,0x5B, /* 00000060
"GC..F..[" */
0x81,0x0B,0x44,0x42,0x47,0x43,0x01,0x44, /* 00000068
"..DBGC.D" */
0x42,0x47,0x33,0x08,0x5B,0x80,0x44,0x42, /* 00000070
"BG3.[.DB" */
0x47,0x44,0x01,0x0B,0x48,0xB0,0x01,0x5B, /* 00000078
"GD..H..[" */
0x81,0x0B,0x44,0x42,0x47,0x44,0x01,0x44, /* 00000080
"..DBGD.D" */
0x42,0x47,0x34,0x08,0x5B,0x80,0x50,0x52, /* 00000088
"BG4.[.PR" */
0x54,0x31,0x01,0x0A,0xB2,0x0A,0x02,0x5B, /* 00000090
"T1.....[" */
0x81,0x10,0x50,0x52,0x54,0x31,0x01,0x50, /* 00000098
"..PRT1.P" */
0x42,0x32,0x5F,0x08,0x50,0x42,0x32,0x41, /* 000000A0
"B2_.PB2A" */
0x08,0x5B,0x80,0x50,0x52,0x54,0x32,0x01, /* 000000A8
".[.PRT2." */
0x0A,0x86,0x01,0x5B,0x81,0x0B,0x50,0x52, /* 000000B0
"...[..PR" */
0x54,0x32,0x01,0x50,0x38,0x36,0x5F,0x08, /* 000000B8
"T2.P86_." */
0x5B,0x80,0x50,0x52,0x54,0x33,0x01,0x0A, /* 000000C0
"[.PRT3.." */
0x88,0x01,0x5B,0x81,0x0B,0x50,0x52,0x54, /* 000000C8
"..[..PRT" */
0x33,0x01,0x50,0x38,0x38,0x5F,0x08,0x5B, /* 000000D0
"3.P88_.[" */
0x01,0x53,0x59,0x4E,0x43,0x01,0x08,0x42, /* 000000D8
".SYNC..B" */
0x55,0x46,0x30,0x11,0x04,0x0B,0x00,0x01, /* 000000E0
"UF0....." */
0x08,0x42,0x55,0x46,0x31,0x11,0x03,0x0A, /* 000000E8
".BUF1..." */
0x08,0x8B,0x42,0x55,0x46,0x31,0x00,0x42, /* 000000F0
"..BUF1.B" */
0x55,0x46,0x41,0x8B,0x42,0x55,0x46,0x31, /* 000000F8
"UFA.BUF1" */
0x0A,0x04,0x42,0x55,0x46,0x42,0x14,0x14, /* 00000100
"..BUFB.." */
And the *new* ssdt_tpm.h contains:
/*
*
* Intel ACPI Component Architecture
* ASL Optimizing Compiler version 20090730 [Aug 29 2009]
* Copyright (C) 2000 - 2009 Intel Corporation
* Supports ACPI Specification Revision 4.0
*
* Compilation of "ssdt_tpm.asl" - Sat Aug 29 18:55:40 2009
*
* C source code output
*
*/
unsigned char AmlCode[] {
0x53,0x53,0x44,0x54,0x4C,0x00,0x00,0x00, /* 00000000
"SSDTL..." */
0x02,0x2A,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008
".*Xen..." */
0x48,0x56,0x4D,0x00,0x00,0x00,0x00,0x00, /* 00000010
"HVM....." */
0x00,0x00,0x00,0x00,0x49,0x4E,0x54,0x4C, /* 00000018
"....INTL" */
0x30,0x07,0x09,0x20,0x5B,0x82,0x26,0x54, /* 00000020 "0..
[.&T" */
0x50,0x4D,0x5F,0x08,0x5F,0x48,0x49,0x44, /* 00000028
"PM_._HID" */
0x0C,0x41,0xD0,0x0C,0x31,0x08,0x5F,0x43, /* 00000030
".A..1._C" */
0x52,0x53,0x11,0x11,0x0A,0x0E,0x86,0x09, /* 00000038
"RS......" */
0x00,0x01,0x00,0x00,0xD4,0xFE,0x00,0x50, /* 00000040
".......P" */
0x00,0x00,0x79,0x00,
};
which are both wrong.
In ssdt_pm.h, I have to change "unsigned char AmlCode[]" to
"unsigned char AmlCode_PM[]".
In ssdt_tpm.h, I have to change "unsigned char AmlCode[]" to
"unsigned char AmlCode_TPM[]".
Then "make tools" is able to complete successfully.
I have created a patch for anybody who may be using the *latest* version of
Intel ACPI CA compiler version 20090730 and attached it here.
Patch file filename enming-patch04.patch:
<CODE>
Patch created by Teo En Ming (Zhang Enming) on 29 August 2009 Saturday at 8:00
P.M. Singapore Time
Email #1: enming.teo@asiasoftsea.net<mailto:enming.teo@asiasoftsea.net>
Email #2:
space.time.universe@gmail.com<mailto:space.time.universe@gmail.com>
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Mobile Phone: +65-9648-9798
--- ssdt_pm.h 2009-08-29 19:54:52.653088000 +0800
+++ ssdt_pm.h 2009-08-29 19:56:51.813088550 +0800
@@ -10,7 +10,7 @@
* C source code output
*
*/
-unsigned char AmlCode[] +unsigned char AmlCode_PM[] {
0x53,0x53,0x44,0x54,0xD6,0x05,0x00,0x00, /* 00000000
"SSDT...." */
0x02,0xB9,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008
"..Xen..." */
--- ssdt_tpm.h 2009-08-29 19:55:44.578738954 +0800
+++ ssdt_tpm.h 2009-08-29 19:57:27.896638884 +0800
@@ -10,7 +10,7 @@
* C source code output
*
*/
-unsigned char AmlCode[] +unsigned char AmlCode_TPM[] {
0x53,0x53,0x44,0x54,0x4C,0x00,0x00,0x00, /* 00000000
"SSDTL..." */
0x02,0x2A,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008
".*Xen..." */
</CODE>
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Company Website: http://www.asiasoft.sg/
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 07:03 PM, Mr. Teo En Ming (Zhang Enming) wrote:
Hi,
I cloned http://xenbits.xensource.com/xen-unstable.hg again today. I tried
applying the three Intel gfx passthrough patches to xen-unstable. When I
"make tools", I get the same error again:
make[7]: Entering directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader''
make -C acpi all
get-path: will use #!/usr/bin/python2.6 for python programs
make[8]: Entering directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi''
make iasl
get-path: will use #!/usr/bin/python2.6 for python programs
make[9]: Entering directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi''
make[9]: `/usr/local/bin/iasl'' is up to date.
make[9]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi''
iasl -tc ssdt_tpm.asl
Intel ACPI Component Architecture
ASL Optimizing Compiler version 20090730 [Aug 29 2009]
Copyright (C) 2000 - 2009 Intel Corporation
Supports ACPI Specification Revision 4.0
ASL Input: ssdt_tpm.asl - 31 lines, 1111 bytes, 3 keywords
AML Output: SSDT_TPM.aml - 76 bytes, 3 named objects, 0 executable opcodes
Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 0 Optimizations
mv ssdt_tpm.hex ssdt_tpm.h
rm -f *.aml
make iasl
get-path: will use #!/usr/bin/python2.6 for python programs
make[9]: Entering directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi''
make[9]: `/usr/local/bin/iasl'' is up to date.
make[9]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi''
iasl -tc ssdt_pm.asl
Intel ACPI Component Architecture
ASL Optimizing Compiler version 20090730 [Aug 29 2009]
Copyright (C) 2000 - 2009 Intel Corporation
Supports ACPI Specification Revision 4.0
ASL Input: ssdt_pm.asl - 425 lines, 12754 bytes, 192 keywords
AML Output: SSDT_PM.aml - 1494 bytes, 64 named objects, 128 executable opcodes
Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 31 Optimizations
mv ssdt_pm.hex ssdt_pm.h
rm -f *.aml
gcc -O1 -fno-omit-frame-pointer -fno-optimize-sibling-calls -m32 -march=i686
-g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value
-Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .build.o.d
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs -Werror
-fno-stack-protector -fno-builtin -msoft-float -I. -I..
-I../../../../tools/include -c -o build.o build.c
In file included from build.c:21:
ssdt_pm.h:13: error: redefinition of ''AmlCode''
ssdt_tpm.h:13: note: previous definition of ''AmlCode'' was here
build.c: In function ''construct_secondary_tables'':
build.c:184: error: ''AmlCode_PM'' undeclared (first use in this
function)
build.c:184: error: (Each undeclared identifier is reported only once
build.c:184: error: for each function it appears in.)
build.c:194: error: ''AmlCode_TPM'' undeclared (first use in
this function)
make[8]: *** [build.o] Error 1
make[8]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi''
make[7]: *** [subdir-all-acpi] Error 2
make[7]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader''
make[6]: *** [subdirs-all] Error 2
make[6]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader''
make[5]: *** [subdir-all-hvmloader] Error 2
make[5]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware''
make[4]: *** [subdirs-all] Error 2
make[4]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware''
make[3]: *** [all] Error 2
make[3]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware''
make[2]: *** [subdir-install-firmware] Error 2
make[2]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools''
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools''
make: *** [install-tools] Error 2
Any ideas about this Advanced Configuration and Power Interface code?
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Company Website: http://www.asiasoft.sg/
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 02:58 PM, Mr. Teo En Ming (Zhang Enming) wrote:
Hi
Anybody available today? I know it''s Saturday. :-)
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Company Website: http://www.asiasoft.sg/
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 11:48 AM, Mr. Teo En Ming (Zhang Enming) wrote:
Dear All,
After applying Intel VGA passthrough patches 1, 2 and 3, I have no problems with
"make xen", and "make install-xen". However, I have errors
with "make tools".
Here is the error output:
msoft-float -I. -I.. -I../../../../tools/include -c -o build.o build.c
build.c: In function ''construct_secondary_tables'':
build.c:194: error: ''AmlCode_TPM'' undeclared (first use in
this function)
build.c:194: error: (Each undeclared identifier is reported only once
build.c:194: error: for each function it appears in.)
make[8]: *** [build.o] Error 1
make[8]: Leaving directory
`/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader/acpi''
make[7]: *** [subdir-all-acpi] Error 2
make[7]: Leaving directory
`/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader''
make[6]: *** [subdirs-all] Error 2
make[6]: Leaving directory
`/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader''
make[5]: *** [subdir-all-hvmloader] Error 2
make[5]: Leaving directory
`/usr/src/xen-unstable.hg-vgapt/tools/firmware''
make[4]: *** [subdirs-all] Error 2
make[4]: Leaving directory
`/usr/src/xen-unstable.hg-vgapt/tools/firmware''
make[3]: *** [all] Error 2
make[3]: Leaving directory
`/usr/src/xen-unstable.hg-vgapt/tools/firmware''
make[2]: *** [subdir-install-firmware] Error 2
make[2]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools''
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools''
make: *** [install-tools] Error 2
There is an undeclared identifier in tools/firmware/hvmloader/acpi/build.c
source code. Could you guys help me resolve this issue?
I had no problems compiling xen 3.5-unstable before applying the Intel vga
passthrough patches and before installing the Intel ACPI Component Architecture
compiler.
I have also attached Intel graphics passthrough patches 1, 2 and 3 for your
convenience here.
Thank you very much.
Hope I can get this working during the weekends.
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Company Website: http://www.asiasoft.sg/
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 10:17 AM, Mr. Teo En Ming (Zhang Enming) wrote:
Hi Tim,
I thought it should be gfx_passthru=2 in domU config?
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 06:42 AM, Tim Moore wrote:
Teo,
I have also performed the same exercise as yourself and I now have successfully
compiled all 3x patches into Xen, Qemu and the BIOS File Loading in the
hvmloader, this all compiles find on my system. Suggest you do a "make
clean" on the tools and start again !
After booting with the patched xen-unstable and adding the gfx-passthru=1
parameter to my HVM DomU, as I suspected - it still doesn''t work.
I have both a 9500GT and GTX260(primary) in my Intel DX58SO machine, tried
passing through either device and my primary display locks up ! (included hiding
with pci-stub)
I verified that the DomU was functional beforehand, as It also booted
successfully without the gfx-passthru parameter (and a vncviewer/cirrus display)
Unfortunately, I can''t debug further as my Primary display corrupts as
soon as the DomU starts. I did notice that in "xm debug" the
"Loading Gfx BIOS File.." message was displayed and the DomU did
continue to initialise the BIOS tables and such before finally locking. I then
(blindly) typed on a corrupt Dom0 console and managed to start kdm and login, so
the Dom0 was not completely trashed. But then after a few minutes, the machine
totally froze and had to hit the reset switch.
I`m no specialist but this looks like the VGA BIOS Re-initialisation is playing
havoc with the DomU and possibly the Dom0 graphics. I notice that both are also
using IRQ11 which could play a major part. Furthermore, there was a lot of debug
output in the qemu and xend.log indicating Base Address Register invalid access
and therefore it seems there may be a second obstacle.
Hope you have a better success than me !
For now, I would try re-compiling a fresh xen-unstable with carefully applied
patches .. oh! and don''t forget to enable the pci-stub driver for Dom0
(it''s not selected by default)
Tim
From:
xen-devel-bounces@lists.xensource.com<mailto:xen-devel-bounces@lists.xensource.com>
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Mr. Teo En Ming
(Zhang Enming)
Sent: 28 August 2009 21:14
To: enming.teo@asiasoftsea.net<mailto:enming.teo@asiasoftsea.net>
Cc: xen-devel@lists.xensource.com<mailto:xen-devel@lists.xensource.com>;
''Lin, Ben Y''; ''Kay, Allen M''; ''Jean
Guyader'';
Keir.Fraser@eu.citrix.com<mailto:Keir.Fraser@eu.citrix.com>;
weidong.han@intel.com<mailto:weidong.han@intel.com>;
bengheng@eecs.umich.edu<mailto:bengheng@eecs.umich.edu>
Subject: Re: [Xen-devel] [PATCH 2/2] graphics passthrough with VT-d
After applying the 1st and 2nd patch to xen-unstable successfully, I examined
the source codes Makefile and hvmloader.c in tools/firmware/hvmloader, compared
them to Weidong''s 3rd patch and I generated my own 3rd patch. Then I
used my own generated 3rd patch to apply patching for loading vga bios from
firmware file.
Here is my own generated 3rd patch instead of using Weidong''s 3rd
patch:
--- Makefile 2009-08-29 03:24:52.413083774 +0800
+++ Makefile 2009-08-29 03:29:12.763299633 +0800
@@ -50,6 +50,7 @@
roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \
../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h
sh ./mkhex rombios ../rombios/BIOS-bochs-latest > roms.h
+ sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin >> roms.h
sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin >>
roms.h
sh ./mkhex vgabios_cirrusvga \
../vgabios/VGABIOS-lgpl-latest.cirrus.bin >> roms.h
--- hvmloader.c 2009-08-29 03:26:06.911085797 +0800
+++ hvmloader.c 2009-08-29 03:31:43.172084995 +0800
@@ -688,9 +688,9 @@
vgabios_sz = round_option_rom(sizeof(vgabios_stdvga));
break;
case VGA_pt:
- printf("Loading VGABIOS of passthroughed gfx ...\n");
- vgabios_sz
- round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512);
+ printf("Loading Gfx Video BIOS from file ...\n");
+ memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt,
sizeof(vgabios_pt));
+ vgabios_sz = round_option_rom(sizeof(vgabios_pt));
break;
default:
printf("No emulated VGA adaptor ...\n");
I can "make xen" successfully but when I proceeded to "make
tools", errors were encountered.
Please see attached error output. How can I solve this problem?
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 12:59 AM, Mr. Teo En Ming (Zhang Enming) wrote:
OK I believe the 3rd patch is not incomplete but there''s a white space
issue when I copied the code from the mailing list into my vi.
See http://www.htdig.org/mail/2000/11/0167.html
When I used the -l flag to patch using the 3rd patch, the number of errors was
reduced.
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -l -p1 <
intel-gfx-passthru-patch-3.patch
patching file tools/firmware/hvmloader/Makefile
patching file tools/firmware/hvmloader/hvmloader.c
Hunk #1 FAILED at 688.
1 out of 1 hunk FAILED -- saving rejects to file
tools/firmware/hvmloader/hvmloader.c.rej
Now patching tools/firmware/hvmloader/Makefile is successful but patching
tools/firmware/hvmloader/hvmloader.c still failed.
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/28/2009 11:55 PM, Mr. Teo En Ming (Zhang Enming) wrote:
Dear Weidong,
A big big thanks for the vga passthrough patches for xen 3.5-unstable!!! These
are eagerly anticipated patches. As I did not study computer science and
computer architecture, I won''t be able to write those patches you guys
at Intel wrote.
I applied the following patches
xen-gfx-passthrough.patch<http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin>
and
qemu-gfx-passthrough.patch<http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin>
to xen 3.5-unstable without issues.
Then I tried to apply the 3rd patch you provided at
http://lists.xensource.com/archives/html/xen-devel/2009-08/msg01047.html
I saved the following code
<CODE>
diff -r 494be76c1ad9 tools/firmware/hvmloader/Makefile
--- a/tools/firmware/hvmloader/Makefile Thu Aug 27 16:54:33 2009 +0800
+++ b/tools/firmware/hvmloader/Makefile Thu Aug 27 17:22:01 2009 +0800
@@ -50,6 +50,7 @@ roms.h: ../rombios/BIOS-bochs-latest ../
roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \
../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h
sh ./mkhex rombios ../rombios/BIOS-bochs-latest > roms.h
+ sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin >> roms.h
sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin >> roms.h
sh ./mkhex vgabios_cirrusvga \
../vgabios/VGABIOS-lgpl-latest.cirrus.bin >> roms.h
diff -r 494be76c1ad9 tools/firmware/hvmloader/hvmloader.c
--- a/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 16:54:33 2009 +0800
+++ b/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 17:23:00 2009 +0800
@@ -688,9 +688,9 @@ int main(void)
vgabios_sz = round_option_rom(sizeof(vgabios_stdvga));
break;
case VGA_pt:
- printf("Loading Gfx Video BIOS from 0xC0000 ...\n");
- vgabios_sz
- round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512);
+ printf("Loading Gfx Video BIOS from file ...\n");
+ memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt,
sizeof(vgabios_pt));
+ vgabios_sz = round_option_rom(sizeof(vgabios_pt));
break;
default:
printf("No emulated VGA adaptor ...\n");
</CODE>
as intel-gfx-passthru-patch-3.patch and then I tried to apply the patch to xen
3.5-unstable. I got errors. I think it''s because the 3rd patch you
provided is incomplete.
Here''s my patching process:
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name vgabios
./tools/firmware/vgabios
./.hg/store/data/tools/firmware/vgabios
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cp ~enming/vgabios-pt.bin
tools/firmware/vgabios/
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ls tools/firmware/vgabios/
biossums.c clext.c Makefile TODO vbe.h
vgabios.h vgatables.h
BUGS COPYING Notes vbe.c vbetables-gen.c
vgabios-pt.bin
ChangeLog dataseghack README vbe_display_api.txt vgabios.c
vgafonts.h
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# pwd
/usr/src/xen-unstable.hg-vgapt
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wget
http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin
--2009-08-28 23:18:21--
http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin
Resolving lists.xensource.com... 70.42.241.110
Connecting to lists.xensource.com|70.42.241.110|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 12565 (12K) [application/octet-stream]
Saving to: `bincPiiAf0QWg.bin''
100%[======================================================================>]
12,565 30.7K/s in 0.4s
2009-08-28 23:18:22 (30.7 KB/s) - `bincPiiAf0QWg.bin'' saved
[12565/12565]
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv bincPiiAf0QWg.bin
xen-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi xen-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch <
xen-gfx-passthrough.patch
can''t find file to patch at input line 4
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff -r 5d7e7a250267 tools/firmware/hvmloader/config.h
|--- a/tools/firmware/hvmloader/config.h Wed Aug 26 18:28:44 2009 +0800
|+++ b/tools/firmware/hvmloader/config.h Thu Aug 27 16:54:24 2009 +0800
--------------------------
File to patch: ^C
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ex xen-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1 <
xen-gfx-passthrough.patch
patching file tools/firmware/hvmloader/config.h
patching file tools/firmware/hvmloader/hvmloader.c
patching file tools/libxc/ia64/xc_ia64_hvm_build.c
patching file tools/libxc/xc_hvm_build.c
patching file tools/libxc/xc_linux.c
patching file tools/libxc/xenctrl.h
patching file tools/libxc/xenguest.h
patching file tools/python/xen/lowlevel/xc/xc.c
patching file tools/python/xen/xend/XendConfig.py
Hunk #1 succeeded at 174 (offset -1 lines).
patching file tools/python/xen/xend/image.py
Hunk #1 succeeded at 780 (offset -6 lines).
Hunk #3 succeeded at 895 (offset -6 lines).
patching file tools/python/xen/xm/create.py
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wget
http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin
--2009-08-28 23:21:35--
http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin
Resolving lists.xensource.com... 70.42.241.110
Connecting to lists.xensource.com|70.42.241.110|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9841 (9.6K) [application/octet-stream]
Saving to: `binglLqkeq4Rj.bin''
100%[======================================================================>]
9,841 24.3K/s in 0.4s
2009-08-28 23:21:36 (24.3 KB/s) - `binglLqkeq4Rj.bin'' saved [9841/9841]
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv binglLqkeq4Rj.bin
qemu-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi qemu-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name hw
./tools/ioemu-remote/hw
./.hg/store/data/tools/ioemu/hw
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv qemu-gfx-passthrough.patch
tools/ioemu-remote/
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cd tools/ioemu-remote/
[root@fedora11-x86-64-host ioemu-remote]# patch -p1 < qemu-
qemu-aio.h qemu-img.c qemu-sockets.c
qemu-binfmt-conf.sh qemu-img.texi qemu-tech.texi
qemu-char.c qemu-lock.h qemu-timer.h
qemu-char.h qemu-log.h qemu-tool.c
qemu-common.h qemu-malloc.c qemu-xen.h
qemu-doc.texi qemu-nbd.c
qemu-gfx-passthrough.patch qemu-nbd.texi
[root@fedora11-x86-64-host ioemu-remote]# patch -p1 <
qemu-gfx-passthrough.patch
patching file hw/pass-through.c
patching file hw/pass-through.h
patching file hw/pc.c
patching file vl.c
[root@fedora11-x86-64-host ioemu-remote]# cd ..
[root@fedora11-x86-64-host tools]# cd ..
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi
intel-gfx-passthru-patch-3.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1 <
intel-gfx-passthru-patch-3.patch
patching file tools/firmware/hvmloader/Makefile
Hunk #1 FAILED at 50.
1 out of 1 hunk FAILED -- saving rejects to file
tools/firmware/hvmloader/Makefile.rej
patching file tools/firmware/hvmloader/hvmloader.c
patch: **** malformed patch at line 24: sizeof(vgabios_pt));
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi
intel-gfx-passthru-patch-3.patch
For everybody''s convenience, I have attached
intel-gfx-passthru-patch-3.patch and the firmware for my nVidia GeForce 8400 GS
PCI Express x16 graphics card in this email.
Please help me complete intel-gfx-passthru-patch-3.patch as I really need it.
Thank you very much!!!
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
This patch supports basic gfx passthrough on QEMU:
- disable emulated VGA adpater if there is passthroughed gfx
- register/unregister legacy VGA I/O ports and MMIOs for passthroughed gfx
Signed-off-by: Ben Lin
<ben.y.lin@intel.com><mailto:ben.y.lin@intel.com>
Signed-off-by: Weidong Han
<weidong.han@intel.com><mailto:weidong.han@intel.com>
No virus found in this incoming message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 8.5.409 / Virus Database: 270.13.69/2328 - Release Date: 08/27/09
18:02:00
No virus found in this outgoing message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 8.5.409 / Virus Database: 270.13.71/2330 - Release Date: 08/27/09
18:02:00
________________________________
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com<mailto:Xen-devel@lists.xensource.com>
http://lists.xensource.com/xen-devel
________________________________
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com<mailto:Xen-devel@lists.xensource.com>
http://lists.xensource.com/xen-devel
________________________________
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com<mailto: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
Mr. Teo En Ming (Zhang Enming)
2009-Aug-29 13:46 UTC
Re: [Xen-devel] graphics passthrough with VT-d
Dear All, I have attached the patchset to xen-unstable and also the nvidia geforce 8400 gs firmware file here for your convenience. You can refer to the screenshots at my blog here: http://teo-en-ming-aka-zhang-enming.blogspot.com/2009/08/windows-xp-home-domu-test-results-after.html It shows that the emulated virtual VGA card is now disabled (not appearing in Windows XP Home DomU''s device manager) and only the nVidia Geforce 8400 GS VGA BIOS gets loaded. -- Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) Technical Support Engineer Information Technology Department Asiasoft Online Pte Ltd Tampines Central 1 #04-01 Tampines Plaza Singapore 529541 Republic of Singapore Company Website: http://www.asiasoft.sg/ Mobile: +65-9648-9798 MSN: teoenming@hotmail.com Alma Maters: Singapore Polytechnic, National University of Singapore On 08/29/2009 09:20 PM, Mr. Teo En Ming (Zhang Enming) wrote:> Dear All, > > I have applied the following patches to xen 3.5-unstable > > 1) intel-gfx-passthru-patch01.patch > 2) intel-gfx-passthru-patch02.patch > 3) intel-gfx-passthru-patch03.patch > 4) enming-patch04.patch > > and compiled xen 3.5-unstable successfully (both hypervisor and tools). > > i rebooted into this newly compiled Xen hypervisor which supports > loading vga bios from firmware file of nVidia Geforce 8400 GS PCI > Express x16. > > After dom0 has booted up, I executed the following script to hide > nVidia Geforce 8400 GS from dom0. > > [enming@fedora11-x86-64-host scripts]$ cat bind-devices-pci-stub.sh > #!/bin/sh > echo "10de 06e4" > /sys/bus/pci/drivers/pci-stub/new_id > echo "0000:01:00.0" > /sys/bus/pci/devices/0000:01:00.0/driver/unbind > echo "0000:01:00.0" > /sys/bus/pci/drivers/pci-stub/bind > > I also assigned the nVidia Geforce 8400 GS to my Windows XP Home HVM domU. > > pci = [ ''01:00.0'' ] > > I also specified gfx_passthru=2. > > Do note that I booted up with onboard Intel GMA4500 as the primary > video adapter. Hence dom 0 has onboard graphics and Windows XP HVM > domU has nvidia graphics. > > Then I started Windows XP Home HVM DomU. > > Very soon, my Dom 0''s display was garbaged and X server on Dom 0 > totally froze and became unresponsive. I cannot switch to any ttys. > > However, I was still able to vnc into my Windows XP Home HVM Dom U. I > had earlier installed a VNC server into my Windows XP guest. After > remoting in to my Windows XP DomU through vnc, I found that NVIDIA > Geforce 8400 GS cannot be initialized and no resources are available > for this graphics card. > > -- > Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) > Technical Support Engineer > Information Technology Department > Asiasoft Online Pte Ltd > Tampines Central 1 #04-01 Tampines Plaza > Singapore 529541 > Republic of Singapore > Company Website:http://www.asiasoft.sg/ > Mobile: +65-9648-9798 > MSN:teoenming@hotmail.com > Alma Maters: Singapore Polytechnic, National University of Singapore > > > On 08/29/2009 08:25 PM, Mr. Teo En Ming (Zhang Enming) wrote: >> Hi All, >> >> I have solved the problem encountered below when building tools for >> xen 3.5-unstable. The compile problem exists because I downloaded and >> compiled the latest version of Intel ACPI Component Architecture >> compiler version 20090730. And I used this latest compiler during >> "make tools" for xen-unstable. >> >> In original xen-unstable source codes cloned from xensoure mercurial >> repository, the header files ssdt_pm.h and ssdt_tpm.h in source >> directory tools/firmware/hvmloader/acpi/ are generated by >> >> /* >> * >> * Intel ACPI Component Architecture >> * ASL Optimizing Compiler version 20061109 [May 18 2007] >> * Copyright (C) 2000 - 2006 Intel Corporation >> * Supports ACPI Specification Revision 3.0a >> * >> * Compilation of "ssdt_pm.asl" - Sun Oct 12 23:57:51 2008 >> * >> * C source code output >> * >> */ >> >> In original ssdt_pm.h, it has "unsigned char AmlCode_PM[] =". >> >> In original ssdt_tpm.h, it has "unsigned char AmlCode_TPM[] =". >> >> Hence there was no problem with "make tools". >> >> But, I downloaded, compiled and used >> >> /* >> * >> * Intel ACPI Component Architecture >> * ASL Optimizing Compiler version 20090730 [Aug 29 2009] >> * Copyright (C) 2000 - 2009 Intel Corporation >> * Supports ACPI Specification Revision 4.0 >> * >> * Compilation of "ssdt_pm.asl" - Sat Aug 29 18:55:40 2009 >> * >> * C source code output >> * >> */ >> >> So the *new* ssdt_pm.h contains: >> >> /* >> * >> * Intel ACPI Component Architecture >> * ASL Optimizing Compiler version 20090730 [Aug 29 2009] >> * Copyright (C) 2000 - 2009 Intel Corporation >> * Supports ACPI Specification Revision 4.0 >> * >> * Compilation of "ssdt_pm.asl" - Sat Aug 29 18:55:40 2009 >> * >> * C source code output >> * >> */ >> unsigned char AmlCode[] >> { >> 0x53,0x53,0x44,0x54,0xD6,0x05,0x00,0x00, /* 00000000 >> "SSDT...." */ >> 0x02,0xB9,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008 >> "..Xen..." */ >> 0x48,0x56,0x4D,0x00,0x00,0x00,0x00,0x00, /* 00000010 >> "HVM....." */ >> 0x00,0x00,0x00,0x00,0x49,0x4E,0x54,0x4C, /* 00000018 >> "....INTL" */ >> 0x30,0x07,0x09,0x20,0x10,0x41,0x5B,0x5C, /* 00000020 "0.. >> .A[\" */ >> 0x5F,0x53,0x42,0x5F,0x5B,0x80,0x44,0x42, /* 00000028 >> "_SB_[.DB" */ >> 0x47,0x41,0x01,0x0B,0x40,0xB0,0x01,0x5B, /* 00000030 "GA..@..[" */ >> 0x81,0x0B,0x44,0x42,0x47,0x41,0x01,0x44, /* 00000038 >> "..DBGA.D" */ >> 0x42,0x47,0x31,0x08,0x5B,0x80,0x44,0x42, /* 00000040 >> "BG1.[.DB" */ >> 0x47,0x42,0x01,0x0B,0x44,0xB0,0x01,0x5B, /* 00000048 >> "GB..D..[" */ >> 0x81,0x0B,0x44,0x42,0x47,0x42,0x01,0x44, /* 00000050 >> "..DBGB.D" */ >> 0x42,0x47,0x32,0x08,0x5B,0x80,0x44,0x42, /* 00000058 >> "BG2.[.DB" */ >> 0x47,0x43,0x01,0x0B,0x46,0xB0,0x01,0x5B, /* 00000060 >> "GC..F..[" */ >> 0x81,0x0B,0x44,0x42,0x47,0x43,0x01,0x44, /* 00000068 >> "..DBGC.D" */ >> 0x42,0x47,0x33,0x08,0x5B,0x80,0x44,0x42, /* 00000070 >> "BG3.[.DB" */ >> 0x47,0x44,0x01,0x0B,0x48,0xB0,0x01,0x5B, /* 00000078 >> "GD..H..[" */ >> 0x81,0x0B,0x44,0x42,0x47,0x44,0x01,0x44, /* 00000080 >> "..DBGD.D" */ >> 0x42,0x47,0x34,0x08,0x5B,0x80,0x50,0x52, /* 00000088 >> "BG4.[.PR" */ >> 0x54,0x31,0x01,0x0A,0xB2,0x0A,0x02,0x5B, /* 00000090 >> "T1.....[" */ >> 0x81,0x10,0x50,0x52,0x54,0x31,0x01,0x50, /* 00000098 >> "..PRT1.P" */ >> 0x42,0x32,0x5F,0x08,0x50,0x42,0x32,0x41, /* 000000A0 >> "B2_.PB2A" */ >> 0x08,0x5B,0x80,0x50,0x52,0x54,0x32,0x01, /* 000000A8 >> ".[.PRT2." */ >> 0x0A,0x86,0x01,0x5B,0x81,0x0B,0x50,0x52, /* 000000B0 >> "...[..PR" */ >> 0x54,0x32,0x01,0x50,0x38,0x36,0x5F,0x08, /* 000000B8 >> "T2.P86_." */ >> 0x5B,0x80,0x50,0x52,0x54,0x33,0x01,0x0A, /* 000000C0 >> "[.PRT3.." */ >> 0x88,0x01,0x5B,0x81,0x0B,0x50,0x52,0x54, /* 000000C8 >> "..[..PRT" */ >> 0x33,0x01,0x50,0x38,0x38,0x5F,0x08,0x5B, /* 000000D0 >> "3.P88_.[" */ >> 0x01,0x53,0x59,0x4E,0x43,0x01,0x08,0x42, /* 000000D8 >> ".SYNC..B" */ >> 0x55,0x46,0x30,0x11,0x04,0x0B,0x00,0x01, /* 000000E0 >> "UF0....." */ >> 0x08,0x42,0x55,0x46,0x31,0x11,0x03,0x0A, /* 000000E8 >> ".BUF1..." */ >> 0x08,0x8B,0x42,0x55,0x46,0x31,0x00,0x42, /* 000000F0 >> "..BUF1.B" */ >> 0x55,0x46,0x41,0x8B,0x42,0x55,0x46,0x31, /* 000000F8 >> "UFA.BUF1" */ >> 0x0A,0x04,0x42,0x55,0x46,0x42,0x14,0x14, /* 00000100 >> "..BUFB.." */ >> >> And the *new* ssdt_tpm.h contains: >> >> /* >> * >> * Intel ACPI Component Architecture >> * ASL Optimizing Compiler version 20090730 [Aug 29 2009] >> * Copyright (C) 2000 - 2009 Intel Corporation >> * Supports ACPI Specification Revision 4.0 >> * >> * Compilation of "ssdt_tpm.asl" - Sat Aug 29 18:55:40 2009 >> * >> * C source code output >> * >> */ >> unsigned char AmlCode[] >> { >> 0x53,0x53,0x44,0x54,0x4C,0x00,0x00,0x00, /* 00000000 >> "SSDTL..." */ >> 0x02,0x2A,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008 >> ".*Xen..." */ >> 0x48,0x56,0x4D,0x00,0x00,0x00,0x00,0x00, /* 00000010 >> "HVM....." */ >> 0x00,0x00,0x00,0x00,0x49,0x4E,0x54,0x4C, /* 00000018 >> "....INTL" */ >> 0x30,0x07,0x09,0x20,0x5B,0x82,0x26,0x54, /* 00000020 "0.. >> [.&T" */ >> 0x50,0x4D,0x5F,0x08,0x5F,0x48,0x49,0x44, /* 00000028 >> "PM_._HID" */ >> 0x0C,0x41,0xD0,0x0C,0x31,0x08,0x5F,0x43, /* 00000030 >> ".A..1._C" */ >> 0x52,0x53,0x11,0x11,0x0A,0x0E,0x86,0x09, /* 00000038 >> "RS......" */ >> 0x00,0x01,0x00,0x00,0xD4,0xFE,0x00,0x50, /* 00000040 >> ".......P" */ >> 0x00,0x00,0x79,0x00, >> }; >> >> which are both wrong. >> >> In ssdt_pm.h, I have to change "unsigned char AmlCode[]" to "unsigned >> char AmlCode_PM[]". >> >> In ssdt_tpm.h, I have to change "unsigned char AmlCode[]" to >> "unsigned char AmlCode_TPM[]". >> >> Then "make tools" is able to complete successfully. >> >> I have created a patch for anybody who may be using the *latest* >> version of Intel ACPI CA compiler version 20090730 and attached it here. >> >> Patch file filename enming-patch04.patch: >> >> <CODE> >> >> Patch created by Teo En Ming (Zhang Enming) on 29 August 2009 >> Saturday at 8:00 P.M. Singapore Time >> Email #1: enming.teo@asiasoftsea.net >> Email #2: space.time.universe@gmail.com >> MSN: teoenming@hotmail.com >> Mobile Phone: +65-9648-9798 >> >> --- ssdt_pm.h 2009-08-29 19:54:52.653088000 +0800 >> +++ ssdt_pm.h 2009-08-29 19:56:51.813088550 +0800 >> @@ -10,7 +10,7 @@ >> * C source code output >> * >> */ >> -unsigned char AmlCode[] >> +unsigned char AmlCode_PM[] >> { >> 0x53,0x53,0x44,0x54,0xD6,0x05,0x00,0x00, /* 00000000 >> "SSDT...." */ >> 0x02,0xB9,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008 >> "..Xen..." */ >> --- ssdt_tpm.h 2009-08-29 19:55:44.578738954 +0800 >> +++ ssdt_tpm.h 2009-08-29 19:57:27.896638884 +0800 >> @@ -10,7 +10,7 @@ >> * C source code output >> * >> */ >> -unsigned char AmlCode[] >> +unsigned char AmlCode_TPM[] >> { >> 0x53,0x53,0x44,0x54,0x4C,0x00,0x00,0x00, /* 00000000 >> "SSDTL..." */ >> 0x02,0x2A,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008 >> ".*Xen..." */ >> >> </CODE> >> >> -- >> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >> Technical Support Engineer >> Information Technology Department >> Asiasoft Online Pte Ltd >> Tampines Central 1 #04-01 Tampines Plaza >> Singapore 529541 >> Republic of Singapore >> Company Website:http://www.asiasoft.sg/ >> Mobile: +65-9648-9798 >> MSN:teoenming@hotmail.com >> Alma Maters: Singapore Polytechnic, National University of Singapore >> >> >> On 08/29/2009 07:03 PM, Mr. Teo En Ming (Zhang Enming) wrote: >>> Hi, >>> >>> I clonedhttp://xenbits.xensource.com/xen-unstable.hg again today. I tried applying the three Intel gfx passthrough patches to xen-unstable. When I "make tools", I get the same error again: >>> >>> make[7]: Entering directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader'' >>> make -C acpi all >>> get-path: will use #!/usr/bin/python2.6 for python programs >>> make[8]: Entering directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' >>> make iasl >>> get-path: will use #!/usr/bin/python2.6 for python programs >>> make[9]: Entering directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' >>> make[9]: `/usr/local/bin/iasl'' is up to date. >>> make[9]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' >>> iasl -tc ssdt_tpm.asl >>> >>> Intel ACPI Component Architecture >>> ASL Optimizing Compiler version 20090730 [Aug 29 2009] >>> Copyright (C) 2000 - 2009 Intel Corporation >>> Supports ACPI Specification Revision 4.0 >>> >>> ASL Input: ssdt_tpm.asl - 31 lines, 1111 bytes, 3 keywords >>> AML Output: SSDT_TPM.aml - 76 bytes, 3 named objects, 0 executable opcodes >>> >>> Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 0 Optimizations >>> mv ssdt_tpm.hex ssdt_tpm.h >>> rm -f *.aml >>> make iasl >>> get-path: will use #!/usr/bin/python2.6 for python programs >>> make[9]: Entering directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' >>> make[9]: `/usr/local/bin/iasl'' is up to date. >>> make[9]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' >>> iasl -tc ssdt_pm.asl >>> >>> Intel ACPI Component Architecture >>> ASL Optimizing Compiler version 20090730 [Aug 29 2009] >>> Copyright (C) 2000 - 2009 Intel Corporation >>> Supports ACPI Specification Revision 4.0 >>> >>> ASL Input: ssdt_pm.asl - 425 lines, 12754 bytes, 192 keywords >>> AML Output: SSDT_PM.aml - 1494 bytes, 64 named objects, 128 executable opcodes >>> >>> Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 31 Optimizations >>> mv ssdt_pm.hex ssdt_pm.h >>> rm -f *.aml >>> gcc -O1 -fno-omit-frame-pointer -fno-optimize-sibling-calls -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .build.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs -Werror -fno-stack-protector -fno-builtin -msoft-float -I. -I.. -I../../../../tools/include -c -o build.o build.c >>> In file included from build.c:21: >>> ssdt_pm.h:13: error: redefinition of ''AmlCode'' >>> ssdt_tpm.h:13: note: previous definition of ''AmlCode'' was here >>> build.c: In function ''construct_secondary_tables'': >>> build.c:184: error: ''AmlCode_PM'' undeclared (first use in this function) >>> build.c:184: error: (Each undeclared identifier is reported only once >>> build.c:184: error: for each function it appears in.) >>> build.c:194: error: ''AmlCode_TPM'' undeclared (first use in this function) >>> make[8]: *** [build.o] Error 1 >>> make[8]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' >>> make[7]: *** [subdir-all-acpi] Error 2 >>> make[7]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader'' >>> make[6]: *** [subdirs-all] Error 2 >>> make[6]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader'' >>> make[5]: *** [subdir-all-hvmloader] Error 2 >>> make[5]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware'' >>> make[4]: *** [subdirs-all] Error 2 >>> make[4]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware'' >>> make[3]: *** [all] Error 2 >>> make[3]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware'' >>> make[2]: *** [subdir-install-firmware] Error 2 >>> make[2]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools'' >>> make[1]: *** [subdirs-install] Error 2 >>> make[1]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools'' >>> make: *** [install-tools] Error 2 >>> >>> Any ideas about this Advanced Configuration and Power Interface code? >>> >>> -- >>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>> Technical Support Engineer >>> Information Technology Department >>> Asiasoft Online Pte Ltd >>> Tampines Central 1 #04-01 Tampines Plaza >>> Singapore 529541 >>> Republic of Singapore >>> Company Website:http://www.asiasoft.sg/ >>> Mobile: +65-9648-9798 >>> MSN:teoenming@hotmail.com >>> Alma Maters: Singapore Polytechnic, National University of Singapore >>> >>> >>> On 08/29/2009 02:58 PM, Mr. Teo En Ming (Zhang Enming) wrote: >>>> Hi >>>> >>>> Anybody available today? I know it''s Saturday. :-) >>>> >>>> -- >>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>>> Technical Support Engineer >>>> Information Technology Department >>>> Asiasoft Online Pte Ltd >>>> Tampines Central 1 #04-01 Tampines Plaza >>>> Singapore 529541 >>>> Republic of Singapore >>>> Company Website:http://www.asiasoft.sg/ >>>> Mobile: +65-9648-9798 >>>> MSN:teoenming@hotmail.com >>>> Alma Maters: Singapore Polytechnic, National University of Singapore >>>> >>>> >>>> On 08/29/2009 11:48 AM, Mr. Teo En Ming (Zhang Enming) wrote: >>>>> >>>>> Dear All, >>>>> >>>>> After applying Intel VGA passthrough patches 1, 2 and 3, I have no problems with "make xen", and "make install-xen". However, I have errors with "make tools". >>>>> >>>>> Here is the error output: >>>>> >>>>> msoft-float -I. -I.. -I../../../../tools/include -c -o build.o build.c >>>>> build.c: In function ''construct_secondary_tables'': >>>>> build.c:194: error: ''AmlCode_TPM'' undeclared (first use in this function) >>>>> build.c:194: error: (Each undeclared identifier is reported only once >>>>> build.c:194: error: for each function it appears in.) >>>>> make[8]: *** [build.o] Error 1 >>>>> make[8]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader/acpi'' >>>>> make[7]: *** [subdir-all-acpi] Error 2 >>>>> make[7]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader'' >>>>> make[6]: *** [subdirs-all] Error 2 >>>>> make[6]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader'' >>>>> make[5]: *** [subdir-all-hvmloader] Error 2 >>>>> make[5]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'' >>>>> make[4]: *** [subdirs-all] Error 2 >>>>> make[4]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'' >>>>> make[3]: *** [all] Error 2 >>>>> make[3]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'' >>>>> make[2]: *** [subdir-install-firmware] Error 2 >>>>> make[2]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools'' >>>>> make[1]: *** [subdirs-install] Error 2 >>>>> make[1]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools'' >>>>> make: *** [install-tools] Error 2 >>>>> >>>>> There is an undeclared identifier in tools/firmware/hvmloader/acpi/build.c source code. Could you guys help me resolve this issue? >>>>> >>>>> I had no problems compiling xen 3.5-unstable before applying the Intel vga passthrough patches and before installing the Intel ACPI Component Architecture compiler. >>>>> >>>>> I have also attached Intel graphics passthrough patches 1, 2 and 3 for your convenience here. >>>>> >>>>> Thank you very much. >>>>> >>>>> Hope I can get this working during the weekends. >>>>> >>>>> -- >>>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>>>> Technical Support Engineer >>>>> Information Technology Department >>>>> Asiasoft Online Pte Ltd >>>>> Tampines Central 1 #04-01 Tampines Plaza >>>>> Singapore 529541 >>>>> Republic of Singapore >>>>> Company Website:http://www.asiasoft.sg/ >>>>> Mobile: +65-9648-9798 >>>>> MSN:teoenming@hotmail.com >>>>> Alma Maters: Singapore Polytechnic, National University of Singapore >>>>> >>>>> >>>>> On 08/29/2009 10:17 AM, Mr. Teo En Ming (Zhang Enming) wrote: >>>>>> Hi Tim, >>>>>> >>>>>> I thought it should be gfx_passthru=2 in domU config? >>>>>> -- >>>>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>>>>> Technical Support Engineer >>>>>> Information Technology Department >>>>>> Asiasoft Online Pte Ltd >>>>>> Tampines Central 1 #04-01 Tampines Plaza >>>>>> Singapore 529541 >>>>>> Republic of Singapore >>>>>> Mobile: +65-9648-9798 >>>>>> MSN:teoenming@hotmail.com >>>>>> Alma Maters: Singapore Polytechnic, National University of Singapore >>>>>> >>>>>> >>>>>> On 08/29/2009 06:42 AM, Tim Moore wrote: >>>>>>> >>>>>>> Teo, >>>>>>> >>>>>>> I have also performed the same exercise as yourself and I now >>>>>>> have successfully compiled all 3x patches into Xen, Qemu and the >>>>>>> BIOS File Loading in the hvmloader, this all compiles find on my >>>>>>> system. Suggest you do a "make clean" on the tools and start again ! >>>>>>> >>>>>>> After booting with the patched xen-unstable and adding the >>>>>>> gfx-passthru=1 parameter to my HVM DomU, as I suspected - it >>>>>>> still doesn''t work. >>>>>>> >>>>>>> I have both a 9500GT and GTX260(primary) in my Intel DX58SO >>>>>>> machine, tried passing through either device and my primary >>>>>>> display locks up ! (included hiding with pci-stub) >>>>>>> >>>>>>> I verified that the DomU was functional beforehand, as It also >>>>>>> booted successfully without the gfx-passthru parameter (and a >>>>>>> vncviewer/cirrus display) >>>>>>> >>>>>>> Unfortunately, I can''t debug further as my Primary display >>>>>>> corrupts as soon as the DomU starts. I did notice that in "xm >>>>>>> debug" the "Loading Gfx BIOS File.." message was displayed and >>>>>>> the DomU did continue to initialise the BIOS tables and such >>>>>>> before finally locking. I then (blindly) typed on a corrupt Dom0 >>>>>>> console and managed to start kdm and login, so the Dom0 was not >>>>>>> completely trashed. But then after a few minutes, the machine >>>>>>> totally froze and had to hit the reset switch. >>>>>>> >>>>>>> I`m no specialist but this looks like the VGA BIOS >>>>>>> Re-initialisation is playing havoc with the DomU and possibly >>>>>>> the Dom0 graphics. I notice that both are also using IRQ11 which >>>>>>> could play a major part. Furthermore, there was a lot of debug >>>>>>> output in the qemu and xend.log indicating Base Address Register >>>>>>> invalid access and therefore it seems there may be a second >>>>>>> obstacle. >>>>>>> >>>>>>> Hope you have a better success than me ! >>>>>>> >>>>>>> For now, I would try re-compiling a fresh xen-unstable with >>>>>>> carefully applied patches .. oh! and don''t forget to enable the >>>>>>> pci-stub driver for Dom0 (it''s not selected by default) >>>>>>> >>>>>>> Tim >>>>>>> >>>>>>> *From:* xen-devel-bounces@lists.xensource.com >>>>>>> [mailto:xen-devel-bounces@lists.xensource.com] *On Behalf Of >>>>>>> *Mr. Teo En Ming (Zhang Enming) >>>>>>> *Sent:* 28 August 2009 21:14 >>>>>>> *To:* enming.teo@asiasoftsea.net >>>>>>> *Cc:* xen-devel@lists.xensource.com; ''Lin, Ben Y''; ''Kay, Allen >>>>>>> M''; ''Jean Guyader''; Keir.Fraser@eu.citrix.com; >>>>>>> weidong.han@intel.com; bengheng@eecs.umich.edu >>>>>>> *Subject:* Re: [Xen-devel] [PATCH 2/2] graphics passthrough with >>>>>>> VT-d >>>>>>> >>>>>>> After applying the 1st and 2nd patch to xen-unstable successfully, I examined the source codes Makefile and hvmloader.c in tools/firmware/hvmloader, compared them to Weidong''s 3rd patch and I generated my own 3rd patch. Then I used my own generated 3rd patch to apply patching for loading vga bios from firmware file. >>>>>>> >>>>>>> Here is my own generated 3rd patch instead of using Weidong''s 3rd patch: >>>>>>> >>>>>>> --- Makefile 2009-08-29 03:24:52.413083774 +0800 >>>>>>> +++ Makefile 2009-08-29 03:29:12.763299633 +0800 >>>>>>> @@ -50,6 +50,7 @@ >>>>>>> roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \ >>>>>>> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h >>>>>>> sh ./mkhex rombios ../rombios/BIOS-bochs-latest> roms.h >>>>>>> + sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin>> roms.h >>>>>>> sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin>> roms.h >>>>>>> sh ./mkhex vgabios_cirrusvga \ >>>>>>> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin>> roms.h >>>>>>> --- hvmloader.c 2009-08-29 03:26:06.911085797 +0800 >>>>>>> +++ hvmloader.c 2009-08-29 03:31:43.172084995 +0800 >>>>>>> @@ -688,9 +688,9 @@ >>>>>>> vgabios_sz = round_option_rom(sizeof(vgabios_stdvga)); >>>>>>> break; >>>>>>> case VGA_pt: >>>>>>> - printf("Loading VGABIOS of passthroughed gfx ...\n"); >>>>>>> - vgabios_sz >>>>>>> - round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512); >>>>>>> + printf("Loading Gfx Video BIOS from file ...\n"); >>>>>>> + memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt, sizeof(vgabios_pt)); >>>>>>> + vgabios_sz = round_option_rom(sizeof(vgabios_pt)); >>>>>>> break; >>>>>>> default: >>>>>>> printf("No emulated VGA adaptor ...\n"); >>>>>>> >>>>>>> >>>>>>> I can "make xen" successfully but when I proceeded to "make tools", errors were encountered. >>>>>>> >>>>>>> Please see attached error output. How can I solve this problem? >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>>>>>> Technical Support Engineer >>>>>>> Information Technology Department >>>>>>> Asiasoft Online Pte Ltd >>>>>>> Tampines Central 1 #04-01 Tampines Plaza >>>>>>> Singapore 529541 >>>>>>> Republic of Singapore >>>>>>> Mobile: +65-9648-9798 >>>>>>> MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> >>>>>>> Alma Maters: Singapore Polytechnic, National University of Singapore >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 08/29/2009 12:59 AM, Mr. Teo En Ming (Zhang Enming) wrote: >>>>>>> >>>>>>> OK I believe the 3rd patch is not incomplete but there''s a white space issue when I copied the code from the mailing list into my vi. >>>>>>> >>>>>>> Seehttp://www.htdig.org/mail/2000/11/0167.html >>>>>>> >>>>>>> When I used the -l flag to patch using the 3rd patch, the number of errors was reduced. >>>>>>> >>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -l -p1< intel-gfx-passthru-patch-3.patch >>>>>>> patching file tools/firmware/hvmloader/Makefile >>>>>>> patching file tools/firmware/hvmloader/hvmloader.c >>>>>>> Hunk #1 FAILED at 688. >>>>>>> 1 out of 1 hunk FAILED -- saving rejects to file tools/firmware/hvmloader/hvmloader.c.rej >>>>>>> >>>>>>> Now patching tools/firmware/hvmloader/Makefile is successful but patching tools/firmware/hvmloader/hvmloader.c still failed. >>>>>>> >>>>>>> -- >>>>>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>>>>>> Technical Support Engineer >>>>>>> Information Technology Department >>>>>>> Asiasoft Online Pte Ltd >>>>>>> Tampines Central 1 #04-01 Tampines Plaza >>>>>>> Singapore 529541 >>>>>>> Republic of Singapore >>>>>>> Mobile: +65-9648-9798 >>>>>>> MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> >>>>>>> Alma Maters: Singapore Polytechnic, National University of Singapore >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 08/28/2009 11:55 PM, Mr. Teo En Ming (Zhang Enming) wrote: >>>>>>> >>>>>>> Dear Weidong, >>>>>>> >>>>>>> A big big thanks for the vga passthrough patches for xen >>>>>>> 3.5-unstable!!! These are eagerly anticipated patches. As I did >>>>>>> not study computer science and computer architecture, I won''t be >>>>>>> able to write those patches you guys at Intel wrote. >>>>>>> >>>>>>> I applied the following patches *xen-gfx-passthrough.patch >>>>>>> <http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin> >>>>>>> and qemu-gfx-passthrough.patch >>>>>>> <http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin> >>>>>>> to xen 3.5-unstable without issues.* >>>>>>> >>>>>>> Then I tried to apply the 3rd patch you provided at >>>>>>> http://lists.xensource.com/archives/html/xen-devel/2009-08/msg01047.html >>>>>>> >>>>>>> I saved the following code >>>>>>> >>>>>>> <CODE> >>>>>>> >>>>>>> diff -r 494be76c1ad9 tools/firmware/hvmloader/Makefile >>>>>>> --- a/tools/firmware/hvmloader/Makefile Thu Aug 27 16:54:33 2009 +0800 >>>>>>> +++ b/tools/firmware/hvmloader/Makefile Thu Aug 27 17:22:01 2009 +0800 >>>>>>> @@ -50,6 +50,7 @@ roms.h: ../rombios/BIOS-bochs-latest ../ >>>>>>> roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \ >>>>>>> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h >>>>>>> sh ./mkhex rombios ../rombios/BIOS-bochs-latest> roms.h >>>>>>> + sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin>> roms.h >>>>>>> sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin>> roms.h >>>>>>> sh ./mkhex vgabios_cirrusvga \ >>>>>>> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin>> roms.h >>>>>>> diff -r 494be76c1ad9 tools/firmware/hvmloader/hvmloader.c >>>>>>> --- a/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 16:54:33 2009 +0800 >>>>>>> +++ b/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 17:23:00 2009 +0800 >>>>>>> @@ -688,9 +688,9 @@ int main(void) >>>>>>> vgabios_sz = round_option_rom(sizeof(vgabios_stdvga)); >>>>>>> break; >>>>>>> case VGA_pt: >>>>>>> - printf("Loading Gfx Video BIOS from 0xC0000 ...\n"); >>>>>>> - vgabios_sz >>>>>>> - round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512); >>>>>>> + printf("Loading Gfx Video BIOS from file ...\n"); >>>>>>> + memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt, >>>>>>> sizeof(vgabios_pt)); >>>>>>> + vgabios_sz = round_option_rom(sizeof(vgabios_pt)); >>>>>>> break; >>>>>>> default: >>>>>>> printf("No emulated VGA adaptor ...\n"); >>>>>>> >>>>>>> </CODE> >>>>>>> >>>>>>> as intel-gfx-passthru-patch-3.patch and then I tried to apply the patch to xen 3.5-unstable. I got errors. I think it''s because the 3rd patch you provided is incomplete. >>>>>>> >>>>>>> Here''s my patching process: >>>>>>> >>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name vgabios >>>>>>> ./tools/firmware/vgabios >>>>>>> ./.hg/store/data/tools/firmware/vgabios >>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cp ~enming/vgabios-pt.bin tools/firmware/vgabios/ >>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ls tools/firmware/vgabios/ >>>>>>> biossums.c clext.c Makefile TODO vbe.h vgabios.h vgatables.h >>>>>>> BUGS COPYING Notes vbe.c vbetables-gen.c vgabios-pt.bin >>>>>>> ChangeLog dataseghack README vbe_display_api.txt vgabios.c vgafonts.h >>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# pwd >>>>>>> /usr/src/xen-unstable.hg-vgapt >>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wgethttp://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin >>>>>>> --2009-08-28 23:18:21--http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin >>>>>>> Resolving lists.xensource.com... 70.42.241.110 >>>>>>> Connecting to lists.xensource.com|70.42.241.110|:80... connected. >>>>>>> HTTP request sent, awaiting response... 200 OK >>>>>>> Length: 12565 (12K) [application/octet-stream] >>>>>>> Saving to: `bincPiiAf0QWg.bin'' >>>>>>> >>>>>>> 100%[======================================================================>] 12,565 30.7K/s in 0.4s >>>>>>> >>>>>>> 2009-08-28 23:18:22 (30.7 KB/s) - `bincPiiAf0QWg.bin'' saved [12565/12565] >>>>>>> >>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv bincPiiAf0QWg.bin xen-gfx-passthrough.patch >>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi xen-gfx-passthrough.patch >>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch< xen-gfx-passthrough.patch >>>>>>> can''t find file to patch at input line 4 >>>>>>> Perhaps you should have used the -p or --strip option? >>>>>>> The text leading up to this was: >>>>>>> -------------------------- >>>>>>> |diff -r 5d7e7a250267 tools/firmware/hvmloader/config.h >>>>>>> |--- a/tools/firmware/hvmloader/config.h Wed Aug 26 18:28:44 2009 +0800 >>>>>>> |+++ b/tools/firmware/hvmloader/config.h Thu Aug 27 16:54:24 2009 +0800 >>>>>>> -------------------------- >>>>>>> File to patch: ^C >>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ex xen-gfx-passthrough.patch >>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1< xen-gfx-passthrough.patch >>>>>>> patching file tools/firmware/hvmloader/config.h >>>>>>> patching file tools/firmware/hvmloader/hvmloader.c >>>>>>> patching file tools/libxc/ia64/xc_ia64_hvm_build.c >>>>>>> patching file tools/libxc/xc_hvm_build.c >>>>>>> patching file tools/libxc/xc_linux.c >>>>>>> patching file tools/libxc/xenctrl.h >>>>>>> patching file tools/libxc/xenguest.h >>>>>>> patching file tools/python/xen/lowlevel/xc/xc.c >>>>>>> patching file tools/python/xen/xend/XendConfig.py >>>>>>> Hunk #1 succeeded at 174 (offset -1 lines). >>>>>>> patching file tools/python/xen/xend/image.py >>>>>>> Hunk #1 succeeded at 780 (offset -6 lines). >>>>>>> Hunk #3 succeeded at 895 (offset -6 lines). >>>>>>> patching file tools/python/xen/xm/create.py >>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wgethttp://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin >>>>>>> --2009-08-28 23:21:35--http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin >>>>>>> Resolving lists.xensource.com... 70.42.241.110 >>>>>>> Connecting to lists.xensource.com|70.42.241.110|:80... connected. >>>>>>> HTTP request sent, awaiting response... 200 OK >>>>>>> Length: 9841 (9.6K) [application/octet-stream] >>>>>>> Saving to: `binglLqkeq4Rj.bin'' >>>>>>> >>>>>>> 100%[======================================================================>] 9,841 24.3K/s in 0.4s >>>>>>> >>>>>>> 2009-08-28 23:21:36 (24.3 KB/s) - `binglLqkeq4Rj.bin'' saved [9841/9841] >>>>>>> >>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv binglLqkeq4Rj.bin qemu-gfx-passthrough.patch >>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi qemu-gfx-passthrough.patch >>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name hw >>>>>>> ./tools/ioemu-remote/hw >>>>>>> ./.hg/store/data/tools/ioemu/hw >>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv qemu-gfx-passthrough.patch tools/ioemu-remote/ >>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cd tools/ioemu-remote/ >>>>>>> [root@fedora11-x86-64-host ioemu-remote]# patch -p1< qemu- >>>>>>> qemu-aio.h qemu-img.c qemu-sockets.c >>>>>>> qemu-binfmt-conf.sh qemu-img.texi qemu-tech.texi >>>>>>> qemu-char.c qemu-lock.h qemu-timer.h >>>>>>> qemu-char.h qemu-log.h qemu-tool.c >>>>>>> qemu-common.h qemu-malloc.c qemu-xen.h >>>>>>> qemu-doc.texi qemu-nbd.c >>>>>>> qemu-gfx-passthrough.patch qemu-nbd.texi >>>>>>> [root@fedora11-x86-64-host ioemu-remote]# patch -p1< qemu-gfx-passthrough.patch >>>>>>> patching file hw/pass-through.c >>>>>>> patching file hw/pass-through.h >>>>>>> patching file hw/pc.c >>>>>>> patching file vl.c >>>>>>> [root@fedora11-x86-64-host ioemu-remote]# cd .. >>>>>>> [root@fedora11-x86-64-host tools]# cd .. >>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi intel-gfx-passthru-patch-3.patch >>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1< intel-gfx-passthru-patch-3.patch >>>>>>> patching file tools/firmware/hvmloader/Makefile >>>>>>> Hunk #1 FAILED at 50. >>>>>>> 1 out of 1 hunk FAILED -- saving rejects to file tools/firmware/hvmloader/Makefile.rej >>>>>>> patching file tools/firmware/hvmloader/hvmloader.c >>>>>>> patch: **** malformed patch at line 24: sizeof(vgabios_pt)); >>>>>>> >>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi intel-gfx-passthru-patch-3.patch >>>>>>> >>>>>>> For everybody''s convenience, I have attached intel-gfx-passthru-patch-3.patch and the firmware for my nVidia GeForce 8400 GS PCI Express x16 graphics card in this email. >>>>>>> >>>>>>> Please help me complete intel-gfx-passthru-patch-3.patch as I really need it. >>>>>>> >>>>>>> Thank you very much!!! >>>>>>> >>>>>>> -- >>>>>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>>>>>> Technical Support Engineer >>>>>>> Information Technology Department >>>>>>> Asiasoft Online Pte Ltd >>>>>>> Tampines Central 1 #04-01 Tampines Plaza >>>>>>> Singapore 529541 >>>>>>> Republic of Singapore >>>>>>> Mobile: +65-9648-9798 >>>>>>> MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> >>>>>>> Alma Maters: Singapore Polytechnic, National University of Singapore >>>>>>> >>>>>>> This patch supports basic gfx passthrough on QEMU: >>>>>>> >>>>>>> - disable emulated VGA adpater if there is passthroughed gfx >>>>>>> >>>>>>> - register/unregister legacy VGA I/O ports and MMIOs for passthroughed gfx >>>>>>> >>>>>>> >>>>>>> >>>>>>> Signed-off-by: Ben Lin<ben.y.lin@intel.com> <mailto:ben.y.lin@intel.com> >>>>>>> >>>>>>> Signed-off-by: Weidong Han<weidong.han@intel.com> <mailto:weidong.han@intel.com> >>>>>>> >>>>>>> No virus found in this incoming message. >>>>>>> >>>>>>> Checked by AVG -www.avg.com <http://www.avg.com> >>>>>>> >>>>>>> Version: 8.5.409 / Virus Database: 270.13.69/2328 - Release Date: 08/27/09 >>>>>>> >>>>>>> 18:02:00 >>>>>>> >>>>>>> >>>>>>> >>>>>>> No virus found in this outgoing message. >>>>>>> >>>>>>> Checked by AVG -www.avg.com <http://www.avg.com> >>>>>>> >>>>>>> Version: 8.5.409 / Virus Database: 270.13.71/2330 - Release Date: 08/27/09 >>>>>>> >>>>>>> 18:02:00 >>>>>>> >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> >>>>>>> Xen-devel mailing list >>>>>>> >>>>>>> Xen-devel@lists.xensource.com <mailto:Xen-devel@lists.xensource.com> >>>>>>> >>>>>>> http://lists.xensource.com/xen-devel >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Xen-devel mailing list >>>>>>> Xen-devel@lists.xensource.com <mailto: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 >>>>>> >>>>> >>>>> >>>> >>> >>> >> >> > >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mr. Teo En Ming (Zhang Enming)
2009-Aug-29 14:12 UTC
Re: [Xen-devel] graphics passthrough with VT-d
Hi Timothy, Yes, I renamed the firmware file of nVidia Geforce 8400 GS to vgabios-pt.bin and placed it in the source directory tools/firmware/vgabios. Weidong had said Intel has the 1:1 mapping patches. Let''s hope he will release the patch soon to do pBAR:vBAR. -- Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) Technical Support Engineer Information Technology Department Asiasoft Online Pte Ltd Tampines Central 1 #04-01 Tampines Plaza Singapore 529541 Republic of Singapore Company Website: http://www.asiasoft.sg/ Mobile: +65-9648-9798 MSN: teoenming@hotmail.com Alma Maters: Singapore Polytechnic, National University of Singapore On 08/29/2009 09:29 PM, Tim Moore wrote:> > Teo, > > Did you rename your Nvidia BIOS and copy it into the hvmloader source > tree as required ? > > It should get compiled into roms.h in the hvmloader folder - I made > sure it was there as the xen buildroot seems to delete it randomly ... > > I think we are now up against the Base Address Register issue where > the Nvidia driver is expecting to see the card at the Physical BAR > Addresses and in the DomU these are re-mapped to different address > space ... this is a problem with the Nvidia binary driver and > therefore a workaround in xen is maybe needed. > > That said, I''m not sure if the Nvidia BIOS likes to be re-executed and > may also be an issue ... > > Tim > > *From:* Mr. Teo En Ming (Zhang Enming) > [mailto:enming.teo@asiasoftsea.net] > *Sent:* 29 August 2009 14:21 > *To:* enming.teo@asiasoftsea.net > *Cc:* Tim Moore; xen-devel@lists.xensource.com > *Subject:* Re: [Xen-devel] graphics passthrough with VT-d > > Dear All, > > I have applied the following patches to xen 3.5-unstable > > 1) intel-gfx-passthru-patch01.patch > 2) intel-gfx-passthru-patch02.patch > 3) intel-gfx-passthru-patch03.patch > 4) enming-patch04.patch > > and compiled xen 3.5-unstable successfully (both hypervisor and tools). > > i rebooted into this newly compiled Xen hypervisor which supports > loading vga bios from firmware file of nVidia Geforce 8400 GS PCI > Express x16. > > After dom0 has booted up, I executed the following script to hide > nVidia Geforce 8400 GS from dom0. > > [enming@fedora11-x86-64-host scripts]$ cat bind-devices-pci-stub.sh > #!/bin/sh > echo "10de 06e4" > /sys/bus/pci/drivers/pci-stub/new_id > echo "0000:01:00.0" > /sys/bus/pci/devices/0000:01:00.0/driver/unbind > echo "0000:01:00.0" > /sys/bus/pci/drivers/pci-stub/bind > > I also assigned the nVidia Geforce 8400 GS to my Windows XP Home HVM domU. > > pci = [ ''01:00.0'' ] > > I also specified gfx_passthru=2. > > Do note that I booted up with onboard Intel GMA4500 as the primary > video adapter. Hence dom 0 has onboard graphics and Windows XP HVM > domU has nvidia graphics. > > Then I started Windows XP Home HVM DomU. > > Very soon, my Dom 0''s display was garbaged and X server on Dom 0 > totally froze and became unresponsive. I cannot switch to any ttys. > > However, I was still able to vnc into my Windows XP Home HVM Dom U. I > had earlier installed a VNC server into my Windows XP guest. After > remoting in to my Windows XP DomU through vnc, I found that NVIDIA > Geforce 8400 GS cannot be initialized and no resources are available > for this graphics card. > > > -- > Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) > Technical Support Engineer > Information Technology Department > Asiasoft Online Pte Ltd > Tampines Central 1 #04-01 Tampines Plaza > Singapore 529541 > Republic of Singapore > Company Website:http://www.asiasoft.sg/ > Mobile: +65-9648-9798 > MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> > Alma Maters: Singapore Polytechnic, National University of Singapore > > > > On 08/29/2009 08:25 PM, Mr. Teo En Ming (Zhang Enming) wrote: > > Hi All, > > I have solved the problem encountered below when building tools for > xen 3.5-unstable. The compile problem exists because I downloaded and > compiled the latest version of Intel ACPI Component Architecture > compiler version 20090730. And I used this latest compiler during > "make tools" for xen-unstable. > > In original xen-unstable source codes cloned from xensoure mercurial > repository, the header files ssdt_pm.h and ssdt_tpm.h in source > directory tools/firmware/hvmloader/acpi/ are generated by > > /* > * > * Intel ACPI Component Architecture > * ASL Optimizing Compiler version 20061109 [May 18 2007] > * Copyright (C) 2000 - 2006 Intel Corporation > * Supports ACPI Specification Revision 3.0a > * > * Compilation of "ssdt_pm.asl" - Sun Oct 12 23:57:51 2008 > * > * C source code output > * > */ > > In original ssdt_pm.h, it has "unsigned char AmlCode_PM[] =". > > In original ssdt_tpm.h, it has "unsigned char AmlCode_TPM[] =". > > Hence there was no problem with "make tools". > > But, I downloaded, compiled and used > > /* > * > * Intel ACPI Component Architecture > * ASL Optimizing Compiler version 20090730 [Aug 29 2009] > * Copyright (C) 2000 - 2009 Intel Corporation > * Supports ACPI Specification Revision 4.0 > * > * Compilation of "ssdt_pm.asl" - Sat Aug 29 18:55:40 2009 > * > * C source code output > * > */ > > So the *new* ssdt_pm.h contains: > > /* > * > * Intel ACPI Component Architecture > * ASL Optimizing Compiler version 20090730 [Aug 29 2009] > * Copyright (C) 2000 - 2009 Intel Corporation > * Supports ACPI Specification Revision 4.0 > * > * Compilation of "ssdt_pm.asl" - Sat Aug 29 18:55:40 2009 > * > * C source code output > * > */ > unsigned char AmlCode[] > { > 0x53,0x53,0x44,0x54,0xD6,0x05,0x00,0x00, /* 00000000 "SSDT...." */ > 0x02,0xB9,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008 "..Xen..." */ > 0x48,0x56,0x4D,0x00,0x00,0x00,0x00,0x00, /* 00000010 "HVM....." */ > 0x00,0x00,0x00,0x00,0x49,0x4E,0x54,0x4C, /* 00000018 "....INTL" */ > 0x30,0x07,0x09,0x20,0x10,0x41,0x5B,0x5C, /* 00000020 "0.. .A[\" */ > 0x5F,0x53,0x42,0x5F,0x5B,0x80,0x44,0x42, /* 00000028 "_SB_[.DB" */ > 0x47,0x41,0x01,0x0B,0x40,0xB0,0x01,0x5B, /* 00000030 "GA..@..[" > <mailto:GA..@..%5B> */ > 0x81,0x0B,0x44,0x42,0x47,0x41,0x01,0x44, /* 00000038 "..DBGA.D" */ > 0x42,0x47,0x31,0x08,0x5B,0x80,0x44,0x42, /* 00000040 "BG1.[.DB" */ > 0x47,0x42,0x01,0x0B,0x44,0xB0,0x01,0x5B, /* 00000048 "GB..D..[" */ > 0x81,0x0B,0x44,0x42,0x47,0x42,0x01,0x44, /* 00000050 "..DBGB.D" */ > 0x42,0x47,0x32,0x08,0x5B,0x80,0x44,0x42, /* 00000058 "BG2.[.DB" */ > 0x47,0x43,0x01,0x0B,0x46,0xB0,0x01,0x5B, /* 00000060 "GC..F..[" */ > 0x81,0x0B,0x44,0x42,0x47,0x43,0x01,0x44, /* 00000068 "..DBGC.D" */ > 0x42,0x47,0x33,0x08,0x5B,0x80,0x44,0x42, /* 00000070 "BG3.[.DB" */ > 0x47,0x44,0x01,0x0B,0x48,0xB0,0x01,0x5B, /* 00000078 "GD..H..[" */ > 0x81,0x0B,0x44,0x42,0x47,0x44,0x01,0x44, /* 00000080 "..DBGD.D" */ > 0x42,0x47,0x34,0x08,0x5B,0x80,0x50,0x52, /* 00000088 "BG4.[.PR" */ > 0x54,0x31,0x01,0x0A,0xB2,0x0A,0x02,0x5B, /* 00000090 "T1.....[" */ > 0x81,0x10,0x50,0x52,0x54,0x31,0x01,0x50, /* 00000098 "..PRT1.P" */ > 0x42,0x32,0x5F,0x08,0x50,0x42,0x32,0x41, /* 000000A0 "B2_.PB2A" */ > 0x08,0x5B,0x80,0x50,0x52,0x54,0x32,0x01, /* 000000A8 ".[.PRT2." */ > 0x0A,0x86,0x01,0x5B,0x81,0x0B,0x50,0x52, /* 000000B0 "...[..PR" */ > 0x54,0x32,0x01,0x50,0x38,0x36,0x5F,0x08, /* 000000B8 "T2.P86_." */ > 0x5B,0x80,0x50,0x52,0x54,0x33,0x01,0x0A, /* 000000C0 "[.PRT3.." */ > 0x88,0x01,0x5B,0x81,0x0B,0x50,0x52,0x54, /* 000000C8 "..[..PRT" */ > 0x33,0x01,0x50,0x38,0x38,0x5F,0x08,0x5B, /* 000000D0 "3.P88_.[" */ > 0x01,0x53,0x59,0x4E,0x43,0x01,0x08,0x42, /* 000000D8 ".SYNC..B" */ > 0x55,0x46,0x30,0x11,0x04,0x0B,0x00,0x01, /* 000000E0 "UF0....." */ > 0x08,0x42,0x55,0x46,0x31,0x11,0x03,0x0A, /* 000000E8 ".BUF1..." */ > 0x08,0x8B,0x42,0x55,0x46,0x31,0x00,0x42, /* 000000F0 "..BUF1.B" */ > 0x55,0x46,0x41,0x8B,0x42,0x55,0x46,0x31, /* 000000F8 "UFA.BUF1" */ > 0x0A,0x04,0x42,0x55,0x46,0x42,0x14,0x14, /* 00000100 "..BUFB.." */ > > And the *new* ssdt_tpm.h contains: > > /* > * > * Intel ACPI Component Architecture > * ASL Optimizing Compiler version 20090730 [Aug 29 2009] > * Copyright (C) 2000 - 2009 Intel Corporation > * Supports ACPI Specification Revision 4.0 > * > * Compilation of "ssdt_tpm.asl" - Sat Aug 29 18:55:40 2009 > * > * C source code output > * > */ > unsigned char AmlCode[] > { > 0x53,0x53,0x44,0x54,0x4C,0x00,0x00,0x00, /* 00000000 "SSDTL..." */ > 0x02,0x2A,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008 ".*Xen..." */ > 0x48,0x56,0x4D,0x00,0x00,0x00,0x00,0x00, /* 00000010 "HVM....." */ > 0x00,0x00,0x00,0x00,0x49,0x4E,0x54,0x4C, /* 00000018 "....INTL" */ > 0x30,0x07,0x09,0x20,0x5B,0x82,0x26,0x54, /* 00000020 "0.. [.&T" */ > 0x50,0x4D,0x5F,0x08,0x5F,0x48,0x49,0x44, /* 00000028 "PM_._HID" */ > 0x0C,0x41,0xD0,0x0C,0x31,0x08,0x5F,0x43, /* 00000030 ".A..1._C" */ > 0x52,0x53,0x11,0x11,0x0A,0x0E,0x86,0x09, /* 00000038 "RS......" */ > 0x00,0x01,0x00,0x00,0xD4,0xFE,0x00,0x50, /* 00000040 ".......P" */ > 0x00,0x00,0x79,0x00, > }; > > which are both wrong. > > In ssdt_pm.h, I have to change "unsigned char AmlCode[]" to "unsigned > char AmlCode_PM[]". > > In ssdt_tpm.h, I have to change "unsigned char AmlCode[]" to "unsigned > char AmlCode_TPM[]". > > Then "make tools" is able to complete successfully. > > I have created a patch for anybody who may be using the *latest* > version of Intel ACPI CA compiler version 20090730 and attached it here. > > Patch file filename enming-patch04.patch: > > <CODE> > > Patch created by Teo En Ming (Zhang Enming) on 29 August 2009 Saturday > at 8:00 P.M. Singapore Time > Email #1: enming.teo@asiasoftsea.net <mailto:enming.teo@asiasoftsea.net> > Email #2: space.time.universe@gmail.com > <mailto:space.time.universe@gmail.com> > MSN: teoenming@hotmail.com <mailto:teoenming@hotmail.com> > Mobile Phone: +65-9648-9798 > > --- ssdt_pm.h 2009-08-29 19:54:52.653088000 +0800 > +++ ssdt_pm.h 2009-08-29 19:56:51.813088550 +0800 > @@ -10,7 +10,7 @@ > * C source code output > * > */ > -unsigned char AmlCode[] > +unsigned char AmlCode_PM[] > { > 0x53,0x53,0x44,0x54,0xD6,0x05,0x00,0x00, /* 00000000 > "SSDT...." */ > 0x02,0xB9,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008 > "..Xen..." */ > --- ssdt_tpm.h 2009-08-29 19:55:44.578738954 +0800 > +++ ssdt_tpm.h 2009-08-29 19:57:27.896638884 +0800 > @@ -10,7 +10,7 @@ > * C source code output > * > */ > -unsigned char AmlCode[] > +unsigned char AmlCode_TPM[] > { > 0x53,0x53,0x44,0x54,0x4C,0x00,0x00,0x00, /* 00000000 > "SSDTL..." */ > 0x02,0x2A,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008 > ".*Xen..." */ > > </CODE> > > > -- > Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) > Technical Support Engineer > Information Technology Department > Asiasoft Online Pte Ltd > Tampines Central 1 #04-01 Tampines Plaza > Singapore 529541 > Republic of Singapore > Company Website:http://www.asiasoft.sg/ > Mobile: +65-9648-9798 > MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> > Alma Maters: Singapore Polytechnic, National University of Singapore > > > > On 08/29/2009 07:03 PM, Mr. Teo En Ming (Zhang Enming) wrote: > > Hi, > > I clonedhttp://xenbits.xensource.com/xen-unstable.hg again today. I tried applying the three Intel gfx passthrough patches to xen-unstable. When I "make tools", I get the same error again: > > make[7]: Entering directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader'' > make -C acpi all > get-path: will use #!/usr/bin/python2.6 for python programs > make[8]: Entering directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' > make iasl > get-path: will use #!/usr/bin/python2.6 for python programs > make[9]: Entering directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' > make[9]: `/usr/local/bin/iasl'' is up to date. > make[9]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' > iasl -tc ssdt_tpm.asl > > Intel ACPI Component Architecture > ASL Optimizing Compiler version 20090730 [Aug 29 2009] > Copyright (C) 2000 - 2009 Intel Corporation > Supports ACPI Specification Revision 4.0 > > ASL Input: ssdt_tpm.asl - 31 lines, 1111 bytes, 3 keywords > AML Output: SSDT_TPM.aml - 76 bytes, 3 named objects, 0 executable opcodes > > Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 0 Optimizations > mv ssdt_tpm.hex ssdt_tpm.h > rm -f *.aml > make iasl > get-path: will use #!/usr/bin/python2.6 for python programs > make[9]: Entering directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' > make[9]: `/usr/local/bin/iasl'' is up to date. > make[9]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' > iasl -tc ssdt_pm.asl > > Intel ACPI Component Architecture > ASL Optimizing Compiler version 20090730 [Aug 29 2009] > Copyright (C) 2000 - 2009 Intel Corporation > Supports ACPI Specification Revision 4.0 > > ASL Input: ssdt_pm.asl - 425 lines, 12754 bytes, 192 keywords > AML Output: SSDT_PM.aml - 1494 bytes, 64 named objects, 128 executable opcodes > > Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 31 Optimizations > mv ssdt_pm.hex ssdt_pm.h > rm -f *.aml > gcc -O1 -fno-omit-frame-pointer -fno-optimize-sibling-calls -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .build.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs -Werror -fno-stack-protector -fno-builtin -msoft-float -I. -I.. -I../../../../tools/include -c -o build.o build.c > In file included from build.c:21: > ssdt_pm.h:13: error: redefinition of ''AmlCode'' > ssdt_tpm.h:13: note: previous definition of ''AmlCode'' was here > build.c: In function ''construct_secondary_tables'': > build.c:184: error: ''AmlCode_PM'' undeclared (first use in this function) > build.c:184: error: (Each undeclared identifier is reported only once > build.c:184: error: for each function it appears in.) > build.c:194: error: ''AmlCode_TPM'' undeclared (first use in this function) > make[8]: *** [build.o] Error 1 > make[8]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' > make[7]: *** [subdir-all-acpi] Error 2 > make[7]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader'' > make[6]: *** [subdirs-all] Error 2 > make[6]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader'' > make[5]: *** [subdir-all-hvmloader] Error 2 > make[5]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware'' > make[4]: *** [subdirs-all] Error 2 > make[4]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware'' > make[3]: *** [all] Error 2 > make[3]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware'' > make[2]: *** [subdir-install-firmware] Error 2 > make[2]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools'' > make[1]: *** [subdirs-install] Error 2 > make[1]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools'' > make: *** [install-tools] Error 2 > > Any ideas about this Advanced Configuration and Power Interface code? > > -- > Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) > Technical Support Engineer > Information Technology Department > Asiasoft Online Pte Ltd > Tampines Central 1 #04-01 Tampines Plaza > Singapore 529541 > Republic of Singapore > Company Website:http://www.asiasoft.sg/ > Mobile: +65-9648-9798 > MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> > Alma Maters: Singapore Polytechnic, National University of Singapore > > > > On 08/29/2009 02:58 PM, Mr. Teo En Ming (Zhang Enming) wrote: > > Hi > > Anybody available today? I know it''s Saturday. :-) > > > -- > Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) > Technical Support Engineer > Information Technology Department > Asiasoft Online Pte Ltd > Tampines Central 1 #04-01 Tampines Plaza > Singapore 529541 > Republic of Singapore > Company Website:http://www.asiasoft.sg/ > Mobile: +65-9648-9798 > MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> > Alma Maters: Singapore Polytechnic, National University of Singapore > > > > On 08/29/2009 11:48 AM, Mr. Teo En Ming (Zhang Enming) wrote: > > > > Dear All, > > After applying Intel VGA passthrough patches 1, 2 and 3, I have no problems with "make xen", and "make install-xen". However, I have errors with "make tools". > > Here is the error output: > > msoft-float -I. -I.. -I../../../../tools/include -c -o build.o build.c > build.c: In function ''construct_secondary_tables'': > build.c:194: error: ''AmlCode_TPM'' undeclared (first use in this function) > build.c:194: error: (Each undeclared identifier is reported only once > build.c:194: error: for each function it appears in.) > make[8]: *** [build.o] Error 1 > make[8]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader/acpi'' > make[7]: *** [subdir-all-acpi] Error 2 > make[7]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader'' > make[6]: *** [subdirs-all] Error 2 > make[6]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader'' > make[5]: *** [subdir-all-hvmloader] Error 2 > make[5]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'' > make[4]: *** [subdirs-all] Error 2 > make[4]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'' > make[3]: *** [all] Error 2 > make[3]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'' > make[2]: *** [subdir-install-firmware] Error 2 > make[2]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools'' > make[1]: *** [subdirs-install] Error 2 > make[1]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools'' > make: *** [install-tools] Error 2 > > There is an undeclared identifier in tools/firmware/hvmloader/acpi/build.c source code. Could you guys help me resolve this issue? > > I had no problems compiling xen 3.5-unstable before applying the Intel vga passthrough patches and before installing the Intel ACPI Component Architecture compiler. > > I have also attached Intel graphics passthrough patches 1, 2 and 3 for your convenience here. > > Thank you very much. > > Hope I can get this working during the weekends. > > -- > Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) > Technical Support Engineer > Information Technology Department > Asiasoft Online Pte Ltd > Tampines Central 1 #04-01 Tampines Plaza > Singapore 529541 > Republic of Singapore > Company Website:http://www.asiasoft.sg/ > Mobile: +65-9648-9798 > MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> > Alma Maters: Singapore Polytechnic, National University of Singapore > > > > On 08/29/2009 10:17 AM, Mr. Teo En Ming (Zhang Enming) wrote: > > Hi Tim, > > I thought it should be gfx_passthru=2 in domU config? > > -- > Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) > Technical Support Engineer > Information Technology Department > Asiasoft Online Pte Ltd > Tampines Central 1 #04-01 Tampines Plaza > Singapore 529541 > Republic of Singapore > Mobile: +65-9648-9798 > MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> > Alma Maters: Singapore Polytechnic, National University of Singapore > > > > On 08/29/2009 06:42 AM, Tim Moore wrote: > > Teo, > > I have also performed the same exercise as yourself and I now have > successfully compiled all 3x patches into Xen, Qemu and the BIOS File > Loading in the hvmloader, this all compiles find on my system. Suggest > you do a "make clean" on the tools and start again ! > > After booting with the patched xen-unstable and adding the > gfx-passthru=1 parameter to my HVM DomU, as I suspected - it still > doesn''t work. > > I have both a 9500GT and GTX260(primary) in my Intel DX58SO machine, > tried passing through either device and my primary display locks up ! > (included hiding with pci-stub) > > I verified that the DomU was functional beforehand, as It also booted > successfully without the gfx-passthru parameter (and a > vncviewer/cirrus display) > > Unfortunately, I can''t debug further as my Primary display corrupts as > soon as the DomU starts. I did notice that in "xm debug" the "Loading > Gfx BIOS File.." message was displayed and the DomU did continue to > initialise the BIOS tables and such before finally locking. I then > (blindly) typed on a corrupt Dom0 console and managed to start kdm and > login, so the Dom0 was not completely trashed. But then after a few > minutes, the machine totally froze and had to hit the reset switch. > > I`m no specialist but this looks like the VGA BIOS Re-initialisation > is playing havoc with the DomU and possibly the Dom0 graphics. I > notice that both are also using IRQ11 which could play a major part. > Furthermore, there was a lot of debug output in the qemu and xend.log > indicating Base Address Register invalid access and therefore it seems > there may be a second obstacle. > > Hope you have a better success than me ! > > For now, I would try re-compiling a fresh xen-unstable with carefully > applied patches .. oh! and don''t forget to enable the pci-stub driver > for Dom0 (it''s not selected by default) > > Tim > > *From:* xen-devel-bounces@lists.xensource.com > <mailto:xen-devel-bounces@lists.xensource.com> > [mailto:xen-devel-bounces@lists.xensource.com] *On Behalf Of *Mr. Teo > En Ming (Zhang Enming) > *Sent:* 28 August 2009 21:14 > *To:* enming.teo@asiasoftsea.net <mailto:enming.teo@asiasoftsea.net> > *Cc:* xen-devel@lists.xensource.com > <mailto:xen-devel@lists.xensource.com>; ''Lin, Ben Y''; ''Kay, Allen M''; > ''Jean Guyader''; Keir.Fraser@eu.citrix.com > <mailto:Keir.Fraser@eu.citrix.com>; weidong.han@intel.com > <mailto:weidong.han@intel.com>; bengheng@eecs.umich.edu > <mailto:bengheng@eecs.umich.edu> > *Subject:* Re: [Xen-devel] [PATCH 2/2] graphics passthrough with VT-d > > After applying the 1st and 2nd patch to xen-unstable successfully, I examined the source codes Makefile and hvmloader.c in tools/firmware/hvmloader, compared them to Weidong''s 3rd patch and I generated my own 3rd patch. Then I used my own generated 3rd patch to apply patching for loading vga bios from firmware file. > > Here is my own generated 3rd patch instead of using Weidong''s 3rd patch: > > --- Makefile 2009-08-29 03:24:52.413083774 +0800 > +++ Makefile 2009-08-29 03:29:12.763299633 +0800 > @@ -50,6 +50,7 @@ > roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \ > ../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h > sh ./mkhex rombios ../rombios/BIOS-bochs-latest> roms.h > + sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin>> roms.h > sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin>> roms.h > sh ./mkhex vgabios_cirrusvga \ > ../vgabios/VGABIOS-lgpl-latest.cirrus.bin>> roms.h > --- hvmloader.c 2009-08-29 03:26:06.911085797 +0800 > +++ hvmloader.c 2009-08-29 03:31:43.172084995 +0800 > @@ -688,9 +688,9 @@ > vgabios_sz = round_option_rom(sizeof(vgabios_stdvga)); > break; > case VGA_pt: > - printf("Loading VGABIOS of passthroughed gfx ...\n"); > - vgabios_sz > - round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512); > + printf("Loading Gfx Video BIOS from file ...\n"); > + memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt, sizeof(vgabios_pt)); > + vgabios_sz = round_option_rom(sizeof(vgabios_pt)); > break; > default: > printf("No emulated VGA adaptor ...\n"); > > > I can "make xen" successfully but when I proceeded to "make tools", errors were encountered. > > Please see attached error output. How can I solve this problem? > > > -- > Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) > Technical Support Engineer > Information Technology Department > Asiasoft Online Pte Ltd > Tampines Central 1 #04-01 Tampines Plaza > Singapore 529541 > Republic of Singapore > Mobile: +65-9648-9798 > MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> > Alma Maters: Singapore Polytechnic, National University of Singapore > > > > On 08/29/2009 12:59 AM, Mr. Teo En Ming (Zhang Enming) wrote: > > OK I believe the 3rd patch is not incomplete but there''s a white space issue when I copied the code from the mailing list into my vi. > > Seehttp://www.htdig.org/mail/2000/11/0167.html > > When I used the -l flag to patch using the 3rd patch, the number of errors was reduced. > > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -l -p1< intel-gfx-passthru-patch-3.patch > patching file tools/firmware/hvmloader/Makefile > patching file tools/firmware/hvmloader/hvmloader.c > Hunk #1 FAILED at 688. > 1 out of 1 hunk FAILED -- saving rejects to file tools/firmware/hvmloader/hvmloader.c.rej > > Now patching tools/firmware/hvmloader/Makefile is successful but patching tools/firmware/hvmloader/hvmloader.c still failed. > > -- > Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) > Technical Support Engineer > Information Technology Department > Asiasoft Online Pte Ltd > Tampines Central 1 #04-01 Tampines Plaza > Singapore 529541 > Republic of Singapore > Mobile: +65-9648-9798 > MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> > Alma Maters: Singapore Polytechnic, National University of Singapore > > > > > On 08/28/2009 11:55 PM, Mr. Teo En Ming (Zhang Enming) wrote: > > Dear Weidong, > > A big big thanks for the vga passthrough patches for xen > 3.5-unstable!!! These are eagerly anticipated patches. As I did not > study computer science and computer architecture, I won''t be able to > write those patches you guys at Intel wrote. > > I applied the following patches *xen-gfx-passthrough.patch > <http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin> > and qemu-gfx-passthrough.patch > <http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin> > to xen 3.5-unstable without issues.* > > Then I tried to apply the 3rd patch you provided at > http://lists.xensource.com/archives/html/xen-devel/2009-08/msg01047.html > > I saved the following code > > <CODE> > > diff -r 494be76c1ad9 tools/firmware/hvmloader/Makefile > --- a/tools/firmware/hvmloader/Makefile Thu Aug 27 16:54:33 2009 +0800 > +++ b/tools/firmware/hvmloader/Makefile Thu Aug 27 17:22:01 2009 +0800 > @@ -50,6 +50,7 @@ roms.h: ../rombios/BIOS-bochs-latest ../ > roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \ > ../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h > sh ./mkhex rombios ../rombios/BIOS-bochs-latest> roms.h > + sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin>> roms.h > sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin>> roms.h > sh ./mkhex vgabios_cirrusvga \ > ../vgabios/VGABIOS-lgpl-latest.cirrus.bin>> roms.h > diff -r 494be76c1ad9 tools/firmware/hvmloader/hvmloader.c > --- a/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 16:54:33 2009 +0800 > +++ b/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 17:23:00 2009 +0800 > @@ -688,9 +688,9 @@ int main(void) > vgabios_sz = round_option_rom(sizeof(vgabios_stdvga)); > break; > case VGA_pt: > - printf("Loading Gfx Video BIOS from 0xC0000 ...\n"); > - vgabios_sz > - round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512); > + printf("Loading Gfx Video BIOS from file ...\n"); > + memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt, > sizeof(vgabios_pt)); > + vgabios_sz = round_option_rom(sizeof(vgabios_pt)); > break; > default: > printf("No emulated VGA adaptor ...\n"); > > </CODE> > > as intel-gfx-passthru-patch-3.patch and then I tried to apply the patch to xen 3.5-unstable. I got errors. I think it''s because the 3rd patch you provided is incomplete. > > Here''s my patching process: > > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name vgabios > ./tools/firmware/vgabios > ./.hg/store/data/tools/firmware/vgabios > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cp ~enming/vgabios-pt.bin tools/firmware/vgabios/ > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ls tools/firmware/vgabios/ > biossums.c clext.c Makefile TODO vbe.h vgabios.h vgatables.h > BUGS COPYING Notes vbe.c vbetables-gen.c vgabios-pt.bin > ChangeLog dataseghack README vbe_display_api.txt vgabios.c vgafonts.h > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# pwd > /usr/src/xen-unstable.hg-vgapt > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wgethttp://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin > --2009-08-28 23:18:21--http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin > Resolving lists.xensource.com... 70.42.241.110 > Connecting to lists.xensource.com|70.42.241.110|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 12565 (12K) [application/octet-stream] > Saving to: `bincPiiAf0QWg.bin'' > > 100%[======================================================================>] 12,565 30.7K/s in 0.4s > > 2009-08-28 23:18:22 (30.7 KB/s) - `bincPiiAf0QWg.bin'' saved [12565/12565] > > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv bincPiiAf0QWg.bin xen-gfx-passthrough.patch > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi xen-gfx-passthrough.patch > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch< xen-gfx-passthrough.patch > can''t find file to patch at input line 4 > Perhaps you should have used the -p or --strip option? > The text leading up to this was: > -------------------------- > |diff -r 5d7e7a250267 tools/firmware/hvmloader/config.h > |--- a/tools/firmware/hvmloader/config.h Wed Aug 26 18:28:44 2009 +0800 > |+++ b/tools/firmware/hvmloader/config.h Thu Aug 27 16:54:24 2009 +0800 > -------------------------- > File to patch: ^C > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ex xen-gfx-passthrough.patch > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1< xen-gfx-passthrough.patch > patching file tools/firmware/hvmloader/config.h > patching file tools/firmware/hvmloader/hvmloader.c > patching file tools/libxc/ia64/xc_ia64_hvm_build.c > patching file tools/libxc/xc_hvm_build.c > patching file tools/libxc/xc_linux.c > patching file tools/libxc/xenctrl.h > patching file tools/libxc/xenguest.h > patching file tools/python/xen/lowlevel/xc/xc.c > patching file tools/python/xen/xend/XendConfig.py > Hunk #1 succeeded at 174 (offset -1 lines). > patching file tools/python/xen/xend/image.py > Hunk #1 succeeded at 780 (offset -6 lines). > Hunk #3 succeeded at 895 (offset -6 lines). > patching file tools/python/xen/xm/create.py > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wgethttp://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin > --2009-08-28 23:21:35--http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin > Resolving lists.xensource.com... 70.42.241.110 > Connecting to lists.xensource.com|70.42.241.110|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: 9841 (9.6K) [application/octet-stream] > Saving to: `binglLqkeq4Rj.bin'' > > 100%[======================================================================>] 9,841 24.3K/s in 0.4s > > 2009-08-28 23:21:36 (24.3 KB/s) - `binglLqkeq4Rj.bin'' saved [9841/9841] > > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv binglLqkeq4Rj.bin qemu-gfx-passthrough.patch > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi qemu-gfx-passthrough.patch > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name hw > ./tools/ioemu-remote/hw > ./.hg/store/data/tools/ioemu/hw > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv qemu-gfx-passthrough.patch tools/ioemu-remote/ > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cd tools/ioemu-remote/ > [root@fedora11-x86-64-host ioemu-remote]# patch -p1< qemu- > qemu-aio.h qemu-img.c qemu-sockets.c > qemu-binfmt-conf.sh qemu-img.texi qemu-tech.texi > qemu-char.c qemu-lock.h qemu-timer.h > qemu-char.h qemu-log.h qemu-tool.c > qemu-common.h qemu-malloc.c qemu-xen.h > qemu-doc.texi qemu-nbd.c > qemu-gfx-passthrough.patch qemu-nbd.texi > [root@fedora11-x86-64-host ioemu-remote]# patch -p1< qemu-gfx-passthrough.patch > patching file hw/pass-through.c > patching file hw/pass-through.h > patching file hw/pc.c > patching file vl.c > [root@fedora11-x86-64-host ioemu-remote]# cd .. > [root@fedora11-x86-64-host tools]# cd .. > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi intel-gfx-passthru-patch-3.patch > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1< intel-gfx-passthru-patch-3.patch > patching file tools/firmware/hvmloader/Makefile > Hunk #1 FAILED at 50. > 1 out of 1 hunk FAILED -- saving rejects to file tools/firmware/hvmloader/Makefile.rej > patching file tools/firmware/hvmloader/hvmloader.c > patch: **** malformed patch at line 24: sizeof(vgabios_pt)); > > [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi intel-gfx-passthru-patch-3.patch > > For everybody''s convenience, I have attached intel-gfx-passthru-patch-3.patch and the firmware for my nVidia GeForce 8400 GS PCI Express x16 graphics card in this email. > > Please help me complete intel-gfx-passthru-patch-3.patch as I really need it. > > Thank you very much!!! > > -- > Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) > Technical Support Engineer > Information Technology Department > Asiasoft Online Pte Ltd > Tampines Central 1 #04-01 Tampines Plaza > Singapore 529541 > Republic of Singapore > Mobile: +65-9648-9798 > MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> > Alma Maters: Singapore Polytechnic, National University of Singapore > > This patch supports basic gfx passthrough on QEMU: > > - disable emulated VGA adpater if there is passthroughed gfx > > - register/unregister legacy VGA I/O ports and MMIOs for passthroughed gfx > > > > Signed-off-by: Ben Lin<ben.y.lin@intel.com> <mailto:ben.y.lin@intel.com> > > Signed-off-by: Weidong Han<weidong.han@intel.com> <mailto:weidong.han@intel.com> > > No virus found in this incoming message. > > Checked by AVG -www.avg.com <http://www.avg.com> > > Version: 8.5.409 / Virus Database: 270.13.69/2328 - Release Date: 08/27/09 > > 18:02:00 > > > > No virus found in this outgoing message. > > Checked by AVG -www.avg.com <http://www.avg.com> > > Version: 8.5.409 / Virus Database: 270.13.71/2330 - Release Date: 08/27/09 > > 18:02:00 > > > > ------------------------------------------------------------------------ > > > > > > > > > > > > > _______________________________________________ > > Xen-devel mailing list > > Xen-devel@lists.xensource.com <mailto:Xen-devel@lists.xensource.com> > > http://lists.xensource.com/xen-devel > > > > > > > ------------------------------------------------------------------------ > > > > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com <mailto:Xen-devel@lists.xensource.com> > http://lists.xensource.com/xen-devel > > > > > > > > > > > ------------------------------------------------------------------------ > > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xensource.com <mailto: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
Mr. Teo En Ming (Zhang Enming)
2009-Aug-29 14:39 UTC
Re: [Xen-devel] graphics passthrough with VT-d
Dear All, Here is my "xm dmesg" output: linux" (XEN) elf_xen_parse_note: GUEST_VERSION = "2.6" (XEN) elf_xen_parse_note: XEN_VERSION = "xen-3.0" (XEN) elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000 (XEN) elf_xen_parse_note: ENTRY = 0xffffffff8166b200 (XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81009000 (XEN) elf_xen_parse_note: FEATURES = "!writable_page_tables|pae_pgdir_above_4gb" (XEN) elf_xen_parse_note: PAE_MODE = "yes" (XEN) elf_xen_parse_note: LOADER = "generic" (XEN) elf_xen_parse_note: unknown xen elf note (0xd) (XEN) elf_xen_parse_note: SUSPEND_CANCEL = 0x1 (XEN) elf_xen_parse_note: HV_START_LOW = 0xffff800000000000 (XEN) elf_xen_parse_note: PADDR_OFFSET = 0x0 (XEN) elf_xen_addr_calc_check: addresses: (XEN) virt_base = 0xffffffff80000000 (XEN) elf_paddr_offset = 0x0 (XEN) virt_offset = 0xffffffff80000000 (XEN) virt_kstart = 0xffffffff81000000 (XEN) virt_kend = 0xffffffff81911000 (XEN) virt_entry = 0xffffffff8166b200 (XEN) p2m_base = 0xffffffffffffffff (XEN) Xen kernel: 64-bit, lsb, compat32 (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1911000 (XEN) PHYSICAL MEMORY ARRANGEMENT: (XEN) Dom0 alloc.: 00000001f0000000->00000001f4000000 (1470696 pages to be allocated) (XEN) VIRTUAL MEMORY ARRANGEMENT: (XEN) Loaded kernel: ffffffff81000000->ffffffff81911000 (XEN) Init. ramdisk: ffffffff81911000->ffffffff82085400 (XEN) Phys-Mach map: ffffffff82086000->ffffffff82bde740 (XEN) Start info: ffffffff82bdf000->ffffffff82bdf4b4 (XEN) Page tables: ffffffff82be0000->ffffffff82bfb000 (XEN) Boot stack: ffffffff82bfb000->ffffffff82bfc000 (XEN) TOTAL: ffffffff80000000->ffffffff83000000 (XEN) ENTRY ADDRESS: ffffffff8166b200 (XEN) Dom0 has maximum 2 VCPUs (XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff815bb000 (XEN) elf_load_binary: phdr 1 at 0xffffffff815bb000 -> 0xffffffff8165efe0 (XEN) elf_load_binary: phdr 2 at 0xffffffff8165f000 -> 0xffffffff8165f888 (XEN) elf_load_binary: phdr 3 at 0xffffffff81660000 -> 0xffffffff8179c200 (XEN) elf_load_binary: phdr 4 at 0xffffffff8179d000 -> 0xffffffff817b2c60 (XEN) elf_load_binary: phdr 5 at 0xffffffff817b3000 -> 0xffffffff817b4000 (XEN) Scrubbing Free RAM: .done. (XEN) Xen trace buffers: disabled (XEN) Std. Loglevel: All (XEN) Guest Loglevel: All (XEN) *** Serial input -> DOM0 (type \047CTRL-a\047 three times to switch input to Xen) (XEN) Freed 128kB init memory. (XEN) io_apic.c:2275: (XEN) ioapic_guest_write: apic=0, pin=0, old_irq=-1, new_irq=0 (XEN) ioapic_guest_write: old_entry=00010000, new_entry=00010900 (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! (XEN) io_apic.c:2275: (XEN) ioapic_guest_write: apic=0, pin=1, old_irq=1, new_irq=0 (XEN) ioapic_guest_write: old_entry=00000928, new_entry=00010900 (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! (XEN) io_apic.c:2275: (XEN) ioapic_guest_write: apic=0, pin=2, old_irq=0, new_irq=0 (XEN) ioapic_guest_write: old_entry=000009f0, new_entry=00010900 (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! (XEN) io_apic.c:2275: (XEN) ioapic_guest_write: apic=0, pin=3, old_irq=3, new_irq=0 (XEN) ioapic_guest_write: old_entry=00000930, new_entry=00010900 (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! (XEN) io_apic.c:2262: (XEN) ioapic_guest_write: apic=0, pin=4, old_irq=4, new_irq=0 (XEN) ioapic_guest_write: old_entry=000009f1, new_entry=00010900 (XEN) ioapic_guest_write: Attempt to remove IO-APIC pin of in-use IRQ! (XEN) io_apic.c:2275: (XEN) ioapic_guest_write: apic=0, pin=5, old_irq=5, new_irq=0 (XEN) ioapic_guest_write: old_entry=00000938, new_entry=00010900 (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! (XEN) io_apic.c:2275: (XEN) ioapic_guest_write: apic=0, pin=6, old_irq=6, new_irq=0 (XEN) ioapic_guest_write: old_entry=00000940, new_entry=00010900 (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! (XEN) io_apic.c:2275: (XEN) ioapic_guest_write: apic=0, pin=7, old_irq=7, new_irq=0 (XEN) ioapic_guest_write: old_entry=00000948, new_entry=00010900 (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! (XEN) io_apic.c:2275: (XEN) ioapic_guest_write: apic=0, pin=8, old_irq=8, new_irq=0 (XEN) ioapic_guest_write: old_entry=00000950, new_entry=00010900 (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! (XEN) io_apic.c:2275: (XEN) ioapic_guest_write: apic=0, pin=9, old_irq=9, new_irq=0 (XEN) ioapic_guest_write: old_entry=00018958, new_entry=00010900 (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! (XEN) io_apic.c:2275: (XEN) ioapic_guest_write: apic=0, pin=10, old_irq=10, new_irq=0 (XEN) ioapic_guest_write: old_entry=00000960, new_entry=00010900 (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! (XEN) io_apic.c:2275: (XEN) ioapic_guest_write: apic=0, pin=11, old_irq=11, new_irq=0 (XEN) ioapic_guest_write: old_entry=00000968, new_entry=00010900 (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! (XEN) io_apic.c:2275: (XEN) ioapic_guest_write: apic=0, pin=12, old_irq=12, new_irq=0 (XEN) ioapic_guest_write: old_entry=00000970, new_entry=00010900 (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! (XEN) io_apic.c:2275: (XEN) ioapic_guest_write: apic=0, pin=13, old_irq=13, new_irq=0 (XEN) ioapic_guest_write: old_entry=00000978, new_entry=00010900 (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! (XEN) io_apic.c:2275: (XEN) ioapic_guest_write: apic=0, pin=14, old_irq=14, new_irq=0 (XEN) ioapic_guest_write: old_entry=00000988, new_entry=00010900 (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! (XEN) io_apic.c:2275: (XEN) ioapic_guest_write: apic=0, pin=15, old_irq=15, new_irq=0 (XEN) ioapic_guest_write: old_entry=00000990, new_entry=00010900 (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! (XEN) io_apic.c:2275: (XEN) ioapic_guest_write: apic=0, pin=16, old_irq=-1, new_irq=0 (XEN) ioapic_guest_write: old_entry=00010000, new_entry=00010900 (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! (XEN) io_apic.c:2275: (XEN) ioapic_guest_write: apic=0, pin=17, old_irq=-1, new_irq=0 (XEN) ioapic_guest_write: old_entry=00010000, new_entry=00010900 (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! (XEN) io_apic.c:2275: (XEN) ioapic_guest_write: apic=0, pin=18, old_irq=-1, new_irq=0 (XEN) ioapic_guest_write: old_entry=00010000, new_entry=00010900 (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! (XEN) io_apic.c:2275: (XEN) ioapic_guest_write: apic=0, pin=19, old_irq=-1, new_irq=0 (XEN) ioapic_guest_write: old_entry=00010000, new_entry=00010900 (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! (XEN) io_apic.c:2275: (XEN) ioapic_guest_write: apic=0, pin=20, old_irq=-1, new_irq=0 (XEN) ioapic_guest_write: old_entry=00010000, new_entry=00010900 (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! (XEN) io_apic.c:2275: (XEN) ioapic_guest_write: apic=0, pin=21, old_irq=-1, new_irq=0 (XEN) ioapic_guest_write: old_entry=00010000, new_entry=00010900 (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! (XEN) io_apic.c:2275: (XEN) ioapic_guest_write: apic=0, pin=22, old_irq=-1, new_irq=0 (XEN) ioapic_guest_write: old_entry=00010000, new_entry=00010900 (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! (XEN) io_apic.c:2275: (XEN) ioapic_guest_write: apic=0, pin=23, old_irq=-1, new_irq=0 (XEN) ioapic_guest_write: old_entry=00010000, new_entry=00010900 (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! (XEN) io_apic.c:2275: (XEN) ioapic_guest_write: apic=0, pin=0, old_irq=-1, new_irq=0 (XEN) ioapic_guest_write: old_entry=00010000, new_entry=00000900 (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! (XEN) io_apic.c:2275: (XEN) ioapic_guest_write: apic=0, pin=4, old_irq=4, new_irq=4 (XEN) ioapic_guest_write: old_entry=000009f1, new_entry=00000904 (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! (XEN) mce.c:694:d0 MCE: rdmsr MCG_CAP 0x806 (XEN) mce.c:694:d0 MCE: rdmsr MCG_CAP 0x806 (XEN) mce.c:694:d0 MCE: rdmsr MCG_CAP 0x806 (XEN) mce.c:871:d0 MCE: wr MC1_STATUS 0 (XEN) mce.c:871:d0 MCE: wr MC2_STATUS 0 (XEN) mce.c:871:d0 MCE: wr MC3_STATUS 0 (XEN) mce.c:871:d0 MCE: wr MC4_STATUS 0 (XEN) mce.c:871:d0 MCE: wr MC5_STATUS 0 (XEN) mce.c:694:d0 MCE: rdmsr MCG_CAP 0x806 (XEN) mce.c:694:d0 MCE: rdmsr MCG_CAP 0x806 (XEN) mce.c:694:d0 MCE: rdmsr MCG_CAP 0x806 (XEN) mce.c:871:d0 MCE: wr MC1_STATUS 0 (XEN) mce.c:871:d0 MCE: wr MC2_STATUS 0 (XEN) mce.c:871:d0 MCE: wr MC3_STATUS 0 (XEN) mce.c:871:d0 MCE: wr MC4_STATUS 0 (XEN) mce.c:871:d0 MCE: wr MC5_STATUS 0 (XEN) io_apic.c:2275: (XEN) ioapic_guest_write: apic=0, pin=4, old_irq=4, new_irq=4 (XEN) ioapic_guest_write: old_entry=000009f1, new_entry=00000904 (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! (XEN) io_apic.c:2275: (XEN) ioapic_guest_write: apic=0, pin=19, old_irq=19, new_irq=19 (XEN) ioapic_guest_write: old_entry=0000a9c8, new_entry=0001a913 (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! (XEN) io_apic.c:2275: (XEN) ioapic_guest_write: apic=0, pin=18, old_irq=18, new_irq=18 (XEN) ioapic_guest_write: old_entry=0000a9d0, new_entry=0001a912 (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! (XEN) io_apic.c:2275: (XEN) ioapic_guest_write: apic=0, pin=23, old_irq=23, new_irq=23 (XEN) ioapic_guest_write: old_entry=0000a9d8, new_entry=0001a917 (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! (XEN) io_apic.c:2275: (XEN) ioapic_guest_write: apic=0, pin=19, old_irq=19, new_irq=19 (XEN) ioapic_guest_write: old_entry=0000a9c8, new_entry=0001a913 (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! (XEN) io_apic.c:2275: (XEN) ioapic_guest_write: apic=0, pin=18, old_irq=18, new_irq=18 (XEN) ioapic_guest_write: old_entry=0000a9d0, new_entry=0001a912 (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! (XEN) io_apic.c:2275: (XEN) ioapic_guest_write: apic=0, pin=18, old_irq=18, new_irq=18 (XEN) ioapic_guest_write: old_entry=0000a9d0, new_entry=0001a912 (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! (XEN) io_apic.c:2275: (XEN) ioapic_guest_write: apic=0, pin=18, old_irq=18, new_irq=18 (XEN) ioapic_guest_write: old_entry=0000a9d0, new_entry=0001a912 (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! (XEN) io_apic.c:2275: (XEN) ioapic_guest_write: apic=0, pin=16, old_irq=16, new_irq=16 (XEN) ioapic_guest_write: old_entry=0000a9b8, new_entry=0001a910 (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! (XEN) io_apic.c:2275: (XEN) ioapic_guest_write: apic=0, pin=22, old_irq=22, new_irq=22 (XEN) ioapic_guest_write: old_entry=0000a931, new_entry=0001a916 (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! (XEN) [VT-D]iommu.c:1288:d0 domain_context_unmap:PCIe: bdf = 1:0.0 (XEN) [VT-D]iommu.c:1174:d0 domain_context_mapping:PCIe: bdf = 1:0.0 (XEN) domctl.c:887:d0 ioport_map:add f_gport=3b0 f_mport=3b0 np=c (XEN) domctl.c:887:d0 ioport_map:add f_gport=3c0 f_mport=3c0 np=20 (XEN) domctl.c:836:d0 memory_map:add: gfn=a0 mfn=a0 nr_mfns=20 (XEN) [VT-D]io.c:284:d0 VT-d irq bind: m_irq = 1f device = 4 intx = 0 (XEN) HVM1: HVM Loader (XEN) HVM1: Detected Xen v3.5-unstable (XEN) HVM1: CPU speed is 2800 MHz (XEN) irq.c:243: Dom1 PCI link 0 changed 0 -> 5 (XEN) HVM1: PCI-ISA link 0 routed to IRQ5 (XEN) irq.c:243: Dom1 PCI link 1 changed 0 -> 10 (XEN) HVM1: PCI-ISA link 1 routed to IRQ10 (XEN) irq.c:243: Dom1 PCI link 2 changed 0 -> 11 (XEN) HVM1: PCI-ISA link 2 routed to IRQ11 (XEN) irq.c:243: Dom1 PCI link 3 changed 0 -> 5 (XEN) HVM1: PCI-ISA link 3 routed to IRQ5 (XEN) HVM1: pci dev 01:2 INTD->IRQ5 (XEN) HVM1: pci dev 01:3 INTA->IRQ10 (XEN) HVM1: pci dev 02:0 INTA->IRQ11 (XEN) HVM1: pci dev 03:0 INTA->IRQ5 (XEN) HVM1: pci dev 04:0 INTA->IRQ5 (XEN) HVM1: pci dev 04:0 bar 14 size 10000000: e000000c (XEN) domctl.c:836:d0 memory_map:add: gfn=e0000 mfn=c0000 nr_mfns=10000 (XEN) domctl.c:836:d0 memory_map:add: gfn=f0000 mfn=d0000 nr_mfns=2000 (XEN) HVM1: pci dev 04:0 bar 1c size 02000000: f0000004 (XEN) HVM1: pci dev 02:0 bar 14 size 01000000: f2000008 (XEN) domctl.c:836:d0 memory_map:add: gfn=f3000 mfn=d2000 nr_mfns=1000 (XEN) HVM1: pci dev 04:0 bar 10 size 01000000: f3000000 (XEN) HVM1: pci dev 04:0 bar 30 size 00020000: f4000000 (XEN) HVM1: pci dev 02:0 bar 10 size 00000100: 0000c001 (XEN) HVM1: pci dev 03:0 bar 10 size 00000100: 0000c101 (XEN) HVM1: pci dev 03:0 bar 14 size 00000100: f4020000 (XEN) HVM1: pci dev 04:0 bar 24 size 00000080: 0000c201 (XEN) domctl.c:887:d0 ioport_map:add f_gport=c200 f_mport=d000 np=80 (XEN) HVM1: pci dev 01:2 bar 20 size 00000020: 0000c281 (XEN) HVM1: pci dev 01:1 bar 20 size 00000010: 0000c2a1 (XEN) HVM1: Multiprocessor initialisation: (XEN) HVM1: - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. (XEN) HVM1: Testing HVM environment: (XEN) HVM1: - REP INSB across page boundaries ... passed (XEN) HVM1: - GS base MSRs and SWAPGS ... passed (XEN) HVM1: Passed 2 of 2 tests (XEN) HVM1: Writing SMBIOS tables ... (XEN) HVM1: Loading ROMBIOS ... (XEN) HVM1: 11900 bytes of ROMBIOS high-memory extensions: (XEN) HVM1: Relocating to 0xfc000000-0xfc002e7c ... done (XEN) HVM1: Creating MP tables ... (XEN) HVM1: Loading Gfx Video BIOS from file ... (XEN) HVM1: Loading PCI Option ROM ... (XEN) HVM1: - Manufacturer: http://etherboot.org (XEN) HVM1: - Product name: gPXE (XEN) HVM1: Loading ACPI ... (XEN) HVM1: - Lo data: 000ea020-000ea04f (XEN) HVM1: - Hi data: fc003000-fc0125cf (XEN) HVM1: vm86 TSS at fc012800 (XEN) HVM1: BIOS map: (XEN) HVM1: c8000-d47ff: Etherboot ROM (XEN) HVM1: eb000-eb14e: SMBIOS tables (XEN) HVM1: f0000-fffff: Main BIOS (XEN) HVM1: Invoking ROMBIOS ... (XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $ (XEN) HVM1: Bochs BIOS - build: 06/23/99 (XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $ (XEN) HVM1: Options: apmbios pcibios eltorito PMM (XEN) HVM1: (XEN) HVM1: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 (XEN) HVM1: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (51200 MBytes) (XEN) HVM1: IDE time out (XEN) HVM1: ata1 master: QEMU DVD-ROM ATAPI-4 CD-Rom/DVD-Rom (XEN) HVM1: IDE time out (XEN) HVM1: (XEN) HVM1: (XEN) HVM1: (XEN) HVM1: Press F12 for boot menu. (XEN) HVM1: (XEN) HVM1: Booting from Hard Disk... (XEN) HVM1: Booting from 0000:7c00 (XEN) HVM1: int13_harddisk: function 15, unmapped device for ELDL=81 (XEN) HVM1: *** int 15h function AX=e980, BX=006e not yet supported! (XEN) mce.c:694:d1 MCE: rdmsr MCG_CAP 0x806 (XEN) mce.c:714:d1 MCE: rdmsr MC0_CTL 0xffffffffffffffff (XEN) mce.c:694:d1 MCE: rdmsr MCG_CAP 0x806 (XEN) irq.c:243: Dom1 PCI link 0 changed 5 -> 0 (XEN) irq.c:243: Dom1 PCI link 1 changed 10 -> 0 (XEN) irq.c:243: Dom1 PCI link 2 changed 11 -> 0 (XEN) irq.c:243: Dom1 PCI link 3 changed 5 -> 0 (XEN) domctl.c:846:d0 memory_map:remove: gfn=f3000 mfn=d2000 nr_mfns=1000 (XEN) domctl.c:846:d0 memory_map:remove: gfn=e0000 mfn=c0000 nr_mfns=10000 (XEN) domctl.c:846:d0 memory_map:remove: gfn=f0000 mfn=d0000 nr_mfns=2000 (XEN) domctl.c:911:d0 ioport_map:remove f_gport=c200 f_mport=d000 np=80 (XEN) domctl.c:836:d0 memory_map:add: gfn=f3000 mfn=d2000 nr_mfns=1000 (XEN) domctl.c:836:d0 memory_map:add: gfn=e0000 mfn=c0000 nr_mfns=10000 (XEN) domctl.c:836:d0 memory_map:add: gfn=f0000 mfn=d0000 nr_mfns=2000 (XEN) domctl.c:887:d0 ioport_map:add f_gport=c200 f_mport=d000 np=80 (XEN) domctl.c:846:d0 memory_map:remove: gfn=f3000 mfn=d2000 nr_mfns=1000 (XEN) domctl.c:846:d0 memory_map:remove: gfn=e0000 mfn=c0000 nr_mfns=10000 (XEN) domctl.c:846:d0 memory_map:remove: gfn=f0000 mfn=d0000 nr_mfns=2000 (XEN) domctl.c:911:d0 ioport_map:remove f_gport=c200 f_mport=d000 np=80 (XEN) domctl.c:836:d0 memory_map:add: gfn=f3000 mfn=d2000 nr_mfns=1000 (XEN) domctl.c:836:d0 memory_map:add: gfn=e0000 mfn=c0000 nr_mfns=10000 (XEN) domctl.c:836:d0 memory_map:add: gfn=f0000 mfn=d0000 nr_mfns=2000 (XEN) domctl.c:887:d0 ioport_map:add f_gport=c200 f_mport=d000 np=80 (XEN) mce.c:694:d0 MCE: rdmsr MCG_CAP 0x806 (XEN) mce.c:694:d0 MCE: rdmsr MCG_CAP 0x806 -- Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) Technical Support Engineer Information Technology Department Asiasoft Online Pte Ltd Tampines Central 1 #04-01 Tampines Plaza Singapore 529541 Republic of Singapore Company Website: http://www.asiasoft.sg/ Mobile: +65-9648-9798 MSN: teoenming@hotmail.com Alma Maters: Singapore Polytechnic, National University of Singapore On 08/29/2009 09:46 PM, Mr. Teo En Ming (Zhang Enming) wrote:> Dear All, > > I have attached the patchset to xen-unstable and also the nvidia > geforce 8400 gs firmware file here for your convenience. > > You can refer to the screenshots at my blog here: > http://teo-en-ming-aka-zhang-enming.blogspot.com/2009/08/windows-xp-home-domu-test-results-after.html > > It shows that the emulated virtual VGA card is now disabled (not > appearing in Windows XP Home DomU''s device manager) and only the > nVidia Geforce 8400 GS VGA BIOS gets loaded. > > -- > Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) > Technical Support Engineer > Information Technology Department > Asiasoft Online Pte Ltd > Tampines Central 1 #04-01 Tampines Plaza > Singapore 529541 > Republic of Singapore > Company Website:http://www.asiasoft.sg/ > Mobile: +65-9648-9798 > MSN:teoenming@hotmail.com > Alma Maters: Singapore Polytechnic, National University of Singapore > > > On 08/29/2009 09:20 PM, Mr. Teo En Ming (Zhang Enming) wrote: >> Dear All, >> >> I have applied the following patches to xen 3.5-unstable >> >> 1) intel-gfx-passthru-patch01.patch >> 2) intel-gfx-passthru-patch02.patch >> 3) intel-gfx-passthru-patch03.patch >> 4) enming-patch04.patch >> >> and compiled xen 3.5-unstable successfully (both hypervisor and tools). >> >> i rebooted into this newly compiled Xen hypervisor which supports >> loading vga bios from firmware file of nVidia Geforce 8400 GS PCI >> Express x16. >> >> After dom0 has booted up, I executed the following script to hide >> nVidia Geforce 8400 GS from dom0. >> >> [enming@fedora11-x86-64-host scripts]$ cat bind-devices-pci-stub.sh >> #!/bin/sh >> echo "10de 06e4" > /sys/bus/pci/drivers/pci-stub/new_id >> echo "0000:01:00.0" > /sys/bus/pci/devices/0000:01:00.0/driver/unbind >> echo "0000:01:00.0" > /sys/bus/pci/drivers/pci-stub/bind >> >> I also assigned the nVidia Geforce 8400 GS to my Windows XP Home HVM >> domU. >> >> pci = [ ''01:00.0'' ] >> >> I also specified gfx_passthru=2. >> >> Do note that I booted up with onboard Intel GMA4500 as the primary >> video adapter. Hence dom 0 has onboard graphics and Windows XP HVM >> domU has nvidia graphics. >> >> Then I started Windows XP Home HVM DomU. >> >> Very soon, my Dom 0''s display was garbaged and X server on Dom 0 >> totally froze and became unresponsive. I cannot switch to any ttys. >> >> However, I was still able to vnc into my Windows XP Home HVM Dom U. I >> had earlier installed a VNC server into my Windows XP guest. After >> remoting in to my Windows XP DomU through vnc, I found that NVIDIA >> Geforce 8400 GS cannot be initialized and no resources are available >> for this graphics card. >> >> -- >> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >> Technical Support Engineer >> Information Technology Department >> Asiasoft Online Pte Ltd >> Tampines Central 1 #04-01 Tampines Plaza >> Singapore 529541 >> Republic of Singapore >> Company Website:http://www.asiasoft.sg/ >> Mobile: +65-9648-9798 >> MSN:teoenming@hotmail.com >> Alma Maters: Singapore Polytechnic, National University of Singapore >> >> >> On 08/29/2009 08:25 PM, Mr. Teo En Ming (Zhang Enming) wrote: >>> Hi All, >>> >>> I have solved the problem encountered below when building tools for >>> xen 3.5-unstable. The compile problem exists because I downloaded >>> and compiled the latest version of Intel ACPI Component Architecture >>> compiler version 20090730. And I used this latest compiler during >>> "make tools" for xen-unstable. >>> >>> In original xen-unstable source codes cloned from xensoure mercurial >>> repository, the header files ssdt_pm.h and ssdt_tpm.h in source >>> directory tools/firmware/hvmloader/acpi/ are generated by >>> >>> /* >>> * >>> * Intel ACPI Component Architecture >>> * ASL Optimizing Compiler version 20061109 [May 18 2007] >>> * Copyright (C) 2000 - 2006 Intel Corporation >>> * Supports ACPI Specification Revision 3.0a >>> * >>> * Compilation of "ssdt_pm.asl" - Sun Oct 12 23:57:51 2008 >>> * >>> * C source code output >>> * >>> */ >>> >>> In original ssdt_pm.h, it has "unsigned char AmlCode_PM[] =". >>> >>> In original ssdt_tpm.h, it has "unsigned char AmlCode_TPM[] =". >>> >>> Hence there was no problem with "make tools". >>> >>> But, I downloaded, compiled and used >>> >>> /* >>> * >>> * Intel ACPI Component Architecture >>> * ASL Optimizing Compiler version 20090730 [Aug 29 2009] >>> * Copyright (C) 2000 - 2009 Intel Corporation >>> * Supports ACPI Specification Revision 4.0 >>> * >>> * Compilation of "ssdt_pm.asl" - Sat Aug 29 18:55:40 2009 >>> * >>> * C source code output >>> * >>> */ >>> >>> So the *new* ssdt_pm.h contains: >>> >>> /* >>> * >>> * Intel ACPI Component Architecture >>> * ASL Optimizing Compiler version 20090730 [Aug 29 2009] >>> * Copyright (C) 2000 - 2009 Intel Corporation >>> * Supports ACPI Specification Revision 4.0 >>> * >>> * Compilation of "ssdt_pm.asl" - Sat Aug 29 18:55:40 2009 >>> * >>> * C source code output >>> * >>> */ >>> unsigned char AmlCode[] >>> { >>> 0x53,0x53,0x44,0x54,0xD6,0x05,0x00,0x00, /* 00000000 >>> "SSDT...." */ >>> 0x02,0xB9,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008 >>> "..Xen..." */ >>> 0x48,0x56,0x4D,0x00,0x00,0x00,0x00,0x00, /* 00000010 >>> "HVM....." */ >>> 0x00,0x00,0x00,0x00,0x49,0x4E,0x54,0x4C, /* 00000018 >>> "....INTL" */ >>> 0x30,0x07,0x09,0x20,0x10,0x41,0x5B,0x5C, /* 00000020 "0.. >>> .A[\" */ >>> 0x5F,0x53,0x42,0x5F,0x5B,0x80,0x44,0x42, /* 00000028 >>> "_SB_[.DB" */ >>> 0x47,0x41,0x01,0x0B,0x40,0xB0,0x01,0x5B, /* 00000030 "GA..@..[" */ >>> 0x81,0x0B,0x44,0x42,0x47,0x41,0x01,0x44, /* 00000038 >>> "..DBGA.D" */ >>> 0x42,0x47,0x31,0x08,0x5B,0x80,0x44,0x42, /* 00000040 >>> "BG1.[.DB" */ >>> 0x47,0x42,0x01,0x0B,0x44,0xB0,0x01,0x5B, /* 00000048 >>> "GB..D..[" */ >>> 0x81,0x0B,0x44,0x42,0x47,0x42,0x01,0x44, /* 00000050 >>> "..DBGB.D" */ >>> 0x42,0x47,0x32,0x08,0x5B,0x80,0x44,0x42, /* 00000058 >>> "BG2.[.DB" */ >>> 0x47,0x43,0x01,0x0B,0x46,0xB0,0x01,0x5B, /* 00000060 >>> "GC..F..[" */ >>> 0x81,0x0B,0x44,0x42,0x47,0x43,0x01,0x44, /* 00000068 >>> "..DBGC.D" */ >>> 0x42,0x47,0x33,0x08,0x5B,0x80,0x44,0x42, /* 00000070 >>> "BG3.[.DB" */ >>> 0x47,0x44,0x01,0x0B,0x48,0xB0,0x01,0x5B, /* 00000078 >>> "GD..H..[" */ >>> 0x81,0x0B,0x44,0x42,0x47,0x44,0x01,0x44, /* 00000080 >>> "..DBGD.D" */ >>> 0x42,0x47,0x34,0x08,0x5B,0x80,0x50,0x52, /* 00000088 >>> "BG4.[.PR" */ >>> 0x54,0x31,0x01,0x0A,0xB2,0x0A,0x02,0x5B, /* 00000090 >>> "T1.....[" */ >>> 0x81,0x10,0x50,0x52,0x54,0x31,0x01,0x50, /* 00000098 >>> "..PRT1.P" */ >>> 0x42,0x32,0x5F,0x08,0x50,0x42,0x32,0x41, /* 000000A0 >>> "B2_.PB2A" */ >>> 0x08,0x5B,0x80,0x50,0x52,0x54,0x32,0x01, /* 000000A8 >>> ".[.PRT2." */ >>> 0x0A,0x86,0x01,0x5B,0x81,0x0B,0x50,0x52, /* 000000B0 >>> "...[..PR" */ >>> 0x54,0x32,0x01,0x50,0x38,0x36,0x5F,0x08, /* 000000B8 >>> "T2.P86_." */ >>> 0x5B,0x80,0x50,0x52,0x54,0x33,0x01,0x0A, /* 000000C0 >>> "[.PRT3.." */ >>> 0x88,0x01,0x5B,0x81,0x0B,0x50,0x52,0x54, /* 000000C8 >>> "..[..PRT" */ >>> 0x33,0x01,0x50,0x38,0x38,0x5F,0x08,0x5B, /* 000000D0 >>> "3.P88_.[" */ >>> 0x01,0x53,0x59,0x4E,0x43,0x01,0x08,0x42, /* 000000D8 >>> ".SYNC..B" */ >>> 0x55,0x46,0x30,0x11,0x04,0x0B,0x00,0x01, /* 000000E0 >>> "UF0....." */ >>> 0x08,0x42,0x55,0x46,0x31,0x11,0x03,0x0A, /* 000000E8 >>> ".BUF1..." */ >>> 0x08,0x8B,0x42,0x55,0x46,0x31,0x00,0x42, /* 000000F0 >>> "..BUF1.B" */ >>> 0x55,0x46,0x41,0x8B,0x42,0x55,0x46,0x31, /* 000000F8 >>> "UFA.BUF1" */ >>> 0x0A,0x04,0x42,0x55,0x46,0x42,0x14,0x14, /* 00000100 >>> "..BUFB.." */ >>> >>> And the *new* ssdt_tpm.h contains: >>> >>> /* >>> * >>> * Intel ACPI Component Architecture >>> * ASL Optimizing Compiler version 20090730 [Aug 29 2009] >>> * Copyright (C) 2000 - 2009 Intel Corporation >>> * Supports ACPI Specification Revision 4.0 >>> * >>> * Compilation of "ssdt_tpm.asl" - Sat Aug 29 18:55:40 2009 >>> * >>> * C source code output >>> * >>> */ >>> unsigned char AmlCode[] >>> { >>> 0x53,0x53,0x44,0x54,0x4C,0x00,0x00,0x00, /* 00000000 >>> "SSDTL..." */ >>> 0x02,0x2A,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008 >>> ".*Xen..." */ >>> 0x48,0x56,0x4D,0x00,0x00,0x00,0x00,0x00, /* 00000010 >>> "HVM....." */ >>> 0x00,0x00,0x00,0x00,0x49,0x4E,0x54,0x4C, /* 00000018 >>> "....INTL" */ >>> 0x30,0x07,0x09,0x20,0x5B,0x82,0x26,0x54, /* 00000020 "0.. >>> [.&T" */ >>> 0x50,0x4D,0x5F,0x08,0x5F,0x48,0x49,0x44, /* 00000028 >>> "PM_._HID" */ >>> 0x0C,0x41,0xD0,0x0C,0x31,0x08,0x5F,0x43, /* 00000030 >>> ".A..1._C" */ >>> 0x52,0x53,0x11,0x11,0x0A,0x0E,0x86,0x09, /* 00000038 >>> "RS......" */ >>> 0x00,0x01,0x00,0x00,0xD4,0xFE,0x00,0x50, /* 00000040 >>> ".......P" */ >>> 0x00,0x00,0x79,0x00, >>> }; >>> >>> which are both wrong. >>> >>> In ssdt_pm.h, I have to change "unsigned char AmlCode[]" to >>> "unsigned char AmlCode_PM[]". >>> >>> In ssdt_tpm.h, I have to change "unsigned char AmlCode[]" to >>> "unsigned char AmlCode_TPM[]". >>> >>> Then "make tools" is able to complete successfully. >>> >>> I have created a patch for anybody who may be using the *latest* >>> version of Intel ACPI CA compiler version 20090730 and attached it here. >>> >>> Patch file filename enming-patch04.patch: >>> >>> <CODE> >>> >>> Patch created by Teo En Ming (Zhang Enming) on 29 August 2009 >>> Saturday at 8:00 P.M. Singapore Time >>> Email #1: enming.teo@asiasoftsea.net >>> Email #2: space.time.universe@gmail.com >>> MSN: teoenming@hotmail.com >>> Mobile Phone: +65-9648-9798 >>> >>> --- ssdt_pm.h 2009-08-29 19:54:52.653088000 +0800 >>> +++ ssdt_pm.h 2009-08-29 19:56:51.813088550 +0800 >>> @@ -10,7 +10,7 @@ >>> * C source code output >>> * >>> */ >>> -unsigned char AmlCode[] >>> +unsigned char AmlCode_PM[] >>> { >>> 0x53,0x53,0x44,0x54,0xD6,0x05,0x00,0x00, /* 00000000 >>> "SSDT...." */ >>> 0x02,0xB9,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008 >>> "..Xen..." */ >>> --- ssdt_tpm.h 2009-08-29 19:55:44.578738954 +0800 >>> +++ ssdt_tpm.h 2009-08-29 19:57:27.896638884 +0800 >>> @@ -10,7 +10,7 @@ >>> * C source code output >>> * >>> */ >>> -unsigned char AmlCode[] >>> +unsigned char AmlCode_TPM[] >>> { >>> 0x53,0x53,0x44,0x54,0x4C,0x00,0x00,0x00, /* 00000000 >>> "SSDTL..." */ >>> 0x02,0x2A,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008 >>> ".*Xen..." */ >>> >>> </CODE> >>> >>> -- >>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>> Technical Support Engineer >>> Information Technology Department >>> Asiasoft Online Pte Ltd >>> Tampines Central 1 #04-01 Tampines Plaza >>> Singapore 529541 >>> Republic of Singapore >>> Company Website:http://www.asiasoft.sg/ >>> Mobile: +65-9648-9798 >>> MSN:teoenming@hotmail.com >>> Alma Maters: Singapore Polytechnic, National University of Singapore >>> >>> >>> On 08/29/2009 07:03 PM, Mr. Teo En Ming (Zhang Enming) wrote: >>>> Hi, >>>> >>>> I clonedhttp://xenbits.xensource.com/xen-unstable.hg again today. I tried applying the three Intel gfx passthrough patches to xen-unstable. When I "make tools", I get the same error again: >>>> >>>> make[7]: Entering directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader'' >>>> make -C acpi all >>>> get-path: will use #!/usr/bin/python2.6 for python programs >>>> make[8]: Entering directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' >>>> make iasl >>>> get-path: will use #!/usr/bin/python2.6 for python programs >>>> make[9]: Entering directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' >>>> make[9]: `/usr/local/bin/iasl'' is up to date. >>>> make[9]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' >>>> iasl -tc ssdt_tpm.asl >>>> >>>> Intel ACPI Component Architecture >>>> ASL Optimizing Compiler version 20090730 [Aug 29 2009] >>>> Copyright (C) 2000 - 2009 Intel Corporation >>>> Supports ACPI Specification Revision 4.0 >>>> >>>> ASL Input: ssdt_tpm.asl - 31 lines, 1111 bytes, 3 keywords >>>> AML Output: SSDT_TPM.aml - 76 bytes, 3 named objects, 0 executable opcodes >>>> >>>> Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 0 Optimizations >>>> mv ssdt_tpm.hex ssdt_tpm.h >>>> rm -f *.aml >>>> make iasl >>>> get-path: will use #!/usr/bin/python2.6 for python programs >>>> make[9]: Entering directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' >>>> make[9]: `/usr/local/bin/iasl'' is up to date. >>>> make[9]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' >>>> iasl -tc ssdt_pm.asl >>>> >>>> Intel ACPI Component Architecture >>>> ASL Optimizing Compiler version 20090730 [Aug 29 2009] >>>> Copyright (C) 2000 - 2009 Intel Corporation >>>> Supports ACPI Specification Revision 4.0 >>>> >>>> ASL Input: ssdt_pm.asl - 425 lines, 12754 bytes, 192 keywords >>>> AML Output: SSDT_PM.aml - 1494 bytes, 64 named objects, 128 executable opcodes >>>> >>>> Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 31 Optimizations >>>> mv ssdt_pm.hex ssdt_pm.h >>>> rm -f *.aml >>>> gcc -O1 -fno-omit-frame-pointer -fno-optimize-sibling-calls -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .build.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs -Werror -fno-stack-protector -fno-builtin -msoft-float -I. -I.. -I../../../../tools/include -c -o build.o build.c >>>> In file included from build.c:21: >>>> ssdt_pm.h:13: error: redefinition of ''AmlCode'' >>>> ssdt_tpm.h:13: note: previous definition of ''AmlCode'' was here >>>> build.c: In function ''construct_secondary_tables'': >>>> build.c:184: error: ''AmlCode_PM'' undeclared (first use in this function) >>>> build.c:184: error: (Each undeclared identifier is reported only once >>>> build.c:184: error: for each function it appears in.) >>>> build.c:194: error: ''AmlCode_TPM'' undeclared (first use in this function) >>>> make[8]: *** [build.o] Error 1 >>>> make[8]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' >>>> make[7]: *** [subdir-all-acpi] Error 2 >>>> make[7]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader'' >>>> make[6]: *** [subdirs-all] Error 2 >>>> make[6]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader'' >>>> make[5]: *** [subdir-all-hvmloader] Error 2 >>>> make[5]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware'' >>>> make[4]: *** [subdirs-all] Error 2 >>>> make[4]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware'' >>>> make[3]: *** [all] Error 2 >>>> make[3]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware'' >>>> make[2]: *** [subdir-install-firmware] Error 2 >>>> make[2]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools'' >>>> make[1]: *** [subdirs-install] Error 2 >>>> make[1]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools'' >>>> make: *** [install-tools] Error 2 >>>> >>>> Any ideas about this Advanced Configuration and Power Interface code? >>>> >>>> -- >>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>>> Technical Support Engineer >>>> Information Technology Department >>>> Asiasoft Online Pte Ltd >>>> Tampines Central 1 #04-01 Tampines Plaza >>>> Singapore 529541 >>>> Republic of Singapore >>>> Company Website:http://www.asiasoft.sg/ >>>> Mobile: +65-9648-9798 >>>> MSN:teoenming@hotmail.com >>>> Alma Maters: Singapore Polytechnic, National University of Singapore >>>> >>>> >>>> On 08/29/2009 02:58 PM, Mr. Teo En Ming (Zhang Enming) wrote: >>>>> Hi >>>>> >>>>> Anybody available today? I know it''s Saturday. :-) >>>>> >>>>> -- >>>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>>>> Technical Support Engineer >>>>> Information Technology Department >>>>> Asiasoft Online Pte Ltd >>>>> Tampines Central 1 #04-01 Tampines Plaza >>>>> Singapore 529541 >>>>> Republic of Singapore >>>>> Company Website:http://www.asiasoft.sg/ >>>>> Mobile: +65-9648-9798 >>>>> MSN:teoenming@hotmail.com >>>>> Alma Maters: Singapore Polytechnic, National University of Singapore >>>>> >>>>> >>>>> On 08/29/2009 11:48 AM, Mr. Teo En Ming (Zhang Enming) wrote: >>>>>> >>>>>> Dear All, >>>>>> >>>>>> After applying Intel VGA passthrough patches 1, 2 and 3, I have no problems with "make xen", and "make install-xen". However, I have errors with "make tools". >>>>>> >>>>>> Here is the error output: >>>>>> >>>>>> msoft-float -I. -I.. -I../../../../tools/include -c -o build.o build.c >>>>>> build.c: In function ''construct_secondary_tables'': >>>>>> build.c:194: error: ''AmlCode_TPM'' undeclared (first use in this function) >>>>>> build.c:194: error: (Each undeclared identifier is reported only once >>>>>> build.c:194: error: for each function it appears in.) >>>>>> make[8]: *** [build.o] Error 1 >>>>>> make[8]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader/acpi'' >>>>>> make[7]: *** [subdir-all-acpi] Error 2 >>>>>> make[7]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader'' >>>>>> make[6]: *** [subdirs-all] Error 2 >>>>>> make[6]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader'' >>>>>> make[5]: *** [subdir-all-hvmloader] Error 2 >>>>>> make[5]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'' >>>>>> make[4]: *** [subdirs-all] Error 2 >>>>>> make[4]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'' >>>>>> make[3]: *** [all] Error 2 >>>>>> make[3]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'' >>>>>> make[2]: *** [subdir-install-firmware] Error 2 >>>>>> make[2]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools'' >>>>>> make[1]: *** [subdirs-install] Error 2 >>>>>> make[1]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools'' >>>>>> make: *** [install-tools] Error 2 >>>>>> >>>>>> There is an undeclared identifier in tools/firmware/hvmloader/acpi/build.c source code. Could you guys help me resolve this issue? >>>>>> >>>>>> I had no problems compiling xen 3.5-unstable before applying the Intel vga passthrough patches and before installing the Intel ACPI Component Architecture compiler. >>>>>> >>>>>> I have also attached Intel graphics passthrough patches 1, 2 and 3 for your convenience here. >>>>>> >>>>>> Thank you very much. >>>>>> >>>>>> Hope I can get this working during the weekends. >>>>>> >>>>>> -- >>>>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>>>>> Technical Support Engineer >>>>>> Information Technology Department >>>>>> Asiasoft Online Pte Ltd >>>>>> Tampines Central 1 #04-01 Tampines Plaza >>>>>> Singapore 529541 >>>>>> Republic of Singapore >>>>>> Company Website:http://www.asiasoft.sg/ >>>>>> Mobile: +65-9648-9798 >>>>>> MSN:teoenming@hotmail.com >>>>>> Alma Maters: Singapore Polytechnic, National University of Singapore >>>>>> >>>>>> >>>>>> On 08/29/2009 10:17 AM, Mr. Teo En Ming (Zhang Enming) wrote: >>>>>>> Hi Tim, >>>>>>> >>>>>>> I thought it should be gfx_passthru=2 in domU config? >>>>>>> -- >>>>>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>>>>>> Technical Support Engineer >>>>>>> Information Technology Department >>>>>>> Asiasoft Online Pte Ltd >>>>>>> Tampines Central 1 #04-01 Tampines Plaza >>>>>>> Singapore 529541 >>>>>>> Republic of Singapore >>>>>>> Mobile: +65-9648-9798 >>>>>>> MSN:teoenming@hotmail.com >>>>>>> Alma Maters: Singapore Polytechnic, National University of Singapore >>>>>>> >>>>>>> >>>>>>> On 08/29/2009 06:42 AM, Tim Moore wrote: >>>>>>>> >>>>>>>> Teo, >>>>>>>> >>>>>>>> I have also performed the same exercise as yourself and I now >>>>>>>> have successfully compiled all 3x patches into Xen, Qemu and >>>>>>>> the BIOS File Loading in the hvmloader, this all compiles find >>>>>>>> on my system. Suggest you do a "make clean" on the tools and >>>>>>>> start again ! >>>>>>>> >>>>>>>> After booting with the patched xen-unstable and adding the >>>>>>>> gfx-passthru=1 parameter to my HVM DomU, as I suspected - it >>>>>>>> still doesn''t work. >>>>>>>> >>>>>>>> I have both a 9500GT and GTX260(primary) in my Intel DX58SO >>>>>>>> machine, tried passing through either device and my primary >>>>>>>> display locks up ! (included hiding with pci-stub) >>>>>>>> >>>>>>>> I verified that the DomU was functional beforehand, as It also >>>>>>>> booted successfully without the gfx-passthru parameter (and a >>>>>>>> vncviewer/cirrus display) >>>>>>>> >>>>>>>> Unfortunately, I can''t debug further as my Primary display >>>>>>>> corrupts as soon as the DomU starts. I did notice that in "xm >>>>>>>> debug" the "Loading Gfx BIOS File.." message was displayed and >>>>>>>> the DomU did continue to initialise the BIOS tables and such >>>>>>>> before finally locking. I then (blindly) typed on a corrupt >>>>>>>> Dom0 console and managed to start kdm and login, so the Dom0 >>>>>>>> was not completely trashed. But then after a few minutes, the >>>>>>>> machine totally froze and had to hit the reset switch. >>>>>>>> >>>>>>>> I`m no specialist but this looks like the VGA BIOS >>>>>>>> Re-initialisation is playing havoc with the DomU and possibly >>>>>>>> the Dom0 graphics. I notice that both are also using IRQ11 >>>>>>>> which could play a major part. Furthermore, there was a lot of >>>>>>>> debug output in the qemu and xend.log indicating Base Address >>>>>>>> Register invalid access and therefore it seems there may be a >>>>>>>> second obstacle. >>>>>>>> >>>>>>>> Hope you have a better success than me ! >>>>>>>> >>>>>>>> For now, I would try re-compiling a fresh xen-unstable with >>>>>>>> carefully applied patches .. oh! and don''t forget to enable the >>>>>>>> pci-stub driver for Dom0 (it''s not selected by default) >>>>>>>> >>>>>>>> Tim >>>>>>>> >>>>>>>> *From:* xen-devel-bounces@lists.xensource.com >>>>>>>> [mailto:xen-devel-bounces@lists.xensource.com] *On Behalf Of >>>>>>>> *Mr. Teo En Ming (Zhang Enming) >>>>>>>> *Sent:* 28 August 2009 21:14 >>>>>>>> *To:* enming.teo@asiasoftsea.net >>>>>>>> *Cc:* xen-devel@lists.xensource.com; ''Lin, Ben Y''; ''Kay, Allen >>>>>>>> M''; ''Jean Guyader''; Keir.Fraser@eu.citrix.com; >>>>>>>> weidong.han@intel.com; bengheng@eecs.umich.edu >>>>>>>> *Subject:* Re: [Xen-devel] [PATCH 2/2] graphics passthrough >>>>>>>> with VT-d >>>>>>>> >>>>>>>> After applying the 1st and 2nd patch to xen-unstable successfully, I examined the source codes Makefile and hvmloader.c in tools/firmware/hvmloader, compared them to Weidong''s 3rd patch and I generated my own 3rd patch. Then I used my own generated 3rd patch to apply patching for loading vga bios from firmware file. >>>>>>>> >>>>>>>> Here is my own generated 3rd patch instead of using Weidong''s 3rd patch: >>>>>>>> >>>>>>>> --- Makefile 2009-08-29 03:24:52.413083774 +0800 >>>>>>>> +++ Makefile 2009-08-29 03:29:12.763299633 +0800 >>>>>>>> @@ -50,6 +50,7 @@ >>>>>>>> roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \ >>>>>>>> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h >>>>>>>> sh ./mkhex rombios ../rombios/BIOS-bochs-latest> roms.h >>>>>>>> + sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin>> roms.h >>>>>>>> sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin>> roms.h >>>>>>>> sh ./mkhex vgabios_cirrusvga \ >>>>>>>> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin>> roms.h >>>>>>>> --- hvmloader.c 2009-08-29 03:26:06.911085797 +0800 >>>>>>>> +++ hvmloader.c 2009-08-29 03:31:43.172084995 +0800 >>>>>>>> @@ -688,9 +688,9 @@ >>>>>>>> vgabios_sz = round_option_rom(sizeof(vgabios_stdvga)); >>>>>>>> break; >>>>>>>> case VGA_pt: >>>>>>>> - printf("Loading VGABIOS of passthroughed gfx ...\n"); >>>>>>>> - vgabios_sz >>>>>>>> - round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512); >>>>>>>> + printf("Loading Gfx Video BIOS from file ...\n"); >>>>>>>> + memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt, sizeof(vgabios_pt)); >>>>>>>> + vgabios_sz = round_option_rom(sizeof(vgabios_pt)); >>>>>>>> break; >>>>>>>> default: >>>>>>>> printf("No emulated VGA adaptor ...\n"); >>>>>>>> >>>>>>>> >>>>>>>> I can "make xen" successfully but when I proceeded to "make tools", errors were encountered. >>>>>>>> >>>>>>>> Please see attached error output. How can I solve this problem? >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>>>>>>> Technical Support Engineer >>>>>>>> Information Technology Department >>>>>>>> Asiasoft Online Pte Ltd >>>>>>>> Tampines Central 1 #04-01 Tampines Plaza >>>>>>>> Singapore 529541 >>>>>>>> Republic of Singapore >>>>>>>> Mobile: +65-9648-9798 >>>>>>>> MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> >>>>>>>> Alma Maters: Singapore Polytechnic, National University of Singapore >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 08/29/2009 12:59 AM, Mr. Teo En Ming (Zhang Enming) wrote: >>>>>>>> >>>>>>>> OK I believe the 3rd patch is not incomplete but there''s a white space issue when I copied the code from the mailing list into my vi. >>>>>>>> >>>>>>>> Seehttp://www.htdig.org/mail/2000/11/0167.html >>>>>>>> >>>>>>>> When I used the -l flag to patch using the 3rd patch, the number of errors was reduced. >>>>>>>> >>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -l -p1< intel-gfx-passthru-patch-3.patch >>>>>>>> patching file tools/firmware/hvmloader/Makefile >>>>>>>> patching file tools/firmware/hvmloader/hvmloader.c >>>>>>>> Hunk #1 FAILED at 688. >>>>>>>> 1 out of 1 hunk FAILED -- saving rejects to file tools/firmware/hvmloader/hvmloader.c.rej >>>>>>>> >>>>>>>> Now patching tools/firmware/hvmloader/Makefile is successful but patching tools/firmware/hvmloader/hvmloader.c still failed. >>>>>>>> >>>>>>>> -- >>>>>>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>>>>>>> Technical Support Engineer >>>>>>>> Information Technology Department >>>>>>>> Asiasoft Online Pte Ltd >>>>>>>> Tampines Central 1 #04-01 Tampines Plaza >>>>>>>> Singapore 529541 >>>>>>>> Republic of Singapore >>>>>>>> Mobile: +65-9648-9798 >>>>>>>> MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> >>>>>>>> Alma Maters: Singapore Polytechnic, National University of Singapore >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 08/28/2009 11:55 PM, Mr. Teo En Ming (Zhang Enming) wrote: >>>>>>>> >>>>>>>> Dear Weidong, >>>>>>>> >>>>>>>> A big big thanks for the vga passthrough patches for xen >>>>>>>> 3.5-unstable!!! These are eagerly anticipated patches. As I did >>>>>>>> not study computer science and computer architecture, I won''t >>>>>>>> be able to write those patches you guys at Intel wrote. >>>>>>>> >>>>>>>> I applied the following patches *xen-gfx-passthrough.patch >>>>>>>> <http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin> >>>>>>>> and qemu-gfx-passthrough.patch >>>>>>>> <http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin> >>>>>>>> to xen 3.5-unstable without issues.* >>>>>>>> >>>>>>>> Then I tried to apply the 3rd patch you provided at >>>>>>>> http://lists.xensource.com/archives/html/xen-devel/2009-08/msg01047.html >>>>>>>> >>>>>>>> I saved the following code >>>>>>>> >>>>>>>> <CODE> >>>>>>>> >>>>>>>> diff -r 494be76c1ad9 tools/firmware/hvmloader/Makefile >>>>>>>> --- a/tools/firmware/hvmloader/Makefile Thu Aug 27 16:54:33 2009 +0800 >>>>>>>> +++ b/tools/firmware/hvmloader/Makefile Thu Aug 27 17:22:01 2009 +0800 >>>>>>>> @@ -50,6 +50,7 @@ roms.h: ../rombios/BIOS-bochs-latest ../ >>>>>>>> roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \ >>>>>>>> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h >>>>>>>> sh ./mkhex rombios ../rombios/BIOS-bochs-latest> roms.h >>>>>>>> + sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin>> roms.h >>>>>>>> sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin>> roms.h >>>>>>>> sh ./mkhex vgabios_cirrusvga \ >>>>>>>> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin>> roms.h >>>>>>>> diff -r 494be76c1ad9 tools/firmware/hvmloader/hvmloader.c >>>>>>>> --- a/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 16:54:33 2009 +0800 >>>>>>>> +++ b/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 17:23:00 2009 +0800 >>>>>>>> @@ -688,9 +688,9 @@ int main(void) >>>>>>>> vgabios_sz = round_option_rom(sizeof(vgabios_stdvga)); >>>>>>>> break; >>>>>>>> case VGA_pt: >>>>>>>> - printf("Loading Gfx Video BIOS from 0xC0000 ...\n"); >>>>>>>> - vgabios_sz >>>>>>>> - round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512); >>>>>>>> + printf("Loading Gfx Video BIOS from file ...\n"); >>>>>>>> + memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt, >>>>>>>> sizeof(vgabios_pt)); >>>>>>>> + vgabios_sz = round_option_rom(sizeof(vgabios_pt)); >>>>>>>> break; >>>>>>>> default: >>>>>>>> printf("No emulated VGA adaptor ...\n"); >>>>>>>> >>>>>>>> </CODE> >>>>>>>> >>>>>>>> as intel-gfx-passthru-patch-3.patch and then I tried to apply the patch to xen 3.5-unstable. I got errors. I think it''s because the 3rd patch you provided is incomplete. >>>>>>>> >>>>>>>> Here''s my patching process: >>>>>>>> >>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name vgabios >>>>>>>> ./tools/firmware/vgabios >>>>>>>> ./.hg/store/data/tools/firmware/vgabios >>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cp ~enming/vgabios-pt.bin tools/firmware/vgabios/ >>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ls tools/firmware/vgabios/ >>>>>>>> biossums.c clext.c Makefile TODO vbe.h vgabios.h vgatables.h >>>>>>>> BUGS COPYING Notes vbe.c vbetables-gen.c vgabios-pt.bin >>>>>>>> ChangeLog dataseghack README vbe_display_api.txt vgabios.c vgafonts.h >>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# pwd >>>>>>>> /usr/src/xen-unstable.hg-vgapt >>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wgethttp://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin >>>>>>>> --2009-08-28 23:18:21--http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin >>>>>>>> Resolving lists.xensource.com... 70.42.241.110 >>>>>>>> Connecting to lists.xensource.com|70.42.241.110|:80... connected. >>>>>>>> HTTP request sent, awaiting response... 200 OK >>>>>>>> Length: 12565 (12K) [application/octet-stream] >>>>>>>> Saving to: `bincPiiAf0QWg.bin'' >>>>>>>> >>>>>>>> 100%[======================================================================>] 12,565 30.7K/s in 0.4s >>>>>>>> >>>>>>>> 2009-08-28 23:18:22 (30.7 KB/s) - `bincPiiAf0QWg.bin'' saved [12565/12565] >>>>>>>> >>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv bincPiiAf0QWg.bin xen-gfx-passthrough.patch >>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi xen-gfx-passthrough.patch >>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch< xen-gfx-passthrough.patch >>>>>>>> can''t find file to patch at input line 4 >>>>>>>> Perhaps you should have used the -p or --strip option? >>>>>>>> The text leading up to this was: >>>>>>>> -------------------------- >>>>>>>> |diff -r 5d7e7a250267 tools/firmware/hvmloader/config.h >>>>>>>> |--- a/tools/firmware/hvmloader/config.h Wed Aug 26 18:28:44 2009 +0800 >>>>>>>> |+++ b/tools/firmware/hvmloader/config.h Thu Aug 27 16:54:24 2009 +0800 >>>>>>>> -------------------------- >>>>>>>> File to patch: ^C >>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ex xen-gfx-passthrough.patch >>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1< xen-gfx-passthrough.patch >>>>>>>> patching file tools/firmware/hvmloader/config.h >>>>>>>> patching file tools/firmware/hvmloader/hvmloader.c >>>>>>>> patching file tools/libxc/ia64/xc_ia64_hvm_build.c >>>>>>>> patching file tools/libxc/xc_hvm_build.c >>>>>>>> patching file tools/libxc/xc_linux.c >>>>>>>> patching file tools/libxc/xenctrl.h >>>>>>>> patching file tools/libxc/xenguest.h >>>>>>>> patching file tools/python/xen/lowlevel/xc/xc.c >>>>>>>> patching file tools/python/xen/xend/XendConfig.py >>>>>>>> Hunk #1 succeeded at 174 (offset -1 lines). >>>>>>>> patching file tools/python/xen/xend/image.py >>>>>>>> Hunk #1 succeeded at 780 (offset -6 lines). >>>>>>>> Hunk #3 succeeded at 895 (offset -6 lines). >>>>>>>> patching file tools/python/xen/xm/create.py >>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wgethttp://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin >>>>>>>> --2009-08-28 23:21:35--http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin >>>>>>>> Resolving lists.xensource.com... 70.42.241.110 >>>>>>>> Connecting to lists.xensource.com|70.42.241.110|:80... connected. >>>>>>>> HTTP request sent, awaiting response... 200 OK >>>>>>>> Length: 9841 (9.6K) [application/octet-stream] >>>>>>>> Saving to: `binglLqkeq4Rj.bin'' >>>>>>>> >>>>>>>> 100%[======================================================================>] 9,841 24.3K/s in 0.4s >>>>>>>> >>>>>>>> 2009-08-28 23:21:36 (24.3 KB/s) - `binglLqkeq4Rj.bin'' saved [9841/9841] >>>>>>>> >>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv binglLqkeq4Rj.bin qemu-gfx-passthrough.patch >>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi qemu-gfx-passthrough.patch >>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name hw >>>>>>>> ./tools/ioemu-remote/hw >>>>>>>> ./.hg/store/data/tools/ioemu/hw >>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv qemu-gfx-passthrough.patch tools/ioemu-remote/ >>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cd tools/ioemu-remote/ >>>>>>>> [root@fedora11-x86-64-host ioemu-remote]# patch -p1< qemu- >>>>>>>> qemu-aio.h qemu-img.c qemu-sockets.c >>>>>>>> qemu-binfmt-conf.sh qemu-img.texi qemu-tech.texi >>>>>>>> qemu-char.c qemu-lock.h qemu-timer.h >>>>>>>> qemu-char.h qemu-log.h qemu-tool.c >>>>>>>> qemu-common.h qemu-malloc.c qemu-xen.h >>>>>>>> qemu-doc.texi qemu-nbd.c >>>>>>>> qemu-gfx-passthrough.patch qemu-nbd.texi >>>>>>>> [root@fedora11-x86-64-host ioemu-remote]# patch -p1< qemu-gfx-passthrough.patch >>>>>>>> patching file hw/pass-through.c >>>>>>>> patching file hw/pass-through.h >>>>>>>> patching file hw/pc.c >>>>>>>> patching file vl.c >>>>>>>> [root@fedora11-x86-64-host ioemu-remote]# cd .. >>>>>>>> [root@fedora11-x86-64-host tools]# cd .. >>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi intel-gfx-passthru-patch-3.patch >>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1< intel-gfx-passthru-patch-3.patch >>>>>>>> patching file tools/firmware/hvmloader/Makefile >>>>>>>> Hunk #1 FAILED at 50. >>>>>>>> 1 out of 1 hunk FAILED -- saving rejects to file tools/firmware/hvmloader/Makefile.rej >>>>>>>> patching file tools/firmware/hvmloader/hvmloader.c >>>>>>>> patch: **** malformed patch at line 24: sizeof(vgabios_pt)); >>>>>>>> >>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi intel-gfx-passthru-patch-3.patch >>>>>>>> >>>>>>>> For everybody''s convenience, I have attached intel-gfx-passthru-patch-3.patch and the firmware for my nVidia GeForce 8400 GS PCI Express x16 graphics card in this email. >>>>>>>> >>>>>>>> Please help me complete intel-gfx-passthru-patch-3.patch as I really need it. >>>>>>>> >>>>>>>> Thank you very much!!! >>>>>>>> >>>>>>>> -- >>>>>>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>>>>>>> Technical Support Engineer >>>>>>>> Information Technology Department >>>>>>>> Asiasoft Online Pte Ltd >>>>>>>> Tampines Central 1 #04-01 Tampines Plaza >>>>>>>> Singapore 529541 >>>>>>>> Republic of Singapore >>>>>>>> Mobile: +65-9648-9798 >>>>>>>> MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> >>>>>>>> Alma Maters: Singapore Polytechnic, National University of Singapore >>>>>>>> >>>>>>>> This patch supports basic gfx passthrough on QEMU: >>>>>>>> >>>>>>>> - disable emulated VGA adpater if there is passthroughed gfx >>>>>>>> >>>>>>>> - register/unregister legacy VGA I/O ports and MMIOs for passthroughed gfx >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Signed-off-by: Ben Lin<ben.y.lin@intel.com> <mailto:ben.y.lin@intel.com> >>>>>>>> >>>>>>>> Signed-off-by: Weidong Han<weidong.han@intel.com> <mailto:weidong.han@intel.com> >>>>>>>> >>>>>>>> No virus found in this incoming message. >>>>>>>> >>>>>>>> Checked by AVG -www.avg.com <http://www.avg.com> >>>>>>>> >>>>>>>> Version: 8.5.409 / Virus Database: 270.13.69/2328 - Release Date: 08/27/09 >>>>>>>> >>>>>>>> 18:02:00 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> No virus found in this outgoing message. >>>>>>>> >>>>>>>> Checked by AVG -www.avg.com <http://www.avg.com> >>>>>>>> >>>>>>>> Version: 8.5.409 / Virus Database: 270.13.71/2330 - Release Date: 08/27/09 >>>>>>>> >>>>>>>> 18:02:00 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------------------------------ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> >>>>>>>> Xen-devel mailing list >>>>>>>> >>>>>>>> Xen-devel@lists.xensource.com <mailto:Xen-devel@lists.xensource.com> >>>>>>>> >>>>>>>> http://lists.xensource.com/xen-devel >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ------------------------------------------------------------------------ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Xen-devel mailing list >>>>>>>> Xen-devel@lists.xensource.com <mailto: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 >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >> >> >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mr. Teo En Ming (Zhang Enming)
2009-Aug-29 14:48 UTC
Re: [Xen-devel] graphics passthrough with VT-d
I am wondering if there are any cheap consumer ATI PCIe x16 graphics card that does not depend on 1:1 BAR mapping? -- Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) Technical Support Engineer Information Technology Department Asiasoft Online Pte Ltd Tampines Central 1 #04-01 Tampines Plaza Singapore 529541 Republic of Singapore Company Website: http://www.asiasoft.sg/ Mobile: +65-9648-9798 MSN: teoenming@hotmail.com Alma Maters: Singapore Polytechnic, National University of Singapore On 08/29/2009 10:12 PM, Mr. Teo En Ming (Zhang Enming) wrote:> Hi Timothy, > > Yes, I renamed the firmware file of nVidia Geforce 8400 GS to > vgabios-pt.bin and placed it in the source directory > tools/firmware/vgabios. > > Weidong had said Intel has the 1:1 mapping patches. Let''s hope he will > release the patch soon to do pBAR:vBAR. > > -- > Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) > Technical Support Engineer > Information Technology Department > Asiasoft Online Pte Ltd > Tampines Central 1 #04-01 Tampines Plaza > Singapore 529541 > Republic of Singapore > Company Website:http://www.asiasoft.sg/ > Mobile: +65-9648-9798 > MSN:teoenming@hotmail.com > Alma Maters: Singapore Polytechnic, National University of Singapore > > > On 08/29/2009 09:29 PM, Tim Moore wrote: >> >> Teo, >> >> Did you rename your Nvidia BIOS and copy it into the hvmloader source >> tree as required ? >> >> It should get compiled into roms.h in the hvmloader folder - I made >> sure it was there as the xen buildroot seems to delete it randomly ... >> >> I think we are now up against the Base Address Register issue where >> the Nvidia driver is expecting to see the card at the Physical BAR >> Addresses and in the DomU these are re-mapped to different address >> space ... this is a problem with the Nvidia binary driver and >> therefore a workaround in xen is maybe needed. >> >> That said, I''m not sure if the Nvidia BIOS likes to be re-executed >> and may also be an issue ... >> >> Tim >> >> *From:* Mr. Teo En Ming (Zhang Enming) >> [mailto:enming.teo@asiasoftsea.net] >> *Sent:* 29 August 2009 14:21 >> *To:* enming.teo@asiasoftsea.net >> *Cc:* Tim Moore; xen-devel@lists.xensource.com >> *Subject:* Re: [Xen-devel] graphics passthrough with VT-d >> >> Dear All, >> >> I have applied the following patches to xen 3.5-unstable >> >> 1) intel-gfx-passthru-patch01.patch >> 2) intel-gfx-passthru-patch02.patch >> 3) intel-gfx-passthru-patch03.patch >> 4) enming-patch04.patch >> >> and compiled xen 3.5-unstable successfully (both hypervisor and tools). >> >> i rebooted into this newly compiled Xen hypervisor which supports >> loading vga bios from firmware file of nVidia Geforce 8400 GS PCI >> Express x16. >> >> After dom0 has booted up, I executed the following script to hide >> nVidia Geforce 8400 GS from dom0. >> >> [enming@fedora11-x86-64-host scripts]$ cat bind-devices-pci-stub.sh >> #!/bin/sh >> echo "10de 06e4" > /sys/bus/pci/drivers/pci-stub/new_id >> echo "0000:01:00.0" > /sys/bus/pci/devices/0000:01:00.0/driver/unbind >> echo "0000:01:00.0" > /sys/bus/pci/drivers/pci-stub/bind >> >> I also assigned the nVidia Geforce 8400 GS to my Windows XP Home HVM >> domU. >> >> pci = [ ''01:00.0'' ] >> >> I also specified gfx_passthru=2. >> >> Do note that I booted up with onboard Intel GMA4500 as the primary >> video adapter. Hence dom 0 has onboard graphics and Windows XP HVM >> domU has nvidia graphics. >> >> Then I started Windows XP Home HVM DomU. >> >> Very soon, my Dom 0''s display was garbaged and X server on Dom 0 >> totally froze and became unresponsive. I cannot switch to any ttys. >> >> However, I was still able to vnc into my Windows XP Home HVM Dom U. I >> had earlier installed a VNC server into my Windows XP guest. After >> remoting in to my Windows XP DomU through vnc, I found that NVIDIA >> Geforce 8400 GS cannot be initialized and no resources are available >> for this graphics card. >> >> >> -- >> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >> Technical Support Engineer >> Information Technology Department >> Asiasoft Online Pte Ltd >> Tampines Central 1 #04-01 Tampines Plaza >> Singapore 529541 >> Republic of Singapore >> Company Website:http://www.asiasoft.sg/ >> Mobile: +65-9648-9798 >> MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> >> Alma Maters: Singapore Polytechnic, National University of Singapore >> >> >> >> On 08/29/2009 08:25 PM, Mr. Teo En Ming (Zhang Enming) wrote: >> >> Hi All, >> >> I have solved the problem encountered below when building tools for >> xen 3.5-unstable. The compile problem exists because I downloaded and >> compiled the latest version of Intel ACPI Component Architecture >> compiler version 20090730. And I used this latest compiler during >> "make tools" for xen-unstable. >> >> In original xen-unstable source codes cloned from xensoure mercurial >> repository, the header files ssdt_pm.h and ssdt_tpm.h in source >> directory tools/firmware/hvmloader/acpi/ are generated by >> >> /* >> * >> * Intel ACPI Component Architecture >> * ASL Optimizing Compiler version 20061109 [May 18 2007] >> * Copyright (C) 2000 - 2006 Intel Corporation >> * Supports ACPI Specification Revision 3.0a >> * >> * Compilation of "ssdt_pm.asl" - Sun Oct 12 23:57:51 2008 >> * >> * C source code output >> * >> */ >> >> In original ssdt_pm.h, it has "unsigned char AmlCode_PM[] =". >> >> In original ssdt_tpm.h, it has "unsigned char AmlCode_TPM[] =". >> >> Hence there was no problem with "make tools". >> >> But, I downloaded, compiled and used >> >> /* >> * >> * Intel ACPI Component Architecture >> * ASL Optimizing Compiler version 20090730 [Aug 29 2009] >> * Copyright (C) 2000 - 2009 Intel Corporation >> * Supports ACPI Specification Revision 4.0 >> * >> * Compilation of "ssdt_pm.asl" - Sat Aug 29 18:55:40 2009 >> * >> * C source code output >> * >> */ >> >> So the *new* ssdt_pm.h contains: >> >> /* >> * >> * Intel ACPI Component Architecture >> * ASL Optimizing Compiler version 20090730 [Aug 29 2009] >> * Copyright (C) 2000 - 2009 Intel Corporation >> * Supports ACPI Specification Revision 4.0 >> * >> * Compilation of "ssdt_pm.asl" - Sat Aug 29 18:55:40 2009 >> * >> * C source code output >> * >> */ >> unsigned char AmlCode[] >> { >> 0x53,0x53,0x44,0x54,0xD6,0x05,0x00,0x00, /* 00000000 >> "SSDT...." */ >> 0x02,0xB9,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008 >> "..Xen..." */ >> 0x48,0x56,0x4D,0x00,0x00,0x00,0x00,0x00, /* 00000010 >> "HVM....." */ >> 0x00,0x00,0x00,0x00,0x49,0x4E,0x54,0x4C, /* 00000018 >> "....INTL" */ >> 0x30,0x07,0x09,0x20,0x10,0x41,0x5B,0x5C, /* 00000020 "0.. >> .A[\" */ >> 0x5F,0x53,0x42,0x5F,0x5B,0x80,0x44,0x42, /* 00000028 >> "_SB_[.DB" */ >> 0x47,0x41,0x01,0x0B,0x40,0xB0,0x01,0x5B, /* 00000030 "GA..@..[" >> <mailto:GA..@..%5B> */ >> 0x81,0x0B,0x44,0x42,0x47,0x41,0x01,0x44, /* 00000038 >> "..DBGA.D" */ >> 0x42,0x47,0x31,0x08,0x5B,0x80,0x44,0x42, /* 00000040 >> "BG1.[.DB" */ >> 0x47,0x42,0x01,0x0B,0x44,0xB0,0x01,0x5B, /* 00000048 >> "GB..D..[" */ >> 0x81,0x0B,0x44,0x42,0x47,0x42,0x01,0x44, /* 00000050 >> "..DBGB.D" */ >> 0x42,0x47,0x32,0x08,0x5B,0x80,0x44,0x42, /* 00000058 >> "BG2.[.DB" */ >> 0x47,0x43,0x01,0x0B,0x46,0xB0,0x01,0x5B, /* 00000060 >> "GC..F..[" */ >> 0x81,0x0B,0x44,0x42,0x47,0x43,0x01,0x44, /* 00000068 >> "..DBGC.D" */ >> 0x42,0x47,0x33,0x08,0x5B,0x80,0x44,0x42, /* 00000070 >> "BG3.[.DB" */ >> 0x47,0x44,0x01,0x0B,0x48,0xB0,0x01,0x5B, /* 00000078 >> "GD..H..[" */ >> 0x81,0x0B,0x44,0x42,0x47,0x44,0x01,0x44, /* 00000080 >> "..DBGD.D" */ >> 0x42,0x47,0x34,0x08,0x5B,0x80,0x50,0x52, /* 00000088 >> "BG4.[.PR" */ >> 0x54,0x31,0x01,0x0A,0xB2,0x0A,0x02,0x5B, /* 00000090 >> "T1.....[" */ >> 0x81,0x10,0x50,0x52,0x54,0x31,0x01,0x50, /* 00000098 >> "..PRT1.P" */ >> 0x42,0x32,0x5F,0x08,0x50,0x42,0x32,0x41, /* 000000A0 >> "B2_.PB2A" */ >> 0x08,0x5B,0x80,0x50,0x52,0x54,0x32,0x01, /* 000000A8 >> ".[.PRT2." */ >> 0x0A,0x86,0x01,0x5B,0x81,0x0B,0x50,0x52, /* 000000B0 >> "...[..PR" */ >> 0x54,0x32,0x01,0x50,0x38,0x36,0x5F,0x08, /* 000000B8 >> "T2.P86_." */ >> 0x5B,0x80,0x50,0x52,0x54,0x33,0x01,0x0A, /* 000000C0 >> "[.PRT3.." */ >> 0x88,0x01,0x5B,0x81,0x0B,0x50,0x52,0x54, /* 000000C8 >> "..[..PRT" */ >> 0x33,0x01,0x50,0x38,0x38,0x5F,0x08,0x5B, /* 000000D0 >> "3.P88_.[" */ >> 0x01,0x53,0x59,0x4E,0x43,0x01,0x08,0x42, /* 000000D8 >> ".SYNC..B" */ >> 0x55,0x46,0x30,0x11,0x04,0x0B,0x00,0x01, /* 000000E0 >> "UF0....." */ >> 0x08,0x42,0x55,0x46,0x31,0x11,0x03,0x0A, /* 000000E8 >> ".BUF1..." */ >> 0x08,0x8B,0x42,0x55,0x46,0x31,0x00,0x42, /* 000000F0 >> "..BUF1.B" */ >> 0x55,0x46,0x41,0x8B,0x42,0x55,0x46,0x31, /* 000000F8 >> "UFA.BUF1" */ >> 0x0A,0x04,0x42,0x55,0x46,0x42,0x14,0x14, /* 00000100 >> "..BUFB.." */ >> >> And the *new* ssdt_tpm.h contains: >> >> /* >> * >> * Intel ACPI Component Architecture >> * ASL Optimizing Compiler version 20090730 [Aug 29 2009] >> * Copyright (C) 2000 - 2009 Intel Corporation >> * Supports ACPI Specification Revision 4.0 >> * >> * Compilation of "ssdt_tpm.asl" - Sat Aug 29 18:55:40 2009 >> * >> * C source code output >> * >> */ >> unsigned char AmlCode[] >> { >> 0x53,0x53,0x44,0x54,0x4C,0x00,0x00,0x00, /* 00000000 >> "SSDTL..." */ >> 0x02,0x2A,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008 >> ".*Xen..." */ >> 0x48,0x56,0x4D,0x00,0x00,0x00,0x00,0x00, /* 00000010 >> "HVM....." */ >> 0x00,0x00,0x00,0x00,0x49,0x4E,0x54,0x4C, /* 00000018 >> "....INTL" */ >> 0x30,0x07,0x09,0x20,0x5B,0x82,0x26,0x54, /* 00000020 "0.. >> [.&T" */ >> 0x50,0x4D,0x5F,0x08,0x5F,0x48,0x49,0x44, /* 00000028 >> "PM_._HID" */ >> 0x0C,0x41,0xD0,0x0C,0x31,0x08,0x5F,0x43, /* 00000030 >> ".A..1._C" */ >> 0x52,0x53,0x11,0x11,0x0A,0x0E,0x86,0x09, /* 00000038 >> "RS......" */ >> 0x00,0x01,0x00,0x00,0xD4,0xFE,0x00,0x50, /* 00000040 >> ".......P" */ >> 0x00,0x00,0x79,0x00, >> }; >> >> which are both wrong. >> >> In ssdt_pm.h, I have to change "unsigned char AmlCode[]" to "unsigned >> char AmlCode_PM[]". >> >> In ssdt_tpm.h, I have to change "unsigned char AmlCode[]" to >> "unsigned char AmlCode_TPM[]". >> >> Then "make tools" is able to complete successfully. >> >> I have created a patch for anybody who may be using the *latest* >> version of Intel ACPI CA compiler version 20090730 and attached it here. >> >> Patch file filename enming-patch04.patch: >> >> <CODE> >> >> Patch created by Teo En Ming (Zhang Enming) on 29 August 2009 >> Saturday at 8:00 P.M. Singapore Time >> Email #1: enming.teo@asiasoftsea.net <mailto:enming.teo@asiasoftsea.net> >> Email #2: space.time.universe@gmail.com >> <mailto:space.time.universe@gmail.com> >> MSN: teoenming@hotmail.com <mailto:teoenming@hotmail.com> >> Mobile Phone: +65-9648-9798 >> >> --- ssdt_pm.h 2009-08-29 19:54:52.653088000 +0800 >> +++ ssdt_pm.h 2009-08-29 19:56:51.813088550 +0800 >> @@ -10,7 +10,7 @@ >> * C source code output >> * >> */ >> -unsigned char AmlCode[] >> +unsigned char AmlCode_PM[] >> { >> 0x53,0x53,0x44,0x54,0xD6,0x05,0x00,0x00, /* 00000000 >> "SSDT...." */ >> 0x02,0xB9,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008 >> "..Xen..." */ >> --- ssdt_tpm.h 2009-08-29 19:55:44.578738954 +0800 >> +++ ssdt_tpm.h 2009-08-29 19:57:27.896638884 +0800 >> @@ -10,7 +10,7 @@ >> * C source code output >> * >> */ >> -unsigned char AmlCode[] >> +unsigned char AmlCode_TPM[] >> { >> 0x53,0x53,0x44,0x54,0x4C,0x00,0x00,0x00, /* 00000000 >> "SSDTL..." */ >> 0x02,0x2A,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008 >> ".*Xen..." */ >> >> </CODE> >> >> >> -- >> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >> Technical Support Engineer >> Information Technology Department >> Asiasoft Online Pte Ltd >> Tampines Central 1 #04-01 Tampines Plaza >> Singapore 529541 >> Republic of Singapore >> Company Website:http://www.asiasoft.sg/ >> Mobile: +65-9648-9798 >> MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> >> Alma Maters: Singapore Polytechnic, National University of Singapore >> >> >> >> On 08/29/2009 07:03 PM, Mr. Teo En Ming (Zhang Enming) wrote: >> >> Hi, >> >> I clonedhttp://xenbits.xensource.com/xen-unstable.hg again today. I tried applying the three Intel gfx passthrough patches to xen-unstable. When I "make tools", I get the same error again: >> >> make[7]: Entering directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader'' >> make -C acpi all >> get-path: will use #!/usr/bin/python2.6 for python programs >> make[8]: Entering directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' >> make iasl >> get-path: will use #!/usr/bin/python2.6 for python programs >> make[9]: Entering directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' >> make[9]: `/usr/local/bin/iasl'' is up to date. >> make[9]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' >> iasl -tc ssdt_tpm.asl >> >> Intel ACPI Component Architecture >> ASL Optimizing Compiler version 20090730 [Aug 29 2009] >> Copyright (C) 2000 - 2009 Intel Corporation >> Supports ACPI Specification Revision 4.0 >> >> ASL Input: ssdt_tpm.asl - 31 lines, 1111 bytes, 3 keywords >> AML Output: SSDT_TPM.aml - 76 bytes, 3 named objects, 0 executable opcodes >> >> Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 0 Optimizations >> mv ssdt_tpm.hex ssdt_tpm.h >> rm -f *.aml >> make iasl >> get-path: will use #!/usr/bin/python2.6 for python programs >> make[9]: Entering directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' >> make[9]: `/usr/local/bin/iasl'' is up to date. >> make[9]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' >> iasl -tc ssdt_pm.asl >> >> Intel ACPI Component Architecture >> ASL Optimizing Compiler version 20090730 [Aug 29 2009] >> Copyright (C) 2000 - 2009 Intel Corporation >> Supports ACPI Specification Revision 4.0 >> >> ASL Input: ssdt_pm.asl - 425 lines, 12754 bytes, 192 keywords >> AML Output: SSDT_PM.aml - 1494 bytes, 64 named objects, 128 executable opcodes >> >> Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 31 Optimizations >> mv ssdt_pm.hex ssdt_pm.h >> rm -f *.aml >> gcc -O1 -fno-omit-frame-pointer -fno-optimize-sibling-calls -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .build.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs -Werror -fno-stack-protector -fno-builtin -msoft-float -I. -I.. -I../../../../tools/include -c -o build.o build.c >> In file included from build.c:21: >> ssdt_pm.h:13: error: redefinition of ''AmlCode'' >> ssdt_tpm.h:13: note: previous definition of ''AmlCode'' was here >> build.c: In function ''construct_secondary_tables'': >> build.c:184: error: ''AmlCode_PM'' undeclared (first use in this function) >> build.c:184: error: (Each undeclared identifier is reported only once >> build.c:184: error: for each function it appears in.) >> build.c:194: error: ''AmlCode_TPM'' undeclared (first use in this function) >> make[8]: *** [build.o] Error 1 >> make[8]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' >> make[7]: *** [subdir-all-acpi] Error 2 >> make[7]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader'' >> make[6]: *** [subdirs-all] Error 2 >> make[6]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader'' >> make[5]: *** [subdir-all-hvmloader] Error 2 >> make[5]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware'' >> make[4]: *** [subdirs-all] Error 2 >> make[4]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware'' >> make[3]: *** [all] Error 2 >> make[3]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware'' >> make[2]: *** [subdir-install-firmware] Error 2 >> make[2]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools'' >> make[1]: *** [subdirs-install] Error 2 >> make[1]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools'' >> make: *** [install-tools] Error 2 >> >> Any ideas about this Advanced Configuration and Power Interface code? >> >> -- >> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >> Technical Support Engineer >> Information Technology Department >> Asiasoft Online Pte Ltd >> Tampines Central 1 #04-01 Tampines Plaza >> Singapore 529541 >> Republic of Singapore >> Company Website:http://www.asiasoft.sg/ >> Mobile: +65-9648-9798 >> MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> >> Alma Maters: Singapore Polytechnic, National University of Singapore >> >> >> >> On 08/29/2009 02:58 PM, Mr. Teo En Ming (Zhang Enming) wrote: >> >> Hi >> >> Anybody available today? I know it''s Saturday. :-) >> >> >> -- >> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >> Technical Support Engineer >> Information Technology Department >> Asiasoft Online Pte Ltd >> Tampines Central 1 #04-01 Tampines Plaza >> Singapore 529541 >> Republic of Singapore >> Company Website:http://www.asiasoft.sg/ >> Mobile: +65-9648-9798 >> MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> >> Alma Maters: Singapore Polytechnic, National University of Singapore >> >> >> >> On 08/29/2009 11:48 AM, Mr. Teo En Ming (Zhang Enming) wrote: >> >> >> >> Dear All, >> >> After applying Intel VGA passthrough patches 1, 2 and 3, I have no problems with "make xen", and "make install-xen". However, I have errors with "make tools". >> >> Here is the error output: >> >> msoft-float -I. -I.. -I../../../../tools/include -c -o build.o build.c >> build.c: In function ''construct_secondary_tables'': >> build.c:194: error: ''AmlCode_TPM'' undeclared (first use in this function) >> build.c:194: error: (Each undeclared identifier is reported only once >> build.c:194: error: for each function it appears in.) >> make[8]: *** [build.o] Error 1 >> make[8]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader/acpi'' >> make[7]: *** [subdir-all-acpi] Error 2 >> make[7]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader'' >> make[6]: *** [subdirs-all] Error 2 >> make[6]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader'' >> make[5]: *** [subdir-all-hvmloader] Error 2 >> make[5]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'' >> make[4]: *** [subdirs-all] Error 2 >> make[4]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'' >> make[3]: *** [all] Error 2 >> make[3]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'' >> make[2]: *** [subdir-install-firmware] Error 2 >> make[2]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools'' >> make[1]: *** [subdirs-install] Error 2 >> make[1]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools'' >> make: *** [install-tools] Error 2 >> >> There is an undeclared identifier in tools/firmware/hvmloader/acpi/build.c source code. Could you guys help me resolve this issue? >> >> I had no problems compiling xen 3.5-unstable before applying the Intel vga passthrough patches and before installing the Intel ACPI Component Architecture compiler. >> >> I have also attached Intel graphics passthrough patches 1, 2 and 3 for your convenience here. >> >> Thank you very much. >> >> Hope I can get this working during the weekends. >> >> -- >> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >> Technical Support Engineer >> Information Technology Department >> Asiasoft Online Pte Ltd >> Tampines Central 1 #04-01 Tampines Plaza >> Singapore 529541 >> Republic of Singapore >> Company Website:http://www.asiasoft.sg/ >> Mobile: +65-9648-9798 >> MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> >> Alma Maters: Singapore Polytechnic, National University of Singapore >> >> >> >> On 08/29/2009 10:17 AM, Mr. Teo En Ming (Zhang Enming) wrote: >> >> Hi Tim, >> >> I thought it should be gfx_passthru=2 in domU config? >> >> -- >> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >> Technical Support Engineer >> Information Technology Department >> Asiasoft Online Pte Ltd >> Tampines Central 1 #04-01 Tampines Plaza >> Singapore 529541 >> Republic of Singapore >> Mobile: +65-9648-9798 >> MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> >> Alma Maters: Singapore Polytechnic, National University of Singapore >> >> >> >> On 08/29/2009 06:42 AM, Tim Moore wrote: >> >> Teo, >> >> I have also performed the same exercise as yourself and I now have >> successfully compiled all 3x patches into Xen, Qemu and the BIOS File >> Loading in the hvmloader, this all compiles find on my system. >> Suggest you do a "make clean" on the tools and start again ! >> >> After booting with the patched xen-unstable and adding the >> gfx-passthru=1 parameter to my HVM DomU, as I suspected - it still >> doesn''t work. >> >> I have both a 9500GT and GTX260(primary) in my Intel DX58SO machine, >> tried passing through either device and my primary display locks up ! >> (included hiding with pci-stub) >> >> I verified that the DomU was functional beforehand, as It also booted >> successfully without the gfx-passthru parameter (and a >> vncviewer/cirrus display) >> >> Unfortunately, I can''t debug further as my Primary display corrupts >> as soon as the DomU starts. I did notice that in "xm debug" the >> "Loading Gfx BIOS File.." message was displayed and the DomU did >> continue to initialise the BIOS tables and such before finally >> locking. I then (blindly) typed on a corrupt Dom0 console and managed >> to start kdm and login, so the Dom0 was not completely trashed. But >> then after a few minutes, the machine totally froze and had to hit >> the reset switch. >> >> I`m no specialist but this looks like the VGA BIOS Re-initialisation >> is playing havoc with the DomU and possibly the Dom0 graphics. I >> notice that both are also using IRQ11 which could play a major part. >> Furthermore, there was a lot of debug output in the qemu and xend.log >> indicating Base Address Register invalid access and therefore it >> seems there may be a second obstacle. >> >> Hope you have a better success than me ! >> >> For now, I would try re-compiling a fresh xen-unstable with carefully >> applied patches .. oh! and don''t forget to enable the pci-stub driver >> for Dom0 (it''s not selected by default) >> >> Tim >> >> *From:* xen-devel-bounces@lists.xensource.com >> <mailto:xen-devel-bounces@lists.xensource.com> >> [mailto:xen-devel-bounces@lists.xensource.com] *On Behalf Of *Mr. Teo >> En Ming (Zhang Enming) >> *Sent:* 28 August 2009 21:14 >> *To:* enming.teo@asiasoftsea.net <mailto:enming.teo@asiasoftsea.net> >> *Cc:* xen-devel@lists.xensource.com >> <mailto:xen-devel@lists.xensource.com>; ''Lin, Ben Y''; ''Kay, Allen M''; >> ''Jean Guyader''; Keir.Fraser@eu.citrix.com >> <mailto:Keir.Fraser@eu.citrix.com>; weidong.han@intel.com >> <mailto:weidong.han@intel.com>; bengheng@eecs.umich.edu >> <mailto:bengheng@eecs.umich.edu> >> *Subject:* Re: [Xen-devel] [PATCH 2/2] graphics passthrough with VT-d >> >> After applying the 1st and 2nd patch to xen-unstable successfully, I examined the source codes Makefile and hvmloader.c in tools/firmware/hvmloader, compared them to Weidong''s 3rd patch and I generated my own 3rd patch. Then I used my own generated 3rd patch to apply patching for loading vga bios from firmware file. >> >> Here is my own generated 3rd patch instead of using Weidong''s 3rd patch: >> >> --- Makefile 2009-08-29 03:24:52.413083774 +0800 >> +++ Makefile 2009-08-29 03:29:12.763299633 +0800 >> @@ -50,6 +50,7 @@ >> roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \ >> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h >> sh ./mkhex rombios ../rombios/BIOS-bochs-latest> roms.h >> + sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin>> roms.h >> sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin>> roms.h >> sh ./mkhex vgabios_cirrusvga \ >> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin>> roms.h >> --- hvmloader.c 2009-08-29 03:26:06.911085797 +0800 >> +++ hvmloader.c 2009-08-29 03:31:43.172084995 +0800 >> @@ -688,9 +688,9 @@ >> vgabios_sz = round_option_rom(sizeof(vgabios_stdvga)); >> break; >> case VGA_pt: >> - printf("Loading VGABIOS of passthroughed gfx ...\n"); >> - vgabios_sz >> - round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512); >> + printf("Loading Gfx Video BIOS from file ...\n"); >> + memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt, sizeof(vgabios_pt)); >> + vgabios_sz = round_option_rom(sizeof(vgabios_pt)); >> break; >> default: >> printf("No emulated VGA adaptor ...\n"); >> >> >> I can "make xen" successfully but when I proceeded to "make tools", errors were encountered. >> >> Please see attached error output. How can I solve this problem? >> >> >> -- >> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >> Technical Support Engineer >> Information Technology Department >> Asiasoft Online Pte Ltd >> Tampines Central 1 #04-01 Tampines Plaza >> Singapore 529541 >> Republic of Singapore >> Mobile: +65-9648-9798 >> MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> >> Alma Maters: Singapore Polytechnic, National University of Singapore >> >> >> >> On 08/29/2009 12:59 AM, Mr. Teo En Ming (Zhang Enming) wrote: >> >> OK I believe the 3rd patch is not incomplete but there''s a white space issue when I copied the code from the mailing list into my vi. >> >> Seehttp://www.htdig.org/mail/2000/11/0167.html >> >> When I used the -l flag to patch using the 3rd patch, the number of errors was reduced. >> >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -l -p1< intel-gfx-passthru-patch-3.patch >> patching file tools/firmware/hvmloader/Makefile >> patching file tools/firmware/hvmloader/hvmloader.c >> Hunk #1 FAILED at 688. >> 1 out of 1 hunk FAILED -- saving rejects to file tools/firmware/hvmloader/hvmloader.c.rej >> >> Now patching tools/firmware/hvmloader/Makefile is successful but patching tools/firmware/hvmloader/hvmloader.c still failed. >> >> -- >> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >> Technical Support Engineer >> Information Technology Department >> Asiasoft Online Pte Ltd >> Tampines Central 1 #04-01 Tampines Plaza >> Singapore 529541 >> Republic of Singapore >> Mobile: +65-9648-9798 >> MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> >> Alma Maters: Singapore Polytechnic, National University of Singapore >> >> >> >> >> On 08/28/2009 11:55 PM, Mr. Teo En Ming (Zhang Enming) wrote: >> >> Dear Weidong, >> >> A big big thanks for the vga passthrough patches for xen >> 3.5-unstable!!! These are eagerly anticipated patches. As I did not >> study computer science and computer architecture, I won''t be able to >> write those patches you guys at Intel wrote. >> >> I applied the following patches *xen-gfx-passthrough.patch >> <http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin> >> and qemu-gfx-passthrough.patch >> <http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin> >> to xen 3.5-unstable without issues.* >> >> Then I tried to apply the 3rd patch you provided at >> http://lists.xensource.com/archives/html/xen-devel/2009-08/msg01047.html >> >> I saved the following code >> >> <CODE> >> >> diff -r 494be76c1ad9 tools/firmware/hvmloader/Makefile >> --- a/tools/firmware/hvmloader/Makefile Thu Aug 27 16:54:33 2009 +0800 >> +++ b/tools/firmware/hvmloader/Makefile Thu Aug 27 17:22:01 2009 +0800 >> @@ -50,6 +50,7 @@ roms.h: ../rombios/BIOS-bochs-latest ../ >> roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \ >> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h >> sh ./mkhex rombios ../rombios/BIOS-bochs-latest> roms.h >> + sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin>> roms.h >> sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin>> roms.h >> sh ./mkhex vgabios_cirrusvga \ >> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin>> roms.h >> diff -r 494be76c1ad9 tools/firmware/hvmloader/hvmloader.c >> --- a/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 16:54:33 2009 +0800 >> +++ b/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 17:23:00 2009 +0800 >> @@ -688,9 +688,9 @@ int main(void) >> vgabios_sz = round_option_rom(sizeof(vgabios_stdvga)); >> break; >> case VGA_pt: >> - printf("Loading Gfx Video BIOS from 0xC0000 ...\n"); >> - vgabios_sz >> - round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512); >> + printf("Loading Gfx Video BIOS from file ...\n"); >> + memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt, >> sizeof(vgabios_pt)); >> + vgabios_sz = round_option_rom(sizeof(vgabios_pt)); >> break; >> default: >> printf("No emulated VGA adaptor ...\n"); >> >> </CODE> >> >> as intel-gfx-passthru-patch-3.patch and then I tried to apply the patch to xen 3.5-unstable. I got errors. I think it''s because the 3rd patch you provided is incomplete. >> >> Here''s my patching process: >> >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name vgabios >> ./tools/firmware/vgabios >> ./.hg/store/data/tools/firmware/vgabios >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cp ~enming/vgabios-pt.bin tools/firmware/vgabios/ >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ls tools/firmware/vgabios/ >> biossums.c clext.c Makefile TODO vbe.h vgabios.h vgatables.h >> BUGS COPYING Notes vbe.c vbetables-gen.c vgabios-pt.bin >> ChangeLog dataseghack README vbe_display_api.txt vgabios.c vgafonts.h >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# pwd >> /usr/src/xen-unstable.hg-vgapt >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wgethttp://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin >> --2009-08-28 23:18:21--http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin >> Resolving lists.xensource.com... 70.42.241.110 >> Connecting to lists.xensource.com|70.42.241.110|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 12565 (12K) [application/octet-stream] >> Saving to: `bincPiiAf0QWg.bin'' >> >> 100%[======================================================================>] 12,565 30.7K/s in 0.4s >> >> 2009-08-28 23:18:22 (30.7 KB/s) - `bincPiiAf0QWg.bin'' saved [12565/12565] >> >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv bincPiiAf0QWg.bin xen-gfx-passthrough.patch >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi xen-gfx-passthrough.patch >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch< xen-gfx-passthrough.patch >> can''t find file to patch at input line 4 >> Perhaps you should have used the -p or --strip option? >> The text leading up to this was: >> -------------------------- >> |diff -r 5d7e7a250267 tools/firmware/hvmloader/config.h >> |--- a/tools/firmware/hvmloader/config.h Wed Aug 26 18:28:44 2009 +0800 >> |+++ b/tools/firmware/hvmloader/config.h Thu Aug 27 16:54:24 2009 +0800 >> -------------------------- >> File to patch: ^C >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ex xen-gfx-passthrough.patch >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1< xen-gfx-passthrough.patch >> patching file tools/firmware/hvmloader/config.h >> patching file tools/firmware/hvmloader/hvmloader.c >> patching file tools/libxc/ia64/xc_ia64_hvm_build.c >> patching file tools/libxc/xc_hvm_build.c >> patching file tools/libxc/xc_linux.c >> patching file tools/libxc/xenctrl.h >> patching file tools/libxc/xenguest.h >> patching file tools/python/xen/lowlevel/xc/xc.c >> patching file tools/python/xen/xend/XendConfig.py >> Hunk #1 succeeded at 174 (offset -1 lines). >> patching file tools/python/xen/xend/image.py >> Hunk #1 succeeded at 780 (offset -6 lines). >> Hunk #3 succeeded at 895 (offset -6 lines). >> patching file tools/python/xen/xm/create.py >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wgethttp://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin >> --2009-08-28 23:21:35--http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin >> Resolving lists.xensource.com... 70.42.241.110 >> Connecting to lists.xensource.com|70.42.241.110|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 9841 (9.6K) [application/octet-stream] >> Saving to: `binglLqkeq4Rj.bin'' >> >> 100%[======================================================================>] 9,841 24.3K/s in 0.4s >> >> 2009-08-28 23:21:36 (24.3 KB/s) - `binglLqkeq4Rj.bin'' saved [9841/9841] >> >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv binglLqkeq4Rj.bin qemu-gfx-passthrough.patch >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi qemu-gfx-passthrough.patch >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name hw >> ./tools/ioemu-remote/hw >> ./.hg/store/data/tools/ioemu/hw >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv qemu-gfx-passthrough.patch tools/ioemu-remote/ >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cd tools/ioemu-remote/ >> [root@fedora11-x86-64-host ioemu-remote]# patch -p1< qemu- >> qemu-aio.h qemu-img.c qemu-sockets.c >> qemu-binfmt-conf.sh qemu-img.texi qemu-tech.texi >> qemu-char.c qemu-lock.h qemu-timer.h >> qemu-char.h qemu-log.h qemu-tool.c >> qemu-common.h qemu-malloc.c qemu-xen.h >> qemu-doc.texi qemu-nbd.c >> qemu-gfx-passthrough.patch qemu-nbd.texi >> [root@fedora11-x86-64-host ioemu-remote]# patch -p1< qemu-gfx-passthrough.patch >> patching file hw/pass-through.c >> patching file hw/pass-through.h >> patching file hw/pc.c >> patching file vl.c >> [root@fedora11-x86-64-host ioemu-remote]# cd .. >> [root@fedora11-x86-64-host tools]# cd .. >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi intel-gfx-passthru-patch-3.patch >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1< intel-gfx-passthru-patch-3.patch >> patching file tools/firmware/hvmloader/Makefile >> Hunk #1 FAILED at 50. >> 1 out of 1 hunk FAILED -- saving rejects to file tools/firmware/hvmloader/Makefile.rej >> patching file tools/firmware/hvmloader/hvmloader.c >> patch: **** malformed patch at line 24: sizeof(vgabios_pt)); >> >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi intel-gfx-passthru-patch-3.patch >> >> For everybody''s convenience, I have attached intel-gfx-passthru-patch-3.patch and the firmware for my nVidia GeForce 8400 GS PCI Express x16 graphics card in this email. >> >> Please help me complete intel-gfx-passthru-patch-3.patch as I really need it. >> >> Thank you very much!!! >> >> -- >> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >> Technical Support Engineer >> Information Technology Department >> Asiasoft Online Pte Ltd >> Tampines Central 1 #04-01 Tampines Plaza >> Singapore 529541 >> Republic of Singapore >> Mobile: +65-9648-9798 >> MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> >> Alma Maters: Singapore Polytechnic, National University of Singapore >> >> This patch supports basic gfx passthrough on QEMU: >> >> - disable emulated VGA adpater if there is passthroughed gfx >> >> - register/unregister legacy VGA I/O ports and MMIOs for passthroughed gfx >> >> >> >> Signed-off-by: Ben Lin<ben.y.lin@intel.com> <mailto:ben.y.lin@intel.com> >> >> Signed-off-by: Weidong Han<weidong.han@intel.com> <mailto:weidong.han@intel.com> >> >> No virus found in this incoming message. >> >> Checked by AVG -www.avg.com <http://www.avg.com> >> >> Version: 8.5.409 / Virus Database: 270.13.69/2328 - Release Date: 08/27/09 >> >> 18:02:00 >> >> >> >> No virus found in this outgoing message. >> >> Checked by AVG -www.avg.com <http://www.avg.com> >> >> Version: 8.5.409 / Virus Database: 270.13.71/2330 - Release Date: 08/27/09 >> >> 18:02:00 >> >> >> >> ------------------------------------------------------------------------ >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> Xen-devel mailing list >> >> Xen-devel@lists.xensource.com <mailto:Xen-devel@lists.xensource.com> >> >> http://lists.xensource.com/xen-devel >> >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> >> >> >> >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com <mailto:Xen-devel@lists.xensource.com> >> http://lists.xensource.com/xen-devel >> >> >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com <mailto: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 >_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mr. Teo En Ming (Zhang Enming)
2009-Aug-29 15:06 UTC
Re: [Xen-devel] graphics passthrough with VT-d
On 08/29/2009 10:39 PM, Mr. Teo En Ming (Zhang Enming) wrote:> Dear All, > > Here is my "xm dmesg" output: > > linux" > (XEN) elf_xen_parse_note: GUEST_VERSION = "2.6" > (XEN) elf_xen_parse_note: XEN_VERSION = "xen-3.0" > (XEN) elf_xen_parse_note: VIRT_BASE = 0xffffffff80000000 > (XEN) elf_xen_parse_note: ENTRY = 0xffffffff8166b200 > (XEN) elf_xen_parse_note: HYPERCALL_PAGE = 0xffffffff81009000 > (XEN) elf_xen_parse_note: FEATURES = "!writable_page_tables|pae_pgdir_above_4gb" > (XEN) elf_xen_parse_note: PAE_MODE = "yes" > (XEN) elf_xen_parse_note: LOADER = "generic" > (XEN) elf_xen_parse_note: unknown xen elf note (0xd) > (XEN) elf_xen_parse_note: SUSPEND_CANCEL = 0x1 > (XEN) elf_xen_parse_note: HV_START_LOW = 0xffff800000000000 > (XEN) elf_xen_parse_note: PADDR_OFFSET = 0x0 > (XEN) elf_xen_addr_calc_check: addresses: > (XEN) virt_base = 0xffffffff80000000 > (XEN) elf_paddr_offset = 0x0 > (XEN) virt_offset = 0xffffffff80000000 > (XEN) virt_kstart = 0xffffffff81000000 > (XEN) virt_kend = 0xffffffff81911000 > (XEN) virt_entry = 0xffffffff8166b200 > (XEN) p2m_base = 0xffffffffffffffff > (XEN) Xen kernel: 64-bit, lsb, compat32 > (XEN) Dom0 kernel: 64-bit, PAE, lsb, paddr 0x1000000 -> 0x1911000 > (XEN) PHYSICAL MEMORY ARRANGEMENT: > (XEN) Dom0 alloc.: 00000001f0000000->00000001f4000000 (1470696 pages to be allocated) > (XEN) VIRTUAL MEMORY ARRANGEMENT: > (XEN) Loaded kernel: ffffffff81000000->ffffffff81911000 > (XEN) Init. ramdisk: ffffffff81911000->ffffffff82085400 > (XEN) Phys-Mach map: ffffffff82086000->ffffffff82bde740 > (XEN) Start info: ffffffff82bdf000->ffffffff82bdf4b4 > (XEN) Page tables: ffffffff82be0000->ffffffff82bfb000 > (XEN) Boot stack: ffffffff82bfb000->ffffffff82bfc000 > (XEN) TOTAL: ffffffff80000000->ffffffff83000000 > (XEN) ENTRY ADDRESS: ffffffff8166b200 > (XEN) Dom0 has maximum 2 VCPUs > (XEN) elf_load_binary: phdr 0 at 0xffffffff81000000 -> 0xffffffff815bb000 > (XEN) elf_load_binary: phdr 1 at 0xffffffff815bb000 -> 0xffffffff8165efe0 > (XEN) elf_load_binary: phdr 2 at 0xffffffff8165f000 -> 0xffffffff8165f888 > (XEN) elf_load_binary: phdr 3 at 0xffffffff81660000 -> 0xffffffff8179c200 > (XEN) elf_load_binary: phdr 4 at 0xffffffff8179d000 -> 0xffffffff817b2c60 > (XEN) elf_load_binary: phdr 5 at 0xffffffff817b3000 -> 0xffffffff817b4000 > (XEN) Scrubbing Free RAM: .done. > (XEN) Xen trace buffers: disabled > (XEN) Std. Loglevel: All > (XEN) Guest Loglevel: All > (XEN) *** Serial input -> DOM0 (type \047CTRL-a\047 three times to switch input to Xen) > (XEN) Freed 128kB init memory. > (XEN) io_apic.c:2275: > (XEN) ioapic_guest_write: apic=0, pin=0, old_irq=-1, new_irq=0 > (XEN) ioapic_guest_write: old_entry=00010000, new_entry=00010900 > (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! > (XEN) io_apic.c:2275: > (XEN) ioapic_guest_write: apic=0, pin=1, old_irq=1, new_irq=0 > (XEN) ioapic_guest_write: old_entry=00000928, new_entry=00010900 > (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! > (XEN) io_apic.c:2275: > (XEN) ioapic_guest_write: apic=0, pin=2, old_irq=0, new_irq=0 > (XEN) ioapic_guest_write: old_entry=000009f0, new_entry=00010900 > (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! > (XEN) io_apic.c:2275: > (XEN) ioapic_guest_write: apic=0, pin=3, old_irq=3, new_irq=0 > (XEN) ioapic_guest_write: old_entry=00000930, new_entry=00010900 > (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! > (XEN) io_apic.c:2262: > (XEN) ioapic_guest_write: apic=0, pin=4, old_irq=4, new_irq=0 > (XEN) ioapic_guest_write: old_entry=000009f1, new_entry=00010900 > (XEN) ioapic_guest_write: Attempt to remove IO-APIC pin of in-use IRQ! > (XEN) io_apic.c:2275: > (XEN) ioapic_guest_write: apic=0, pin=5, old_irq=5, new_irq=0 > (XEN) ioapic_guest_write: old_entry=00000938, new_entry=00010900 > (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! > (XEN) io_apic.c:2275: > (XEN) ioapic_guest_write: apic=0, pin=6, old_irq=6, new_irq=0 > (XEN) ioapic_guest_write: old_entry=00000940, new_entry=00010900 > (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! > (XEN) io_apic.c:2275: > (XEN) ioapic_guest_write: apic=0, pin=7, old_irq=7, new_irq=0 > (XEN) ioapic_guest_write: old_entry=00000948, new_entry=00010900 > (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! > (XEN) io_apic.c:2275: > (XEN) ioapic_guest_write: apic=0, pin=8, old_irq=8, new_irq=0 > (XEN) ioapic_guest_write: old_entry=00000950, new_entry=00010900 > (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! > (XEN) io_apic.c:2275: > (XEN) ioapic_guest_write: apic=0, pin=9, old_irq=9, new_irq=0 > (XEN) ioapic_guest_write: old_entry=00018958, new_entry=00010900 > (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! > (XEN) io_apic.c:2275: > (XEN) ioapic_guest_write: apic=0, pin=10, old_irq=10, new_irq=0 > (XEN) ioapic_guest_write: old_entry=00000960, new_entry=00010900 > (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! > (XEN) io_apic.c:2275: > (XEN) ioapic_guest_write: apic=0, pin=11, old_irq=11, new_irq=0 > (XEN) ioapic_guest_write: old_entry=00000968, new_entry=00010900 > (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! > (XEN) io_apic.c:2275: > (XEN) ioapic_guest_write: apic=0, pin=12, old_irq=12, new_irq=0 > (XEN) ioapic_guest_write: old_entry=00000970, new_entry=00010900 > (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! > (XEN) io_apic.c:2275: > (XEN) ioapic_guest_write: apic=0, pin=13, old_irq=13, new_irq=0 > (XEN) ioapic_guest_write: old_entry=00000978, new_entry=00010900 > (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! > (XEN) io_apic.c:2275: > (XEN) ioapic_guest_write: apic=0, pin=14, old_irq=14, new_irq=0 > (XEN) ioapic_guest_write: old_entry=00000988, new_entry=00010900 > (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! > (XEN) io_apic.c:2275: > (XEN) ioapic_guest_write: apic=0, pin=15, old_irq=15, new_irq=0 > (XEN) ioapic_guest_write: old_entry=00000990, new_entry=00010900 > (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! > (XEN) io_apic.c:2275: > (XEN) ioapic_guest_write: apic=0, pin=16, old_irq=-1, new_irq=0 > (XEN) ioapic_guest_write: old_entry=00010000, new_entry=00010900 > (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! > (XEN) io_apic.c:2275: > (XEN) ioapic_guest_write: apic=0, pin=17, old_irq=-1, new_irq=0 > (XEN) ioapic_guest_write: old_entry=00010000, new_entry=00010900 > (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! > (XEN) io_apic.c:2275: > (XEN) ioapic_guest_write: apic=0, pin=18, old_irq=-1, new_irq=0 > (XEN) ioapic_guest_write: old_entry=00010000, new_entry=00010900 > (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! > (XEN) io_apic.c:2275: > (XEN) ioapic_guest_write: apic=0, pin=19, old_irq=-1, new_irq=0 > (XEN) ioapic_guest_write: old_entry=00010000, new_entry=00010900 > (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! > (XEN) io_apic.c:2275: > (XEN) ioapic_guest_write: apic=0, pin=20, old_irq=-1, new_irq=0 > (XEN) ioapic_guest_write: old_entry=00010000, new_entry=00010900 > (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! > (XEN) io_apic.c:2275: > (XEN) ioapic_guest_write: apic=0, pin=21, old_irq=-1, new_irq=0 > (XEN) ioapic_guest_write: old_entry=00010000, new_entry=00010900 > (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! > (XEN) io_apic.c:2275: > (XEN) ioapic_guest_write: apic=0, pin=22, old_irq=-1, new_irq=0 > (XEN) ioapic_guest_write: old_entry=00010000, new_entry=00010900 > (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! > (XEN) io_apic.c:2275: > (XEN) ioapic_guest_write: apic=0, pin=23, old_irq=-1, new_irq=0 > (XEN) ioapic_guest_write: old_entry=00010000, new_entry=00010900 > (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! > (XEN) io_apic.c:2275: > (XEN) ioapic_guest_write: apic=0, pin=0, old_irq=-1, new_irq=0 > (XEN) ioapic_guest_write: old_entry=00010000, new_entry=00000900 > (XEN) ioapic_guest_write: Attempt to add IO-APIC pin for in-use IRQ! > (XEN) io_apic.c:2275: > (XEN) ioapic_guest_write: apic=0, pin=4, old_irq=4, new_irq=4 > (XEN) ioapic_guest_write: old_entry=000009f1, new_entry=00000904 > (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! > (XEN) mce.c:694:d0 MCE: rdmsr MCG_CAP 0x806 > (XEN) mce.c:694:d0 MCE: rdmsr MCG_CAP 0x806 > (XEN) mce.c:694:d0 MCE: rdmsr MCG_CAP 0x806 > (XEN) mce.c:871:d0 MCE: wr MC1_STATUS 0 > (XEN) mce.c:871:d0 MCE: wr MC2_STATUS 0 > (XEN) mce.c:871:d0 MCE: wr MC3_STATUS 0 > (XEN) mce.c:871:d0 MCE: wr MC4_STATUS 0 > (XEN) mce.c:871:d0 MCE: wr MC5_STATUS 0 > (XEN) mce.c:694:d0 MCE: rdmsr MCG_CAP 0x806 > (XEN) mce.c:694:d0 MCE: rdmsr MCG_CAP 0x806 > (XEN) mce.c:694:d0 MCE: rdmsr MCG_CAP 0x806 > (XEN) mce.c:871:d0 MCE: wr MC1_STATUS 0 > (XEN) mce.c:871:d0 MCE: wr MC2_STATUS 0 > (XEN) mce.c:871:d0 MCE: wr MC3_STATUS 0 > (XEN) mce.c:871:d0 MCE: wr MC4_STATUS 0 > (XEN) mce.c:871:d0 MCE: wr MC5_STATUS 0 > (XEN) io_apic.c:2275: > (XEN) ioapic_guest_write: apic=0, pin=4, old_irq=4, new_irq=4 > (XEN) ioapic_guest_write: old_entry=000009f1, new_entry=00000904 > (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! > (XEN) io_apic.c:2275: > (XEN) ioapic_guest_write: apic=0, pin=19, old_irq=19, new_irq=19 > (XEN) ioapic_guest_write: old_entry=0000a9c8, new_entry=0001a913 > (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! > (XEN) io_apic.c:2275: > (XEN) ioapic_guest_write: apic=0, pin=18, old_irq=18, new_irq=18 > (XEN) ioapic_guest_write: old_entry=0000a9d0, new_entry=0001a912 > (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! > (XEN) io_apic.c:2275: > (XEN) ioapic_guest_write: apic=0, pin=23, old_irq=23, new_irq=23 > (XEN) ioapic_guest_write: old_entry=0000a9d8, new_entry=0001a917 > (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! > (XEN) io_apic.c:2275: > (XEN) ioapic_guest_write: apic=0, pin=19, old_irq=19, new_irq=19 > (XEN) ioapic_guest_write: old_entry=0000a9c8, new_entry=0001a913 > (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! > (XEN) io_apic.c:2275: > (XEN) ioapic_guest_write: apic=0, pin=18, old_irq=18, new_irq=18 > (XEN) ioapic_guest_write: old_entry=0000a9d0, new_entry=0001a912 > (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! > (XEN) io_apic.c:2275: > (XEN) ioapic_guest_write: apic=0, pin=18, old_irq=18, new_irq=18 > (XEN) ioapic_guest_write: old_entry=0000a9d0, new_entry=0001a912 > (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! > (XEN) io_apic.c:2275: > (XEN) ioapic_guest_write: apic=0, pin=18, old_irq=18, new_irq=18 > (XEN) ioapic_guest_write: old_entry=0000a9d0, new_entry=0001a912 > (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! > (XEN) io_apic.c:2275: > (XEN) ioapic_guest_write: apic=0, pin=16, old_irq=16, new_irq=16 > (XEN) ioapic_guest_write: old_entry=0000a9b8, new_entry=0001a910 > (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! > (XEN) io_apic.c:2275: > (XEN) ioapic_guest_write: apic=0, pin=22, old_irq=22, new_irq=22 > (XEN) ioapic_guest_write: old_entry=0000a931, new_entry=0001a916 > (XEN) ioapic_guest_write: Attempt to modify IO-APIC pin for in-use IRQ! > (XEN) [VT-D]iommu.c:1288:d0 domain_context_unmap:PCIe: bdf = 1:0.0 > (XEN) [VT-D]iommu.c:1174:d0 domain_context_mapping:PCIe: bdf = 1:0.0 > (XEN) domctl.c:887:d0 ioport_map:add f_gport=3b0 f_mport=3b0 np=c > (XEN) domctl.c:887:d0 ioport_map:add f_gport=3c0 f_mport=3c0 np=20 > (XEN) domctl.c:836:d0 memory_map:add: gfn=a0 mfn=a0 nr_mfns=20 > (XEN) [VT-D]io.c:284:d0 VT-d irq bind: m_irq = 1f device = 4 intx = 0 > (XEN) HVM1: HVM Loader > (XEN) HVM1: Detected Xen v3.5-unstable > (XEN) HVM1: CPU speed is 2800 MHz > (XEN) irq.c:243: Dom1 PCI link 0 changed 0 -> 5 > (XEN) HVM1: PCI-ISA link 0 routed to IRQ5 > (XEN) irq.c:243: Dom1 PCI link 1 changed 0 -> 10 > (XEN) HVM1: PCI-ISA link 1 routed to IRQ10 > (XEN) irq.c:243: Dom1 PCI link 2 changed 0 -> 11 > (XEN) HVM1: PCI-ISA link 2 routed to IRQ11 > (XEN) irq.c:243: Dom1 PCI link 3 changed 0 -> 5 > (XEN) HVM1: PCI-ISA link 3 routed to IRQ5 > (XEN) HVM1: pci dev 01:2 INTD->IRQ5 > (XEN) HVM1: pci dev 01:3 INTA->IRQ10 > (XEN) HVM1: pci dev 02:0 INTA->IRQ11 > (XEN) HVM1: pci dev 03:0 INTA->IRQ5 > (XEN) HVM1: pci dev 04:0 INTA->IRQ5 > (XEN) HVM1: pci dev 04:0 bar 14 size 10000000: e000000c > (XEN) domctl.c:836:d0 memory_map:add: gfn=e0000 mfn=c0000 nr_mfns=10000 > (XEN) domctl.c:836:d0 memory_map:add: gfn=f0000 mfn=d0000 nr_mfns=2000 > (XEN) HVM1: pci dev 04:0 bar 1c size 02000000: f0000004 > (XEN) HVM1: pci dev 02:0 bar 14 size 01000000: f2000008 > (XEN) domctl.c:836:d0 memory_map:add: gfn=f3000 mfn=d2000 nr_mfns=1000 > (XEN) HVM1: pci dev 04:0 bar 10 size 01000000: f3000000 > (XEN) HVM1: pci dev 04:0 bar 30 size 00020000: f4000000 > (XEN) HVM1: pci dev 02:0 bar 10 size 00000100: 0000c001 > (XEN) HVM1: pci dev 03:0 bar 10 size 00000100: 0000c101 > (XEN) HVM1: pci dev 03:0 bar 14 size 00000100: f4020000 > (XEN) HVM1: pci dev 04:0 bar 24 size 00000080: 0000c201 > (XEN) domctl.c:887:d0 ioport_map:add f_gport=c200 f_mport=d000 np=80 > (XEN) HVM1: pci dev 01:2 bar 20 size 00000020: 0000c281 > (XEN) HVM1: pci dev 01:1 bar 20 size 00000010: 0000c2a1 > (XEN) HVM1: Multiprocessor initialisation: > (XEN) HVM1: - CPU0 ... 36-bit phys ... fixed MTRRs ... var MTRRs [3/8] ... done. > (XEN) HVM1: Testing HVM environment: > (XEN) HVM1: - REP INSB across page boundaries ... passed > (XEN) HVM1: - GS base MSRs and SWAPGS ... passed > (XEN) HVM1: Passed 2 of 2 tests > (XEN) HVM1: Writing SMBIOS tables ... > (XEN) HVM1: Loading ROMBIOS ... > (XEN) HVM1: 11900 bytes of ROMBIOS high-memory extensions: > (XEN) HVM1: Relocating to 0xfc000000-0xfc002e7c ... done > (XEN) HVM1: Creating MP tables ... > (XEN) HVM1: Loading Gfx Video BIOS from file ... > (XEN) HVM1: Loading PCI Option ROM ... > (XEN) HVM1: - Manufacturer:http://etherboot.org > (XEN) HVM1: - Product name: gPXE > (XEN) HVM1: Loading ACPI ... > (XEN) HVM1: - Lo data: 000ea020-000ea04f > (XEN) HVM1: - Hi data: fc003000-fc0125cf > (XEN) HVM1: vm86 TSS at fc012800 > (XEN) HVM1: BIOS map: > (XEN) HVM1: c8000-d47ff: Etherboot ROM > (XEN) HVM1: eb000-eb14e: SMBIOS tables > (XEN) HVM1: f0000-fffff: Main BIOS > (XEN) HVM1: Invoking ROMBIOS ... > (XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $ > (XEN) HVM1: Bochs BIOS - build: 06/23/99 > (XEN) HVM1: $Revision: 1.221 $ $Date: 2008/12/07 17:32:29 $ > (XEN) HVM1: Options: apmbios pcibios eltorito PMM > (XEN) HVM1: > (XEN) HVM1: ata0-0: PCHS=16383/16/63 translation=lba LCHS=1024/255/63 > (XEN) HVM1: ata0 master: QEMU HARDDISK ATA-7 Hard-Disk (51200 MBytes) > (XEN) HVM1: IDE time out > (XEN) HVM1: ata1 master: QEMU DVD-ROM ATAPI-4 CD-Rom/DVD-Rom > (XEN) HVM1: IDE time out > (XEN) HVM1: > (XEN) HVM1: > (XEN) HVM1: > (XEN) HVM1: Press F12 for boot menu. > (XEN) HVM1: > (XEN) HVM1: Booting from Hard Disk... > (XEN) HVM1: Booting from 0000:7c00 > (XEN) HVM1: int13_harddisk: function 15, unmapped device for ELDL=81 > (XEN) HVM1: *** int 15h function AX=e980, BX=006e not yet supported! > (XEN) mce.c:694:d1 MCE: rdmsr MCG_CAP 0x806 > (XEN) mce.c:714:d1 MCE: rdmsr MC0_CTL 0xffffffffffffffff > (XEN) mce.c:694:d1 MCE: rdmsr MCG_CAP 0x806 > (XEN) irq.c:243: Dom1 PCI link 0 changed 5 -> 0 > (XEN) irq.c:243: Dom1 PCI link 1 changed 10 -> 0 > (XEN) irq.c:243: Dom1 PCI link 2 changed 11 -> 0 > (XEN) irq.c:243: Dom1 PCI link 3 changed 5 -> 0 > (XEN) domctl.c:846:d0 memory_map:remove: gfn=f3000 mfn=d2000 nr_mfns=1000 > (XEN) domctl.c:846:d0 memory_map:remove: gfn=e0000 mfn=c0000 nr_mfns=10000 > (XEN) domctl.c:846:d0 memory_map:remove: gfn=f0000 mfn=d0000 nr_mfns=2000 > (XEN) domctl.c:911:d0 ioport_map:remove f_gport=c200 f_mport=d000 np=80 > (XEN) domctl.c:836:d0 memory_map:add: gfn=f3000 mfn=d2000 nr_mfns=1000 > (XEN) domctl.c:836:d0 memory_map:add: gfn=e0000 mfn=c0000 nr_mfns=10000 > (XEN) domctl.c:836:d0 memory_map:add: gfn=f0000 mfn=d0000 nr_mfns=2000 > (XEN) domctl.c:887:d0 ioport_map:add f_gport=c200 f_mport=d000 np=80 > (XEN) domctl.c:846:d0 memory_map:remove: gfn=f3000 mfn=d2000 nr_mfns=1000 > (XEN) domctl.c:846:d0 memory_map:remove: gfn=e0000 mfn=c0000 nr_mfns=10000 > (XEN) domctl.c:846:d0 memory_map:remove: gfn=f0000 mfn=d0000 nr_mfns=2000 > (XEN) domctl.c:911:d0 ioport_map:remove f_gport=c200 f_mport=d000 np=80 > (XEN) domctl.c:836:d0 memory_map:add: gfn=f3000 mfn=d2000 nr_mfns=1000 > (XEN) domctl.c:836:d0 memory_map:add: gfn=e0000 mfn=c0000 nr_mfns=10000 > (XEN) domctl.c:836:d0 memory_map:add: gfn=f0000 mfn=d0000 nr_mfns=2000 > (XEN) domctl.c:887:d0 ioport_map:add f_gport=c200 f_mport=d000 np=80 > (XEN) mce.c:694:d0 MCE: rdmsr MCG_CAP 0x806 > (XEN) mce.c:694:d0 MCE: rdmsr MCG_CAP 0x806 > > -- > Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) > Technical Support Engineer > Information Technology Department > Asiasoft Online Pte Ltd > Tampines Central 1 #04-01 Tampines Plaza > Singapore 529541 > Republic of Singapore > Company Website:http://www.asiasoft.sg/ > Mobile: +65-9648-9798 > MSN:teoenming@hotmail.com > Alma Maters: Singapore Polytechnic, National University of Singapore > > On 08/29/2009 09:46 PM, Mr. Teo En Ming (Zhang Enming) wrote: >> Dear All, >> >> I have attached the patchset to xen-unstable and also the nvidia >> geforce 8400 gs firmware file here for your convenience. >> >> You can refer to the screenshots at my blog here: >> http://teo-en-ming-aka-zhang-enming.blogspot.com/2009/08/windows-xp-home-domu-test-results-after.html >> >> It shows that the emulated virtual VGA card is now disabled (not >> appearing in Windows XP Home DomU''s device manager) and only the >> nVidia Geforce 8400 GS VGA BIOS gets loaded. >> >> -- >> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >> Technical Support Engineer >> Information Technology Department >> Asiasoft Online Pte Ltd >> Tampines Central 1 #04-01 Tampines Plaza >> Singapore 529541 >> Republic of Singapore >> Company Website:http://www.asiasoft.sg/ >> Mobile: +65-9648-9798 >> MSN:teoenming@hotmail.com >> Alma Maters: Singapore Polytechnic, National University of Singapore >> >> >> On 08/29/2009 09:20 PM, Mr. Teo En Ming (Zhang Enming) wrote: >>> Dear All, >>> >>> I have applied the following patches to xen 3.5-unstable >>> >>> 1) intel-gfx-passthru-patch01.patch >>> 2) intel-gfx-passthru-patch02.patch >>> 3) intel-gfx-passthru-patch03.patch >>> 4) enming-patch04.patch >>> >>> and compiled xen 3.5-unstable successfully (both hypervisor and tools). >>> >>> i rebooted into this newly compiled Xen hypervisor which supports >>> loading vga bios from firmware file of nVidia Geforce 8400 GS PCI >>> Express x16. >>> >>> After dom0 has booted up, I executed the following script to hide >>> nVidia Geforce 8400 GS from dom0. >>> >>> [enming@fedora11-x86-64-host scripts]$ cat bind-devices-pci-stub.sh >>> #!/bin/sh >>> echo "10de 06e4" > /sys/bus/pci/drivers/pci-stub/new_id >>> echo "0000:01:00.0" > /sys/bus/pci/devices/0000:01:00.0/driver/unbind >>> echo "0000:01:00.0" > /sys/bus/pci/drivers/pci-stub/bind >>> >>> I also assigned the nVidia Geforce 8400 GS to my Windows XP Home HVM >>> domU. >>> >>> pci = [ ''01:00.0'' ] >>> >>> I also specified gfx_passthru=2. >>> >>> Do note that I booted up with onboard Intel GMA4500 as the primary >>> video adapter. Hence dom 0 has onboard graphics and Windows XP HVM >>> domU has nvidia graphics. >>> >>> Then I started Windows XP Home HVM DomU. >>> >>> Very soon, my Dom 0''s display was garbaged and X server on Dom 0 >>> totally froze and became unresponsive. I cannot switch to any ttys. >>> >>> However, I was still able to vnc into my Windows XP Home HVM Dom U. >>> I had earlier installed a VNC server into my Windows XP guest. After >>> remoting in to my Windows XP DomU through vnc, I found that NVIDIA >>> Geforce 8400 GS cannot be initialized and no resources are available >>> for this graphics card. >>> >>> -- >>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>> Technical Support Engineer >>> Information Technology Department >>> Asiasoft Online Pte Ltd >>> Tampines Central 1 #04-01 Tampines Plaza >>> Singapore 529541 >>> Republic of Singapore >>> Company Website:http://www.asiasoft.sg/ >>> Mobile: +65-9648-9798 >>> MSN:teoenming@hotmail.com >>> Alma Maters: Singapore Polytechnic, National University of Singapore >>> >>> >>> On 08/29/2009 08:25 PM, Mr. Teo En Ming (Zhang Enming) wrote: >>>> Hi All, >>>> >>>> I have solved the problem encountered below when building tools for >>>> xen 3.5-unstable. The compile problem exists because I downloaded >>>> and compiled the latest version of Intel ACPI Component >>>> Architecture compiler version 20090730. And I used this latest >>>> compiler during "make tools" for xen-unstable. >>>> >>>> In original xen-unstable source codes cloned from xensoure >>>> mercurial repository, the header files ssdt_pm.h and ssdt_tpm.h in >>>> source directory tools/firmware/hvmloader/acpi/ are generated by >>>> >>>> /* >>>> * >>>> * Intel ACPI Component Architecture >>>> * ASL Optimizing Compiler version 20061109 [May 18 2007] >>>> * Copyright (C) 2000 - 2006 Intel Corporation >>>> * Supports ACPI Specification Revision 3.0a >>>> * >>>> * Compilation of "ssdt_pm.asl" - Sun Oct 12 23:57:51 2008 >>>> * >>>> * C source code output >>>> * >>>> */ >>>> >>>> In original ssdt_pm.h, it has "unsigned char AmlCode_PM[] =". >>>> >>>> In original ssdt_tpm.h, it has "unsigned char AmlCode_TPM[] =". >>>> >>>> Hence there was no problem with "make tools". >>>> >>>> But, I downloaded, compiled and used >>>> >>>> /* >>>> * >>>> * Intel ACPI Component Architecture >>>> * ASL Optimizing Compiler version 20090730 [Aug 29 2009] >>>> * Copyright (C) 2000 - 2009 Intel Corporation >>>> * Supports ACPI Specification Revision 4.0 >>>> * >>>> * Compilation of "ssdt_pm.asl" - Sat Aug 29 18:55:40 2009 >>>> * >>>> * C source code output >>>> * >>>> */ >>>> >>>> So the *new* ssdt_pm.h contains: >>>> >>>> /* >>>> * >>>> * Intel ACPI Component Architecture >>>> * ASL Optimizing Compiler version 20090730 [Aug 29 2009] >>>> * Copyright (C) 2000 - 2009 Intel Corporation >>>> * Supports ACPI Specification Revision 4.0 >>>> * >>>> * Compilation of "ssdt_pm.asl" - Sat Aug 29 18:55:40 2009 >>>> * >>>> * C source code output >>>> * >>>> */ >>>> unsigned char AmlCode[] >>>> { >>>> 0x53,0x53,0x44,0x54,0xD6,0x05,0x00,0x00, /* 00000000 >>>> "SSDT...." */ >>>> 0x02,0xB9,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008 >>>> "..Xen..." */ >>>> 0x48,0x56,0x4D,0x00,0x00,0x00,0x00,0x00, /* 00000010 >>>> "HVM....." */ >>>> 0x00,0x00,0x00,0x00,0x49,0x4E,0x54,0x4C, /* 00000018 >>>> "....INTL" */ >>>> 0x30,0x07,0x09,0x20,0x10,0x41,0x5B,0x5C, /* 00000020 "0.. >>>> .A[\" */ >>>> 0x5F,0x53,0x42,0x5F,0x5B,0x80,0x44,0x42, /* 00000028 >>>> "_SB_[.DB" */ >>>> 0x47,0x41,0x01,0x0B,0x40,0xB0,0x01,0x5B, /* 00000030 "GA..@..[" */ >>>> 0x81,0x0B,0x44,0x42,0x47,0x41,0x01,0x44, /* 00000038 >>>> "..DBGA.D" */ >>>> 0x42,0x47,0x31,0x08,0x5B,0x80,0x44,0x42, /* 00000040 >>>> "BG1.[.DB" */ >>>> 0x47,0x42,0x01,0x0B,0x44,0xB0,0x01,0x5B, /* 00000048 >>>> "GB..D..[" */ >>>> 0x81,0x0B,0x44,0x42,0x47,0x42,0x01,0x44, /* 00000050 >>>> "..DBGB.D" */ >>>> 0x42,0x47,0x32,0x08,0x5B,0x80,0x44,0x42, /* 00000058 >>>> "BG2.[.DB" */ >>>> 0x47,0x43,0x01,0x0B,0x46,0xB0,0x01,0x5B, /* 00000060 >>>> "GC..F..[" */ >>>> 0x81,0x0B,0x44,0x42,0x47,0x43,0x01,0x44, /* 00000068 >>>> "..DBGC.D" */ >>>> 0x42,0x47,0x33,0x08,0x5B,0x80,0x44,0x42, /* 00000070 >>>> "BG3.[.DB" */ >>>> 0x47,0x44,0x01,0x0B,0x48,0xB0,0x01,0x5B, /* 00000078 >>>> "GD..H..[" */ >>>> 0x81,0x0B,0x44,0x42,0x47,0x44,0x01,0x44, /* 00000080 >>>> "..DBGD.D" */ >>>> 0x42,0x47,0x34,0x08,0x5B,0x80,0x50,0x52, /* 00000088 >>>> "BG4.[.PR" */ >>>> 0x54,0x31,0x01,0x0A,0xB2,0x0A,0x02,0x5B, /* 00000090 >>>> "T1.....[" */ >>>> 0x81,0x10,0x50,0x52,0x54,0x31,0x01,0x50, /* 00000098 >>>> "..PRT1.P" */ >>>> 0x42,0x32,0x5F,0x08,0x50,0x42,0x32,0x41, /* 000000A0 >>>> "B2_.PB2A" */ >>>> 0x08,0x5B,0x80,0x50,0x52,0x54,0x32,0x01, /* 000000A8 >>>> ".[.PRT2." */ >>>> 0x0A,0x86,0x01,0x5B,0x81,0x0B,0x50,0x52, /* 000000B0 >>>> "...[..PR" */ >>>> 0x54,0x32,0x01,0x50,0x38,0x36,0x5F,0x08, /* 000000B8 >>>> "T2.P86_." */ >>>> 0x5B,0x80,0x50,0x52,0x54,0x33,0x01,0x0A, /* 000000C0 >>>> "[.PRT3.." */ >>>> 0x88,0x01,0x5B,0x81,0x0B,0x50,0x52,0x54, /* 000000C8 >>>> "..[..PRT" */ >>>> 0x33,0x01,0x50,0x38,0x38,0x5F,0x08,0x5B, /* 000000D0 >>>> "3.P88_.[" */ >>>> 0x01,0x53,0x59,0x4E,0x43,0x01,0x08,0x42, /* 000000D8 >>>> ".SYNC..B" */ >>>> 0x55,0x46,0x30,0x11,0x04,0x0B,0x00,0x01, /* 000000E0 >>>> "UF0....." */ >>>> 0x08,0x42,0x55,0x46,0x31,0x11,0x03,0x0A, /* 000000E8 >>>> ".BUF1..." */ >>>> 0x08,0x8B,0x42,0x55,0x46,0x31,0x00,0x42, /* 000000F0 >>>> "..BUF1.B" */ >>>> 0x55,0x46,0x41,0x8B,0x42,0x55,0x46,0x31, /* 000000F8 >>>> "UFA.BUF1" */ >>>> 0x0A,0x04,0x42,0x55,0x46,0x42,0x14,0x14, /* 00000100 >>>> "..BUFB.." */ >>>> >>>> And the *new* ssdt_tpm.h contains: >>>> >>>> /* >>>> * >>>> * Intel ACPI Component Architecture >>>> * ASL Optimizing Compiler version 20090730 [Aug 29 2009] >>>> * Copyright (C) 2000 - 2009 Intel Corporation >>>> * Supports ACPI Specification Revision 4.0 >>>> * >>>> * Compilation of "ssdt_tpm.asl" - Sat Aug 29 18:55:40 2009 >>>> * >>>> * C source code output >>>> * >>>> */ >>>> unsigned char AmlCode[] >>>> { >>>> 0x53,0x53,0x44,0x54,0x4C,0x00,0x00,0x00, /* 00000000 >>>> "SSDTL..." */ >>>> 0x02,0x2A,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008 >>>> ".*Xen..." */ >>>> 0x48,0x56,0x4D,0x00,0x00,0x00,0x00,0x00, /* 00000010 >>>> "HVM....." */ >>>> 0x00,0x00,0x00,0x00,0x49,0x4E,0x54,0x4C, /* 00000018 >>>> "....INTL" */ >>>> 0x30,0x07,0x09,0x20,0x5B,0x82,0x26,0x54, /* 00000020 "0.. >>>> [.&T" */ >>>> 0x50,0x4D,0x5F,0x08,0x5F,0x48,0x49,0x44, /* 00000028 >>>> "PM_._HID" */ >>>> 0x0C,0x41,0xD0,0x0C,0x31,0x08,0x5F,0x43, /* 00000030 >>>> ".A..1._C" */ >>>> 0x52,0x53,0x11,0x11,0x0A,0x0E,0x86,0x09, /* 00000038 >>>> "RS......" */ >>>> 0x00,0x01,0x00,0x00,0xD4,0xFE,0x00,0x50, /* 00000040 >>>> ".......P" */ >>>> 0x00,0x00,0x79,0x00, >>>> }; >>>> >>>> which are both wrong. >>>> >>>> In ssdt_pm.h, I have to change "unsigned char AmlCode[]" to >>>> "unsigned char AmlCode_PM[]". >>>> >>>> In ssdt_tpm.h, I have to change "unsigned char AmlCode[]" to >>>> "unsigned char AmlCode_TPM[]". >>>> >>>> Then "make tools" is able to complete successfully. >>>> >>>> I have created a patch for anybody who may be using the *latest* >>>> version of Intel ACPI CA compiler version 20090730 and attached it >>>> here. >>>> >>>> Patch file filename enming-patch04.patch: >>>> >>>> <CODE> >>>> >>>> Patch created by Teo En Ming (Zhang Enming) on 29 August 2009 >>>> Saturday at 8:00 P.M. Singapore Time >>>> Email #1: enming.teo@asiasoftsea.net >>>> Email #2: space.time.universe@gmail.com >>>> MSN: teoenming@hotmail.com >>>> Mobile Phone: +65-9648-9798 >>>> >>>> --- ssdt_pm.h 2009-08-29 19:54:52.653088000 +0800 >>>> +++ ssdt_pm.h 2009-08-29 19:56:51.813088550 +0800 >>>> @@ -10,7 +10,7 @@ >>>> * C source code output >>>> * >>>> */ >>>> -unsigned char AmlCode[] >>>> +unsigned char AmlCode_PM[] >>>> { >>>> 0x53,0x53,0x44,0x54,0xD6,0x05,0x00,0x00, /* 00000000 >>>> "SSDT...." */ >>>> 0x02,0xB9,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008 >>>> "..Xen..." */ >>>> --- ssdt_tpm.h 2009-08-29 19:55:44.578738954 +0800 >>>> +++ ssdt_tpm.h 2009-08-29 19:57:27.896638884 +0800 >>>> @@ -10,7 +10,7 @@ >>>> * C source code output >>>> * >>>> */ >>>> -unsigned char AmlCode[] >>>> +unsigned char AmlCode_TPM[] >>>> { >>>> 0x53,0x53,0x44,0x54,0x4C,0x00,0x00,0x00, /* 00000000 >>>> "SSDTL..." */ >>>> 0x02,0x2A,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008 >>>> ".*Xen..." */ >>>> >>>> </CODE> >>>> >>>> -- >>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>>> Technical Support Engineer >>>> Information Technology Department >>>> Asiasoft Online Pte Ltd >>>> Tampines Central 1 #04-01 Tampines Plaza >>>> Singapore 529541 >>>> Republic of Singapore >>>> Company Website:http://www.asiasoft.sg/ >>>> Mobile: +65-9648-9798 >>>> MSN:teoenming@hotmail.com >>>> Alma Maters: Singapore Polytechnic, National University of Singapore >>>> >>>> >>>> On 08/29/2009 07:03 PM, Mr. Teo En Ming (Zhang Enming) wrote: >>>>> Hi, >>>>> >>>>> I clonedhttp://xenbits.xensource.com/xen-unstable.hg again today. I tried applying the three Intel gfx passthrough patches to xen-unstable. When I "make tools", I get the same error again: >>>>> >>>>> make[7]: Entering directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader'' >>>>> make -C acpi all >>>>> get-path: will use #!/usr/bin/python2.6 for python programs >>>>> make[8]: Entering directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' >>>>> make iasl >>>>> get-path: will use #!/usr/bin/python2.6 for python programs >>>>> make[9]: Entering directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' >>>>> make[9]: `/usr/local/bin/iasl'' is up to date. >>>>> make[9]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' >>>>> iasl -tc ssdt_tpm.asl >>>>> >>>>> Intel ACPI Component Architecture >>>>> ASL Optimizing Compiler version 20090730 [Aug 29 2009] >>>>> Copyright (C) 2000 - 2009 Intel Corporation >>>>> Supports ACPI Specification Revision 4.0 >>>>> >>>>> ASL Input: ssdt_tpm.asl - 31 lines, 1111 bytes, 3 keywords >>>>> AML Output: SSDT_TPM.aml - 76 bytes, 3 named objects, 0 executable opcodes >>>>> >>>>> Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 0 Optimizations >>>>> mv ssdt_tpm.hex ssdt_tpm.h >>>>> rm -f *.aml >>>>> make iasl >>>>> get-path: will use #!/usr/bin/python2.6 for python programs >>>>> make[9]: Entering directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' >>>>> make[9]: `/usr/local/bin/iasl'' is up to date. >>>>> make[9]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' >>>>> iasl -tc ssdt_pm.asl >>>>> >>>>> Intel ACPI Component Architecture >>>>> ASL Optimizing Compiler version 20090730 [Aug 29 2009] >>>>> Copyright (C) 2000 - 2009 Intel Corporation >>>>> Supports ACPI Specification Revision 4.0 >>>>> >>>>> ASL Input: ssdt_pm.asl - 425 lines, 12754 bytes, 192 keywords >>>>> AML Output: SSDT_PM.aml - 1494 bytes, 64 named objects, 128 executable opcodes >>>>> >>>>> Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 31 Optimizations >>>>> mv ssdt_pm.hex ssdt_pm.h >>>>> rm -f *.aml >>>>> gcc -O1 -fno-omit-frame-pointer -fno-optimize-sibling-calls -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .build.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs -Werror -fno-stack-protector -fno-builtin -msoft-float -I. -I.. -I../../../../tools/include -c -o build.o build.c >>>>> In file included from build.c:21: >>>>> ssdt_pm.h:13: error: redefinition of ''AmlCode'' >>>>> ssdt_tpm.h:13: note: previous definition of ''AmlCode'' was here >>>>> build.c: In function ''construct_secondary_tables'': >>>>> build.c:184: error: ''AmlCode_PM'' undeclared (first use in this function) >>>>> build.c:184: error: (Each undeclared identifier is reported only once >>>>> build.c:184: error: for each function it appears in.) >>>>> build.c:194: error: ''AmlCode_TPM'' undeclared (first use in this function) >>>>> make[8]: *** [build.o] Error 1 >>>>> make[8]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' >>>>> make[7]: *** [subdir-all-acpi] Error 2 >>>>> make[7]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader'' >>>>> make[6]: *** [subdirs-all] Error 2 >>>>> make[6]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader'' >>>>> make[5]: *** [subdir-all-hvmloader] Error 2 >>>>> make[5]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware'' >>>>> make[4]: *** [subdirs-all] Error 2 >>>>> make[4]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware'' >>>>> make[3]: *** [all] Error 2 >>>>> make[3]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware'' >>>>> make[2]: *** [subdir-install-firmware] Error 2 >>>>> make[2]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools'' >>>>> make[1]: *** [subdirs-install] Error 2 >>>>> make[1]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools'' >>>>> make: *** [install-tools] Error 2 >>>>> >>>>> Any ideas about this Advanced Configuration and Power Interface code? >>>>> >>>>> -- >>>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>>>> Technical Support Engineer >>>>> Information Technology Department >>>>> Asiasoft Online Pte Ltd >>>>> Tampines Central 1 #04-01 Tampines Plaza >>>>> Singapore 529541 >>>>> Republic of Singapore >>>>> Company Website:http://www.asiasoft.sg/ >>>>> Mobile: +65-9648-9798 >>>>> MSN:teoenming@hotmail.com >>>>> Alma Maters: Singapore Polytechnic, National University of Singapore >>>>> >>>>> >>>>> On 08/29/2009 02:58 PM, Mr. Teo En Ming (Zhang Enming) wrote: >>>>>> Hi >>>>>> >>>>>> Anybody available today? I know it''s Saturday. :-) >>>>>> >>>>>> -- >>>>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>>>>> Technical Support Engineer >>>>>> Information Technology Department >>>>>> Asiasoft Online Pte Ltd >>>>>> Tampines Central 1 #04-01 Tampines Plaza >>>>>> Singapore 529541 >>>>>> Republic of Singapore >>>>>> Company Website:http://www.asiasoft.sg/ >>>>>> Mobile: +65-9648-9798 >>>>>> MSN:teoenming@hotmail.com >>>>>> Alma Maters: Singapore Polytechnic, National University of Singapore >>>>>> >>>>>> >>>>>> On 08/29/2009 11:48 AM, Mr. Teo En Ming (Zhang Enming) wrote: >>>>>>> >>>>>>> Dear All, >>>>>>> >>>>>>> After applying Intel VGA passthrough patches 1, 2 and 3, I have no problems with "make xen", and "make install-xen". However, I have errors with "make tools". >>>>>>> >>>>>>> Here is the error output: >>>>>>> >>>>>>> msoft-float -I. -I.. -I../../../../tools/include -c -o build.o build.c >>>>>>> build.c: In function ''construct_secondary_tables'': >>>>>>> build.c:194: error: ''AmlCode_TPM'' undeclared (first use in this function) >>>>>>> build.c:194: error: (Each undeclared identifier is reported only once >>>>>>> build.c:194: error: for each function it appears in.) >>>>>>> make[8]: *** [build.o] Error 1 >>>>>>> make[8]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader/acpi'' >>>>>>> make[7]: *** [subdir-all-acpi] Error 2 >>>>>>> make[7]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader'' >>>>>>> make[6]: *** [subdirs-all] Error 2 >>>>>>> make[6]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader'' >>>>>>> make[5]: *** [subdir-all-hvmloader] Error 2 >>>>>>> make[5]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'' >>>>>>> make[4]: *** [subdirs-all] Error 2 >>>>>>> make[4]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'' >>>>>>> make[3]: *** [all] Error 2 >>>>>>> make[3]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'' >>>>>>> make[2]: *** [subdir-install-firmware] Error 2 >>>>>>> make[2]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools'' >>>>>>> make[1]: *** [subdirs-install] Error 2 >>>>>>> make[1]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools'' >>>>>>> make: *** [install-tools] Error 2 >>>>>>> >>>>>>> There is an undeclared identifier in tools/firmware/hvmloader/acpi/build.c source code. Could you guys help me resolve this issue? >>>>>>> >>>>>>> I had no problems compiling xen 3.5-unstable before applying the Intel vga passthrough patches and before installing the Intel ACPI Component Architecture compiler. >>>>>>> >>>>>>> I have also attached Intel graphics passthrough patches 1, 2 and 3 for your convenience here. >>>>>>> >>>>>>> Thank you very much. >>>>>>> >>>>>>> Hope I can get this working during the weekends. >>>>>>> >>>>>>> -- >>>>>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>>>>>> Technical Support Engineer >>>>>>> Information Technology Department >>>>>>> Asiasoft Online Pte Ltd >>>>>>> Tampines Central 1 #04-01 Tampines Plaza >>>>>>> Singapore 529541 >>>>>>> Republic of Singapore >>>>>>> Company Website:http://www.asiasoft.sg/ >>>>>>> Mobile: +65-9648-9798 >>>>>>> MSN:teoenming@hotmail.com >>>>>>> Alma Maters: Singapore Polytechnic, National University of Singapore >>>>>>> >>>>>>> >>>>>>> On 08/29/2009 10:17 AM, Mr. Teo En Ming (Zhang Enming) wrote: >>>>>>>> Hi Tim, >>>>>>>> >>>>>>>> I thought it should be gfx_passthru=2 in domU config? >>>>>>>> -- >>>>>>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>>>>>>> Technical Support Engineer >>>>>>>> Information Technology Department >>>>>>>> Asiasoft Online Pte Ltd >>>>>>>> Tampines Central 1 #04-01 Tampines Plaza >>>>>>>> Singapore 529541 >>>>>>>> Republic of Singapore >>>>>>>> Mobile: +65-9648-9798 >>>>>>>> MSN:teoenming@hotmail.com >>>>>>>> Alma Maters: Singapore Polytechnic, National University of Singapore >>>>>>>> >>>>>>>> >>>>>>>> On 08/29/2009 06:42 AM, Tim Moore wrote: >>>>>>>>> >>>>>>>>> Teo, >>>>>>>>> >>>>>>>>> I have also performed the same exercise as yourself and I now >>>>>>>>> have successfully compiled all 3x patches into Xen, Qemu and >>>>>>>>> the BIOS File Loading in the hvmloader, this all compiles find >>>>>>>>> on my system. Suggest you do a "make clean" on the tools and >>>>>>>>> start again ! >>>>>>>>> >>>>>>>>> After booting with the patched xen-unstable and adding the >>>>>>>>> gfx-passthru=1 parameter to my HVM DomU, as I suspected - it >>>>>>>>> still doesn''t work. >>>>>>>>> >>>>>>>>> I have both a 9500GT and GTX260(primary) in my Intel DX58SO >>>>>>>>> machine, tried passing through either device and my primary >>>>>>>>> display locks up ! (included hiding with pci-stub) >>>>>>>>> >>>>>>>>> I verified that the DomU was functional beforehand, as It also >>>>>>>>> booted successfully without the gfx-passthru parameter (and a >>>>>>>>> vncviewer/cirrus display) >>>>>>>>> >>>>>>>>> Unfortunately, I can''t debug further as my Primary display >>>>>>>>> corrupts as soon as the DomU starts. I did notice that in "xm >>>>>>>>> debug" the "Loading Gfx BIOS File.." message was displayed and >>>>>>>>> the DomU did continue to initialise the BIOS tables and such >>>>>>>>> before finally locking. I then (blindly) typed on a corrupt >>>>>>>>> Dom0 console and managed to start kdm and login, so the Dom0 >>>>>>>>> was not completely trashed. But then after a few minutes, the >>>>>>>>> machine totally froze and had to hit the reset switch. >>>>>>>>> >>>>>>>>> I`m no specialist but this looks like the VGA BIOS >>>>>>>>> Re-initialisation is playing havoc with the DomU and possibly >>>>>>>>> the Dom0 graphics. I notice that both are also using IRQ11 >>>>>>>>> which could play a major part. Furthermore, there was a lot of >>>>>>>>> debug output in the qemu and xend.log indicating Base Address >>>>>>>>> Register invalid access and therefore it seems there may be a >>>>>>>>> second obstacle. >>>>>>>>> >>>>>>>>> Hope you have a better success than me ! >>>>>>>>> >>>>>>>>> For now, I would try re-compiling a fresh xen-unstable with >>>>>>>>> carefully applied patches .. oh! and don''t forget to enable >>>>>>>>> the pci-stub driver for Dom0 (it''s not selected by default) >>>>>>>>> >>>>>>>>> Tim >>>>>>>>> >>>>>>>>> *From:* xen-devel-bounces@lists.xensource.com >>>>>>>>> [mailto:xen-devel-bounces@lists.xensource.com] *On Behalf Of >>>>>>>>> *Mr. Teo En Ming (Zhang Enming) >>>>>>>>> *Sent:* 28 August 2009 21:14 >>>>>>>>> *To:* enming.teo@asiasoftsea.net >>>>>>>>> *Cc:* xen-devel@lists.xensource.com; ''Lin, Ben Y''; ''Kay, Allen >>>>>>>>> M''; ''Jean Guyader''; Keir.Fraser@eu.citrix.com; >>>>>>>>> weidong.han@intel.com; bengheng@eecs.umich.edu >>>>>>>>> *Subject:* Re: [Xen-devel] [PATCH 2/2] graphics passthrough >>>>>>>>> with VT-d >>>>>>>>> >>>>>>>>> After applying the 1st and 2nd patch to xen-unstable successfully, I examined the source codes Makefile and hvmloader.c in tools/firmware/hvmloader, compared them to Weidong''s 3rd patch and I generated my own 3rd patch. Then I used my own generated 3rd patch to apply patching for loading vga bios from firmware file. >>>>>>>>> >>>>>>>>> Here is my own generated 3rd patch instead of using Weidong''s 3rd patch: >>>>>>>>> >>>>>>>>> --- Makefile 2009-08-29 03:24:52.413083774 +0800 >>>>>>>>> +++ Makefile 2009-08-29 03:29:12.763299633 +0800 >>>>>>>>> @@ -50,6 +50,7 @@ >>>>>>>>> roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \ >>>>>>>>> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h >>>>>>>>> sh ./mkhex rombios ../rombios/BIOS-bochs-latest> roms.h >>>>>>>>> + sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin>> roms.h >>>>>>>>> sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin>> roms.h >>>>>>>>> sh ./mkhex vgabios_cirrusvga \ >>>>>>>>> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin>> roms.h >>>>>>>>> --- hvmloader.c 2009-08-29 03:26:06.911085797 +0800 >>>>>>>>> +++ hvmloader.c 2009-08-29 03:31:43.172084995 +0800 >>>>>>>>> @@ -688,9 +688,9 @@ >>>>>>>>> vgabios_sz = round_option_rom(sizeof(vgabios_stdvga)); >>>>>>>>> break; >>>>>>>>> case VGA_pt: >>>>>>>>> - printf("Loading VGABIOS of passthroughed gfx ...\n"); >>>>>>>>> - vgabios_sz >>>>>>>>> - round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512); >>>>>>>>> + printf("Loading Gfx Video BIOS from file ...\n"); >>>>>>>>> + memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt, sizeof(vgabios_pt)); >>>>>>>>> + vgabios_sz = round_option_rom(sizeof(vgabios_pt)); >>>>>>>>> break; >>>>>>>>> default: >>>>>>>>> printf("No emulated VGA adaptor ...\n"); >>>>>>>>> >>>>>>>>> >>>>>>>>> I can "make xen" successfully but when I proceeded to "make tools", errors were encountered. >>>>>>>>> >>>>>>>>> Please see attached error output. How can I solve this problem? >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>>>>>>>> Technical Support Engineer >>>>>>>>> Information Technology Department >>>>>>>>> Asiasoft Online Pte Ltd >>>>>>>>> Tampines Central 1 #04-01 Tampines Plaza >>>>>>>>> Singapore 529541 >>>>>>>>> Republic of Singapore >>>>>>>>> Mobile: +65-9648-9798 >>>>>>>>> MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> >>>>>>>>> Alma Maters: Singapore Polytechnic, National University of Singapore >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 08/29/2009 12:59 AM, Mr. Teo En Ming (Zhang Enming) wrote: >>>>>>>>> >>>>>>>>> OK I believe the 3rd patch is not incomplete but there''s a white space issue when I copied the code from the mailing list into my vi. >>>>>>>>> >>>>>>>>> Seehttp://www.htdig.org/mail/2000/11/0167.html >>>>>>>>> >>>>>>>>> When I used the -l flag to patch using the 3rd patch, the number of errors was reduced. >>>>>>>>> >>>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -l -p1< intel-gfx-passthru-patch-3.patch >>>>>>>>> patching file tools/firmware/hvmloader/Makefile >>>>>>>>> patching file tools/firmware/hvmloader/hvmloader.c >>>>>>>>> Hunk #1 FAILED at 688. >>>>>>>>> 1 out of 1 hunk FAILED -- saving rejects to file tools/firmware/hvmloader/hvmloader.c.rej >>>>>>>>> >>>>>>>>> Now patching tools/firmware/hvmloader/Makefile is successful but patching tools/firmware/hvmloader/hvmloader.c still failed. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>>>>>>>> Technical Support Engineer >>>>>>>>> Information Technology Department >>>>>>>>> Asiasoft Online Pte Ltd >>>>>>>>> Tampines Central 1 #04-01 Tampines Plaza >>>>>>>>> Singapore 529541 >>>>>>>>> Republic of Singapore >>>>>>>>> Mobile: +65-9648-9798 >>>>>>>>> MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> >>>>>>>>> Alma Maters: Singapore Polytechnic, National University of Singapore >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On 08/28/2009 11:55 PM, Mr. Teo En Ming (Zhang Enming) wrote: >>>>>>>>> >>>>>>>>> Dear Weidong, >>>>>>>>> >>>>>>>>> A big big thanks for the vga passthrough patches for xen >>>>>>>>> 3.5-unstable!!! These are eagerly anticipated patches. As I >>>>>>>>> did not study computer science and computer architecture, I >>>>>>>>> won''t be able to write those patches you guys at Intel wrote. >>>>>>>>> >>>>>>>>> I applied the following patches *xen-gfx-passthrough.patch >>>>>>>>> <http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin> >>>>>>>>> and qemu-gfx-passthrough.patch >>>>>>>>> <http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin> >>>>>>>>> to xen 3.5-unstable without issues.* >>>>>>>>> >>>>>>>>> Then I tried to apply the 3rd patch you provided at >>>>>>>>> http://lists.xensource.com/archives/html/xen-devel/2009-08/msg01047.html >>>>>>>>> >>>>>>>>> I saved the following code >>>>>>>>> >>>>>>>>> <CODE> >>>>>>>>> >>>>>>>>> diff -r 494be76c1ad9 tools/firmware/hvmloader/Makefile >>>>>>>>> --- a/tools/firmware/hvmloader/Makefile Thu Aug 27 16:54:33 2009 +0800 >>>>>>>>> +++ b/tools/firmware/hvmloader/Makefile Thu Aug 27 17:22:01 2009 +0800 >>>>>>>>> @@ -50,6 +50,7 @@ roms.h: ../rombios/BIOS-bochs-latest ../ >>>>>>>>> roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \ >>>>>>>>> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h >>>>>>>>> sh ./mkhex rombios ../rombios/BIOS-bochs-latest> roms.h >>>>>>>>> + sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin>> roms.h >>>>>>>>> sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin>> roms.h >>>>>>>>> sh ./mkhex vgabios_cirrusvga \ >>>>>>>>> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin>> roms.h >>>>>>>>> diff -r 494be76c1ad9 tools/firmware/hvmloader/hvmloader.c >>>>>>>>> --- a/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 16:54:33 2009 +0800 >>>>>>>>> +++ b/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 17:23:00 2009 +0800 >>>>>>>>> @@ -688,9 +688,9 @@ int main(void) >>>>>>>>> vgabios_sz = round_option_rom(sizeof(vgabios_stdvga)); >>>>>>>>> break; >>>>>>>>> case VGA_pt: >>>>>>>>> - printf("Loading Gfx Video BIOS from 0xC0000 ...\n"); >>>>>>>>> - vgabios_sz >>>>>>>>> - round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512); >>>>>>>>> + printf("Loading Gfx Video BIOS from file ...\n"); >>>>>>>>> + memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt, >>>>>>>>> sizeof(vgabios_pt)); >>>>>>>>> + vgabios_sz = round_option_rom(sizeof(vgabios_pt)); >>>>>>>>> break; >>>>>>>>> default: >>>>>>>>> printf("No emulated VGA adaptor ...\n"); >>>>>>>>> >>>>>>>>> </CODE> >>>>>>>>> >>>>>>>>> as intel-gfx-passthru-patch-3.patch and then I tried to apply the patch to xen 3.5-unstable. I got errors. I think it''s because the 3rd patch you provided is incomplete. >>>>>>>>> >>>>>>>>> Here''s my patching process: >>>>>>>>> >>>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name vgabios >>>>>>>>> ./tools/firmware/vgabios >>>>>>>>> ./.hg/store/data/tools/firmware/vgabios >>>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cp ~enming/vgabios-pt.bin tools/firmware/vgabios/ >>>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ls tools/firmware/vgabios/ >>>>>>>>> biossums.c clext.c Makefile TODO vbe.h vgabios.h vgatables.h >>>>>>>>> BUGS COPYING Notes vbe.c vbetables-gen.c vgabios-pt.bin >>>>>>>>> ChangeLog dataseghack README vbe_display_api.txt vgabios.c vgafonts.h >>>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# pwd >>>>>>>>> /usr/src/xen-unstable.hg-vgapt >>>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wgethttp://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin >>>>>>>>> --2009-08-28 23:18:21--http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin >>>>>>>>> Resolving lists.xensource.com... 70.42.241.110 >>>>>>>>> Connecting to lists.xensource.com|70.42.241.110|:80... connected. >>>>>>>>> HTTP request sent, awaiting response... 200 OK >>>>>>>>> Length: 12565 (12K) [application/octet-stream] >>>>>>>>> Saving to: `bincPiiAf0QWg.bin'' >>>>>>>>> >>>>>>>>> 100%[======================================================================>] 12,565 30.7K/s in 0.4s >>>>>>>>> >>>>>>>>> 2009-08-28 23:18:22 (30.7 KB/s) - `bincPiiAf0QWg.bin'' saved [12565/12565] >>>>>>>>> >>>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv bincPiiAf0QWg.bin xen-gfx-passthrough.patch >>>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi xen-gfx-passthrough.patch >>>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch< xen-gfx-passthrough.patch >>>>>>>>> can''t find file to patch at input line 4 >>>>>>>>> Perhaps you should have used the -p or --strip option? >>>>>>>>> The text leading up to this was: >>>>>>>>> -------------------------- >>>>>>>>> |diff -r 5d7e7a250267 tools/firmware/hvmloader/config.h >>>>>>>>> |--- a/tools/firmware/hvmloader/config.h Wed Aug 26 18:28:44 2009 +0800 >>>>>>>>> |+++ b/tools/firmware/hvmloader/config.h Thu Aug 27 16:54:24 2009 +0800 >>>>>>>>> -------------------------- >>>>>>>>> File to patch: ^C >>>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ex xen-gfx-passthrough.patch >>>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1< xen-gfx-passthrough.patch >>>>>>>>> patching file tools/firmware/hvmloader/config.h >>>>>>>>> patching file tools/firmware/hvmloader/hvmloader.c >>>>>>>>> patching file tools/libxc/ia64/xc_ia64_hvm_build.c >>>>>>>>> patching file tools/libxc/xc_hvm_build.c >>>>>>>>> patching file tools/libxc/xc_linux.c >>>>>>>>> patching file tools/libxc/xenctrl.h >>>>>>>>> patching file tools/libxc/xenguest.h >>>>>>>>> patching file tools/python/xen/lowlevel/xc/xc.c >>>>>>>>> patching file tools/python/xen/xend/XendConfig.py >>>>>>>>> Hunk #1 succeeded at 174 (offset -1 lines). >>>>>>>>> patching file tools/python/xen/xend/image.py >>>>>>>>> Hunk #1 succeeded at 780 (offset -6 lines). >>>>>>>>> Hunk #3 succeeded at 895 (offset -6 lines). >>>>>>>>> patching file tools/python/xen/xm/create.py >>>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wgethttp://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin >>>>>>>>> --2009-08-28 23:21:35--http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin >>>>>>>>> Resolving lists.xensource.com... 70.42.241.110 >>>>>>>>> Connecting to lists.xensource.com|70.42.241.110|:80... connected. >>>>>>>>> HTTP request sent, awaiting response... 200 OK >>>>>>>>> Length: 9841 (9.6K) [application/octet-stream] >>>>>>>>> Saving to: `binglLqkeq4Rj.bin'' >>>>>>>>> >>>>>>>>> 100%[======================================================================>] 9,841 24.3K/s in 0.4s >>>>>>>>> >>>>>>>>> 2009-08-28 23:21:36 (24.3 KB/s) - `binglLqkeq4Rj.bin'' saved [9841/9841] >>>>>>>>> >>>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv binglLqkeq4Rj.bin qemu-gfx-passthrough.patch >>>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi qemu-gfx-passthrough.patch >>>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name hw >>>>>>>>> ./tools/ioemu-remote/hw >>>>>>>>> ./.hg/store/data/tools/ioemu/hw >>>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv qemu-gfx-passthrough.patch tools/ioemu-remote/ >>>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cd tools/ioemu-remote/ >>>>>>>>> [root@fedora11-x86-64-host ioemu-remote]# patch -p1< qemu- >>>>>>>>> qemu-aio.h qemu-img.c qemu-sockets.c >>>>>>>>> qemu-binfmt-conf.sh qemu-img.texi qemu-tech.texi >>>>>>>>> qemu-char.c qemu-lock.h qemu-timer.h >>>>>>>>> qemu-char.h qemu-log.h qemu-tool.c >>>>>>>>> qemu-common.h qemu-malloc.c qemu-xen.h >>>>>>>>> qemu-doc.texi qemu-nbd.c >>>>>>>>> qemu-gfx-passthrough.patch qemu-nbd.texi >>>>>>>>> [root@fedora11-x86-64-host ioemu-remote]# patch -p1< qemu-gfx-passthrough.patch >>>>>>>>> patching file hw/pass-through.c >>>>>>>>> patching file hw/pass-through.h >>>>>>>>> patching file hw/pc.c >>>>>>>>> patching file vl.c >>>>>>>>> [root@fedora11-x86-64-host ioemu-remote]# cd .. >>>>>>>>> [root@fedora11-x86-64-host tools]# cd .. >>>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi intel-gfx-passthru-patch-3.patch >>>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1< intel-gfx-passthru-patch-3.patch >>>>>>>>> patching file tools/firmware/hvmloader/Makefile >>>>>>>>> Hunk #1 FAILED at 50. >>>>>>>>> 1 out of 1 hunk FAILED -- saving rejects to file tools/firmware/hvmloader/Makefile.rej >>>>>>>>> patching file tools/firmware/hvmloader/hvmloader.c >>>>>>>>> patch: **** malformed patch at line 24: sizeof(vgabios_pt)); >>>>>>>>> >>>>>>>>> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi intel-gfx-passthru-patch-3.patch >>>>>>>>> >>>>>>>>> For everybody''s convenience, I have attached intel-gfx-passthru-patch-3.patch and the firmware for my nVidia GeForce 8400 GS PCI Express x16 graphics card in this email. >>>>>>>>> >>>>>>>>> Please help me complete intel-gfx-passthru-patch-3.patch as I really need it. >>>>>>>>> >>>>>>>>> Thank you very much!!! >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >>>>>>>>> Technical Support Engineer >>>>>>>>> Information Technology Department >>>>>>>>> Asiasoft Online Pte Ltd >>>>>>>>> Tampines Central 1 #04-01 Tampines Plaza >>>>>>>>> Singapore 529541 >>>>>>>>> Republic of Singapore >>>>>>>>> Mobile: +65-9648-9798 >>>>>>>>> MSN:teoenming@hotmail.com <mailto:teoenming@hotmail.com> >>>>>>>>> Alma Maters: Singapore Polytechnic, National University of Singapore >>>>>>>>> >>>>>>>>> This patch supports basic gfx passthrough on QEMU: >>>>>>>>> >>>>>>>>> - disable emulated VGA adpater if there is passthroughed gfx >>>>>>>>> >>>>>>>>> - register/unregister legacy VGA I/O ports and MMIOs for passthroughed gfx >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Signed-off-by: Ben Lin<ben.y.lin@intel.com> <mailto:ben.y.lin@intel.com> >>>>>>>>> >>>>>>>>> Signed-off-by: Weidong Han<weidong.han@intel.com> <mailto:weidong.han@intel.com> >>>>>>>>> >>>>>>>>> No virus found in this incoming message. >>>>>>>>> >>>>>>>>> Checked by AVG -www.avg.com <http://www.avg.com> >>>>>>>>> >>>>>>>>> Version: 8.5.409 / Virus Database: 270.13.69/2328 - Release Date: 08/27/09 >>>>>>>>> >>>>>>>>> 18:02:00 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> No virus found in this outgoing message. >>>>>>>>> >>>>>>>>> Checked by AVG -www.avg.com <http://www.avg.com> >>>>>>>>> >>>>>>>>> Version: 8.5.409 / Virus Database: 270.13.71/2330 - Release Date: 08/27/09 >>>>>>>>> >>>>>>>>> 18:02:00 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> >>>>>>>>> Xen-devel mailing list >>>>>>>>> >>>>>>>>> Xen-devel@lists.xensource.com <mailto:Xen-devel@lists.xensource.com> >>>>>>>>> >>>>>>>>> http://lists.xensource.com/xen-devel >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Xen-devel mailing list >>>>>>>>> Xen-devel@lists.xensource.com <mailto: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 >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> > >My Dom 0 is working fine as long as I don''t start X server. -- Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) Technical Support Engineer Information Technology Department Asiasoft Online Pte Ltd Tampines Central 1 #04-01 Tampines Plaza Singapore 529541 Republic of Singapore Company Website: http://www.asiasoft.sg/ Mobile: +65-9648-9798 MSN: teoenming@hotmail.com Alma Maters: Singapore Polytechnic, National University of Singapore _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Boris Derzhavets
2009-Aug-29 15:17 UTC
[Xen-devel] Failure to setup Xen 3.4.1 Dom0 on top of Ubuntu 9.10 Server HVM DomU ( 2.6.30.2 xenified kernel)
Karmic Server HVM DomU setup at Xen 3.4.1 Dom0 F11 via virt-install.
Attempt to build Xen from source and xenified kernel succeeded.
Before creating Grub 2 entry for Xen Host directive "root=UUID=.."
switched off by editing /etc/default/grub and update-grub run.
Manually created entry /boot/grub/grib.cfg as advised for Debian (Grub 2)
Xen 3.4.1 Ubuntu 9.10 {
multiboot (hd0,1)/xen-3.4.gz
module (hd0,1)/vmlinuz-2.6.30.2 root=/dev/sda2 ro console=tty0
module (hd0,1)/initrd-2.6.30.2.img
}
Failure when waiting for /dev/sda2 and dropping to grub prompt
HVM itself loads fine.
Boris.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Boris Derzhavets
2009-Aug-30 09:32 UTC
Re: [Xen-devel] Failure to setup Xen 3.4.1 Dom0 on top of Ubuntu 9.10 Server HVM DomU ( 2.6.30.2 xenified kernel)
I''ve got same problems after setup Xen 3.4.1 Xen Dom0 ( with
2.6.31-rc5 pvops) on
top of Ubuntu 9.10 Server,had been installed on bare metal.
It appears to be known issue with Grub2 when loading Xen host and came up
already on Debian Lenny.
In case of Ubuntu 9.10 Server Xen host loading started and dropped to grub
prompt
after gave up waiting for root device.
menuentry "Xen 3.4.1 Ubuntu 9.10" {
set root (hd0,1)
multiboot (hd0,1)/xen-3.4.gz
module (hd0,1)/vmlinuz-2.6.30.2 root=/dev/sda2 ro console=tty0
module (hd0,1)/initrd-2.6.30.2.img
}
generated via /etc/grub.d/40_custom editing and running update-grub
Directive "root=UUID=...." switched off via editing /etc/default/grub
and update-grub
run.
Seems to be Grub2''s multiboot implementation issue.
Grub2 breaks backward compatibility in meantime per my opinion.
Please, advise if i am wrong about that.
Boris
--- On Sat, 8/29/09, Boris Derzhavets <bderzhavets@yahoo.com> wrote:
From: Boris Derzhavets <bderzhavets@yahoo.com>
Subject: [Xen-devel] Failure to setup Xen 3.4.1 Dom0 on top of Ubuntu 9.10
Server HVM DomU ( 2.6.30.2 xenified kernel)
To: "xen-devel@lists.xensource.com"
<xen-devel@lists.xensource.com>
Date: Saturday, August 29, 2009, 11:17 AM
Karmic Server HVM DomU setup at Xen 3.4.1 Dom0 F11 via virt-install.
Attempt to build Xen from source and xenified kernel succeeded.
Before creating Grub 2 entry for Xen Host directive "root=UUID=.."
switched off by editing /etc/default/grub and update-grub run.
Manually created entry /boot/grub/grib.cfg as advised for Debian (Grub 2)
Xen 3.4.1 Ubuntu 9.10 {
multiboot (hd0,1)/xen-3.4.gz
module (hd0,1)/vmlinuz-2.6.30.2 root=/dev/sda2 ro console=tty0
module (hd0,1)/initrd-2.6.30.2.img
}
Failure when waiting for /dev/sda2 and dropping to grub prompt
HVM itself loads fine.
Boris.
-----Inline Attachment Follows-----
_______________________________________________
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
Keir Fraser
2009-Aug-30 12:44 UTC
Re: [Xen-devel] Failure to setup Xen 3.4.1 Dom0 on top of Ubuntu 9.10 Server HVM DomU ( 2.6.30.2 xenified kernel)
On 30/08/2009 10:32, "Boris Derzhavets" <bderzhavets@yahoo.com> wrote:> Directive "root=UUID=...." switched off via editing /etc/default/grub and > update-grub > run. > Seems to be Grub2''s multiboot implementation issue. > Grub2 breaks backward compatibility in meantime per my opinion. > Please, advise if i am wrong about that.Well, it might be a bug in Xen''s interpretation of the multiboot spec of course. The basic issue is that no Xen developer has tested GRUB2, and no GRUB2 developer has tested Xen. :-) No doubt this will get fixed if GRUB2 gains traction. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Boris Derzhavets
2009-Aug-30 13:19 UTC
Re: [Xen-devel] Failure to setup Xen 3.4.1 Dom0 on top of Ubuntu 9.10 Server HVM DomU ( 2.6.30.2 xenified kernel)
> no Xen developer has tested GRUB2Googling clearly shows , that a lot of Xen USERS have been experienced similar issues on Debian 5 aka Lenny. However , workaround seems to be Debian dependent - - http://www.mail-archive.com/grub-devel@gnu.org/msg10870.html For now i just add to kernel boot command line :- grub-installer/grub_2_instead_of_grub_legacy=false pressing F6 at startup menu allows to modify linux boot command line and get Ubuntu 9.10 Server installed with legacy grub. Boris. --- On Sun, 8/30/09, Keir Fraser <keir.fraser@eu.citrix.com> wrote: From: Keir Fraser <keir.fraser@eu.citrix.com> Subject: Re: [Xen-devel] Failure to setup Xen 3.4.1 Dom0 on top of Ubuntu 9..10 Server HVM DomU ( 2.6.30.2 xenified kernel) To: "Boris Derzhavets" <bderzhavets@yahoo.com>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Date: Sunday, August 30, 2009, 8:44 AM On 30/08/2009 10:32, "Boris Derzhavets" <bderzhavets@yahoo.com> wrote:> Directive "root=UUID=...." switched off via editing /etc/default/grub and > update-grub > run. > Seems to be Grub2''s multiboot implementation issue. > Grub2 breaks backward compatibility in meantime per my opinion. > Please, advise if i am wrong about that.Well, it might be a bug in Xen''s interpretation of the multiboot spec of course. The basic issue is that no Xen developer has tested GRUB2, and no GRUB2 developer has tested Xen. :-) No doubt this will get fixed if GRUB2 gains traction. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Christian Tramnitz
2009-Aug-30 13:26 UTC
[Xen-devel] Re: Failure to setup Xen 3.4.1 Dom0 on top of Ubuntu 9.10 Server HVM DomU ( 2.6.30.2 xenified kernel)
Afaik grub2 does not pass the boot parameters "root=/dev/sda2 ro
console=tty0" to the kernel in multiboot/module combination. I have seen
the same problem on gentoo/grub2 and also read about this before. (This
is not really Xen specific, but multiboot related).
My workaround was to compile the kernel options as static cmdline into
the kernel itself...
Best regards,
Christian
Boris Derzhavets wrote:> Karmic Server HVM DomU setup at Xen 3.4.1 Dom0 F11 via virt-install.
> Attempt to build Xen from source and xenified kernel succeeded.
> Before creating Grub 2 entry for Xen Host directive
"root=UUID=.."
> switched off by editing /etc/default/grub and update-grub run.
>
> Manually created entry /boot/grub/grib.cfg as advised for Debian (Grub 2)
>
> Xen 3.4.1 Ubuntu 9.10 {
> multiboot (hd0,1)/xen-3.4.gz
> module (hd0,1)/vmlinuz-2.6.30.2 root=/dev/sda2 ro console=tty0
> module (hd0,1)/initrd-2.6.30.2.img
> }
>
> Failure when waiting for /dev/sda2 and dropping to grub prompt
>
> HVM itself loads fine.
>
> Boris.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Boris Derzhavets
2009-Aug-30 15:17 UTC
Re: [Xen-devel] Re: Failure to setup Xen 3.4.1 Dom0 on top of Ubuntu 9.10 Server HVM DomU ( 2.6.30.2 xenified kernel)
>My workaround was to compile the kernel options as static cmdline into > the kernel itself...Never did it, but your idea is very clear. Could you provide any link ( manual ) how to build linux kernel with static command line ? Might be somewhere in menuconfig ? Thanks any way. Boris. P.S. I''ve already made sure that Karmic Server works fine with legacy grub installed. --- On Sun, 8/30/09, Christian Tramnitz <chris.ace@gmx.net> wrote: From: Christian Tramnitz <chris.ace@gmx.net> Subject: [Xen-devel] Re: Failure to setup Xen 3.4.1 Dom0 on top of Ubuntu 9..10 Server HVM DomU ( 2.6.30.2 xenified kernel) To: xen-devel@lists.xensource.com Date: Sunday, August 30, 2009, 9:26 AM Afaik grub2 does not pass the boot parameters "root=/dev/sda2 ro console=tty0" to the kernel in multiboot/module combination. I have seen the same problem on gentoo/grub2 and also read about this before. (This is not really Xen specific, but multiboot related). My workaround was to compile the kernel options as static cmdline into the kernel itself... Best regards, Christian Boris Derzhavets wrote:> Karmic Server HVM DomU setup at Xen 3.4.1 Dom0 F11 via virt-install. > Attempt to build Xen from source and xenified kernel succeeded. > Before creating Grub 2 entry for Xen Host directive "root=UUID=.." switched off by editing /etc/default/grub and update-grub run. > > Manually created entry /boot/grub/grib.cfg as advised for Debian (Grub 2) > Xen 3.4.1 Ubuntu 9.10 { > multiboot (hd0,1)/xen-3.4.gz > module (hd0,1)/vmlinuz-2.6.30.2 root=/dev/sda2 ro console=tty0 > module (hd0,1)/initrd-2.6.30.2.img > } > > Failure when waiting for /dev/sda2 and dropping to grub prompt > > HVM itself loads fine. > > Boris._______________________________________________ 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
Keir Fraser
2009-Aug-30 15:50 UTC
Re: [Xen-devel] Re: Failure to setup Xen 3.4.1 Dom0 on top of Ubuntu 9.10 Server HVM DomU ( 2.6.30.2 xenified kernel)
On 30/08/2009 14:26, "Christian Tramnitz" <chris.ace@gmx.net> wrote:> Afaik grub2 does not pass the boot parameters "root=/dev/sda2 ro > console=tty0" to the kernel in multiboot/module combination. I have seen > the same problem on gentoo/grub2 and also read about this before. (This > is not really Xen specific, but multiboot related).Okay, that would clearly be a GRUB regression I think. But there is a simple enough less ugly workaround than you suggest...> My workaround was to compile the kernel options as static cmdline into > the kernel itself...Better solution would be to append dom0''s options to Xen''s own command line, separated by --. E.g., multiboot (hd0,1)/xen-3.4.gz console=tty -- root=/dev/sda2 ro console=tty0 -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Boris Derzhavets
2009-Aug-30 15:53 UTC
Re: [Xen-devel] Re: Failure to setup Xen 3.4.1 Dom0 on top of Ubuntu 9.10 Server HVM DomU ( 2.6.30.2 xenified kernel)
[*] Built-in kernel command line │ │ │ │ (root=/dev/sda14 ro console=tty0) Built-in kernel command string I believe i am close Boris. --- On Sun, 8/30/09, Boris Derzhavets <bderzhavets@yahoo.com> wrote: From: Boris Derzhavets <bderzhavets@yahoo.com> Subject: Re: [Xen-devel] Re: Failure to setup Xen 3.4.1 Dom0 on top of Ubuntu 9.10 Server HVM DomU ( 2.6.30.2 xenified kernel) To: xen-devel@lists.xensource.com, "Christian Tramnitz" <chris.ace@gmx.net> Date: Sunday, August 30, 2009, 11:17 AM>My workaround was to compile the kernel options as static cmdline into > the kernel itself...Never did it, but your idea is very clear. Could you provide any link ( manual ) how to build linux kernel with static command line ? Might be somewhere in menuconfig ? Thanks any way. Boris. P.S. I''ve already made sure that Karmic Server works fine with legacy grub installed. --- On Sun, 8/30/09, Christian Tramnitz <chris.ace@gmx.net> wrote: From: Christian Tramnitz <chris.ace@gmx.net> Subject: [Xen-devel] Re: Failure to setup Xen 3.4.1 Dom0 on top of Ubuntu 9..10 Server HVM DomU ( 2.6.30.2 xenified kernel) To: xen-devel@lists.xensource.com Date: Sunday, August 30, 2009, 9:26 AM Afaik grub2 does not pass the boot parameters "root=/dev/sda2 ro console=tty0" to the kernel in multiboot/module combination. I have seen the same problem on gentoo/grub2 and also read about this before. (This is not really Xen specific, but multiboot related).. My workaround was to compile the kernel options as static cmdline into the kernel itself... Best regards, Christian Boris Derzhavets wrote:> Karmic Server HVM DomU setup at Xen 3..4.1 Dom0 F11 via virt-install. > Attempt to build Xen from source and xenified kernel succeeded. > Before creating Grub 2 entry for Xen Host directive "root=UUID=.." switched off by editing /etc/default/grub and update-grub run. > > Manually created entry /boot/grub/grib.cfg as advised for Debian (Grub 2) > Xen 3.4..1 Ubuntu 9.10 { > multiboot (hd0,1)/xen-3.4.gz > module(hd0,1)/vmlinuz-2.6.30.2 root=/dev/sda2 ro console=tty0> module (hd0,1)/initrd-2.6.30.2.img > } > > Failure when waiting for /dev/sda2 and dropping to grub prompt > > HVM itself loads fine. > > Boris._______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource..com/xen-devel -----Inline Attachment Follows----- _______________________________________________ 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
Boris Derzhavets
2009-Aug-30 16:22 UTC
Re: [Xen-devel] Re: Failure to setup Xen 3.4.1 Dom0 on top of Ubuntu 9.10 Server HVM DomU ( 2.6.30.2 xenified kernel)
I''ve tested both options. Chris''s one works with Grub2, Keir''s doesn''t. Distro Ubuntu 9.10 Server (alpha 4.) Thanks. Boris. --- On Sun, 8/30/09, Keir Fraser <keir.fraser@eu.citrix.com> wrote: From: Keir Fraser <keir.fraser@eu.citrix.com> Subject: Re: [Xen-devel] Re: Failure to setup Xen 3.4.1 Dom0 on top of Ubuntu 9.10 Server HVM DomU ( 2.6.30.2 xenified kernel) To: "Christian Tramnitz" <chris.ace@gmx.net>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Date: Sunday, August 30, 2009, 11:50 AM On 30/08/2009 14:26, "Christian Tramnitz" <chris.ace@gmx.net> wrote:> Afaik grub2 does not pass the boot parameters "root=/dev/sda2 ro > console=tty0" to the kernel in multiboot/module combination. I have seen > the same problem on gentoo/grub2 and also read about this before. (This > is not really Xen specific, but multiboot related).Okay, that would clearly be a GRUB regression I think. But there is a simple enough less ugly workaround than you suggest...> My workaround was to compile the kernel options as static cmdline into > the kernel itself...Better solution would be to append dom0''s options to Xen''s own command line, separated by --. E.g., multiboot (hd0,1)/xen-3.4.gz console=tty -- root=/dev/sda2 ro console=tty0 -- Keir _______________________________________________ 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
Keir Fraser
2009-Aug-30 16:41 UTC
Re: [Xen-devel] Re: Failure to setup Xen 3.4.1 Dom0 on top of Ubuntu 9.10 Server HVM DomU ( 2.6.30.2 xenified kernel)
Mine should, if GRUB2 passes through Xen''s command line. -- Keir On 30/08/2009 17:22, "Boris Derzhavets" <bderzhavets@yahoo.com> wrote:> I''ve tested both options. > > Chris''s one works with Grub2, Keir''s doesn''t. > Distro Ubuntu 9.10 Server (alpha 4.) > > Thanks. > Boris. > > --- On Sun, 8/30/09, Keir Fraser <keir.fraser@eu.citrix.com> wrote: >> >> From: Keir Fraser <keir.fraser@eu.citrix.com> >> Subject: Re: [Xen-devel] Re: Failure to setup Xen 3.4.1 Dom0 on top of Ubuntu >> 9.10 Server HVM DomU ( 2.6.30.2 xenified kernel) >> To: "Christian Tramnitz" <chris.ace@gmx.net>, "xen-devel@lists.xensource.com" >> <xen-devel@lists.xensource.com> >> Date: Sunday, August 30, 2009, 11:50 AM >> >> On 30/08/2009 14:26, "Christian Tramnitz" <chris.ace@gmx.net >> </mc/compose?to=chris.ace@gmx.net> > wrote: >> >>> Afaik grub2 does not pass the boot parameters "root=/dev/sda2 ro >>> console=tty0" to the kernel in multiboot/module combination. I have seen >>> the same problem on gentoo/grub2 and also read about this before. (This >>> is not really Xen specific, but multiboot related). >> >> Okay, that would clearly be a GRUB regression I think. But there is a simple >> enough less ugly workaround than you suggest... >> >>> My workaround was to compile the kernel options as static cmdline into >>> the kernel itself... >> >> Better solution would be to append dom0''s options to Xen''s own command line, >> separated by --. E.g., >> multiboot (hd0,1)/xen-3.4.gz console=tty -- root=/dev/sda2 ro console=tty0 >> >> -- Keir >> >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com </mc/compose?to=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
Keir Fraser
2009-Aug-30 16:55 UTC
Re: [Xen-devel] Re: Failure to setup Xen 3.4.1 Dom0 on top of Ubuntu 9.10 Server HVM DomU ( 2.6.30.2 xenified kernel)
Perhaps we''ve got the grub.cfg syntax for specifying multiboot kernel/module command-line options wrong. Unfortunately I can''t find any documentation describing what the syntax is for multiboot config entries. -- Keir On 30/08/2009 17:41, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote:> Mine should, if GRUB2 passes through Xen''s command line. > > -- Keir > > On 30/08/2009 17:22, "Boris Derzhavets" <bderzhavets@yahoo.com> wrote: > >> I''ve tested both options. >> >> Chris''s one works with Grub2, Keir''s doesn''t. >> Distro Ubuntu 9.10 Server (alpha 4.) >> >> Thanks. >> Boris. >> >> --- On Sun, 8/30/09, Keir Fraser <keir.fraser@eu.citrix.com> wrote: >>> >>> From: Keir Fraser <keir.fraser@eu.citrix.com> >>> Subject: Re: [Xen-devel] Re: Failure to setup Xen 3.4.1 Dom0 on top of >>> Ubuntu >>> 9.10 Server HVM DomU ( 2.6.30.2 xenified kernel) >>> To: "Christian Tramnitz" <chris.ace@gmx.net>, >>> "xen-devel@lists.xensource.com" >>> <xen-devel@lists.xensource.com> >>> Date: Sunday, August 30, 2009, 11:50 AM >>> >>> On 30/08/2009 14:26, "Christian Tramnitz" <chris.ace@gmx.net >>> </mc/compose?to=chris.ace@gmx.net> > wrote: >>> >>>> Afaik grub2 does not pass the boot parameters "root=/dev/sda2 ro >>>> console=tty0" to the kernel in multiboot/module combination. I have seen >>>> the same problem on gentoo/grub2 and also read about this before. (This >>>> is not really Xen specific, but multiboot related). >>> >>> Okay, that would clearly be a GRUB regression I think. But there is a simple >>> enough less ugly workaround than you suggest... >>> >>>> My workaround was to compile the kernel options as static cmdline into >>>> the kernel itself... >>> >>> Better solution would be to append dom0''s options to Xen''s own command line, >>> separated by --. E.g., >>> multiboot (hd0,1)/xen-3.4.gz console=tty -- root=/dev/sda2 ro console=tty0 >>> >>> -- Keir >>> >>> >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xensource.com </mc/compose?to=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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Boris Derzhavets
2009-Aug-30 17:10 UTC
Re: [Xen-devel] Re: Failure to setup Xen 3.4.1 Dom0 on top of Ubuntu 9.10 Server HVM DomU ( 2.6.30.2 xenified kernel)
I believe passing parameters via xen.gz command line will become extremely important for any distro with grub2 like Ubuntu Karmic Server. Boris. --- On Sun, 8/30/09, Keir Fraser <keir.fraser@eu.citrix.com> wrote: From: Keir Fraser <keir.fraser@eu.citrix.com> Subject: Re: [Xen-devel] Re: Failure to setup Xen 3.4.1 Dom0 on top of Ubuntu 9.10 Server HVM DomU ( 2.6.30.2 xenified kernel) To: "Keir Fraser" <keir.fraser@eu.citrix.com>, "Boris Derzhavets" <bderzhavets@yahoo.com>, "Christian Tramnitz" <chris.ace@gmx.net>, "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> Date: Sunday, August 30, 2009, 12:55 PM Perhaps we''ve got the grub.cfg syntax for specifying multiboot kernel/module command-line options wrong. Unfortunately I can''t find any documentation describing what the syntax is for multiboot config entries. -- Keir On 30/08/2009 17:41, "Keir Fraser" <keir.fraser@eu.citrix.com> wrote:> Mine should, if GRUB2 passes through Xen''s command line. > > -- Keir > > On 30/08/2009 17:22, "Boris Derzhavets" <bderzhavets@yahoo.com> wrote: > >> I''ve tested both options. >> >> Chris''s one works with Grub2, Keir''s doesn''t. >> Distro Ubuntu 9.10 Server (alpha 4.) >> >> Thanks. >> Boris. >> >> --- On Sun, 8/30/09, Keir Fraser <keir.fraser@eu.citrix.com> wrote: >>> >>> From: Keir Fraser <keir.fraser@eu.citrix.com> >>> Subject: Re: [Xen-devel] Re: Failure to setup Xen 3.4.1 Dom0 on top of >>> Ubuntu >>> 9.10 Server HVM DomU ( 2.6.30.2 xenified kernel) >>> To: "Christian Tramnitz" <chris.ace@gmx.net>, >>> "xen-devel@lists.xensource.com" >>> <xen-devel@lists.xensource.com> >>> Date: Sunday, August 30, 2009, 11:50 AM >>> >>> On 30/08/2009 14:26, "Christian Tramnitz" <chris.ace@gmx.net >>> </mc/compose?to=chris.ace@gmx.net> > wrote: >>> >>>> Afaik grub2 does not pass the boot parameters "root=/dev/sda2 ro >>>> console=tty0" to the kernel in multiboot/module combination. I have seen >>>> the same problem on gentoo/grub2 and also read about this before. (This >>>> is not really Xen specific, but multiboot related). >>> >>> Okay, that would clearly be a GRUB regression I think. But there is a simple >>> enough less ugly workaround than you suggest... >>> >>>> My workaround was to compile the kernel options as static cmdline into >>>> the kernel itself... >>> >>> Better solution would be to append dom0''s options to Xen''s own command line, >>> separated by --. E.g., >>> multiboot (hd0,1)/xen-3.4.gz console=tty -- root=/dev/sda2 ro console=tty0 >>> >>> -- Keir >>> >>> >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xensource.com </mc/compose?to=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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2009-Aug-30 17:49 UTC
Re: [Xen-devel] Re: Failure to setup Xen 3.4.1 Dom0 on top of Ubuntu 9.10 Server HVM DomU ( 2.6.30.2 xenified kernel)
Well, yeah... Good point ;-) -- Keir On 30/08/2009 18:10, "Boris Derzhavets" <bderzhavets@yahoo.com> wrote:> I believe passing parameters via xen.gz command line will become extremely > important for any distro with grub2 like Ubuntu Karmic Server. > > Boris. > > --- On Sun, 8/30/09, Keir Fraser <keir.fraser@eu.citrix.com> wrote: >> >> From: Keir Fraser <keir.fraser@eu.citrix.com> >> Subject: Re: [Xen-devel] Re: Failure to setup Xen 3.4.1 Dom0 on top of Ubuntu >> 9.10 Server HVM DomU ( 2.6.30.2 xenified kernel) >> To: "Keir Fraser" <keir.fraser@eu.citrix.com>, "Boris Derzhavets" >> <bderzhavets@yahoo.com>, "Christian Tramnitz" <chris.ace@gmx.net>, >> "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com> >> Date: Sunday, August 30, 2009, 12:55 PM >> >> Perhaps we''ve got the grub.cfg syntax for specifying multiboot kernel/module >> command-line options wrong. Unfortunately I can''t find any documentation >> describing what the syntax is for multiboot config entries. >> >> -- Keir >> >> On 30/08/2009 17:41, "Keir Fraser" <keir.fraser@eu.citrix.com >> </mc/compose?to=keir.fraser@eu.citrix.com> > wrote: >> >>> Mine should, if GRUB2 passes through Xen''s command line. >>> >>> -- Keir >>> >>> On 30/08/2009 17:22, "Boris Derzhavets" <bderzhavets@yahoo.com >>> </mc/compose?to=bderzhavets@yahoo.com> > wrote: >>> >>>> I''ve tested both options. >>>> >>>> Chris''s one works with Grub2, Keir''s doesn''t. >>>> Distro Ubuntu 9.10 Server (alpha 4.) >>>> >>>> Thanks. >>>> Boris. >>>> >>>> --- On Sun, 8/30/09, Keir Fraser <keir.fraser@eu.citrix.com >>>> </mc/compose?to=keir..fraser@eu.citrix.com> > wrote: >>>>> >>>>> From: Keir Fraser <keir.fraser@eu.citrix.com >>>>> </mc/compose?to=keir.fraser@eu.citrix.com> > >>>>> Subject: Re: [Xen-devel] Re: Failure to setup Xen 3.4.1 Dom0 on top of >>>>> Ubuntu >>>>> 9.10 Server HVM DomU ( 2.6.30.2 xenified kernel) >>>>> To: "Christian Tramnitz" <chris.ace@gmx.net >>>>> </mc/compose?to=chris.ace@gmx.net> >, >>>>> "xen-devel@lists.xensource.com >>>>> </mc/compose?to=xen-devel@lists.xensource.com> " >>>>> <xen-devel@lists.xensource.com >>>>> </mc/compose?to=xen-devel@lists.xensource.com> > >>>>> Date: Sunday, August 30, 2009, 11:50 AM >>>>> >>>>> On 30/08/2009 14:26, "Christian Tramnitz" <chris.ace@gmx.net >>>>> </mc/compose?to=chris..ace@gmx.net> >>>>> </mc/compose?to=chris.ace@gmx.net </mc/compose?to=chris.ace@gmx.net> > > >>>>> wrote: >>>>> >>>>>> Afaik grub2 does not pass the boot parameters "root=/dev/sda2 ro >>>>>> console=tty0" to the kernel in multiboot/module combination. I have seen >>>>>> the same problem on gentoo/grub2 and also read about this before. (This >>>>>> is not really Xen specific, but multiboot related). >>>>> >>>>> Okay, that would clearly be a GRUB regression I think. But there is a >>>>> simple >>>>> enough less ugly workaround than you suggest... >>>>> >>>>>> My workaround was to compile the kernel options as static cmdline into >>>>>> the kernel itself... >>>>> >>>>> Better solution would be to append dom0''s options to Xen''s own command >>>>> line, >>>>> separated by --. E.g., >>>>> multiboot (hd0,1)/xen-3.4.gz console=tty -- root=/dev/sda2 ro console=tty0 >>>>> >>>>> -- Keir >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Xen-devel mailing list >>>>> Xen-devel@lists.xensource.com >>>>> </mc/compose?to=Xen-devel@lists.xensource.com> >>>>> </mc/compose?to=Xen-devel@lists.xensource.com >>>>> </mc/compose?to=Xen-devel@lists.xensource.com> > >>>>> http://lists.xensource.com/xen-devel >>>> >>>> >>> >>> >>> >>> _______________________________________________ >>> Xen-devel mailing list >>> Xen-devel@lists.xensource.com </mc/compose?to=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
Ian Pratt
2009-Aug-30 17:55 UTC
RE: [Xen-devel] Failure to setup Xen 3.4.1 Dom0 on top of Ubuntu 9.10 Server HVM DomU ( 2.6.30.2 xenified kernel)
> > Directive "root=UUID=...." switched off via editing /etc/default/grub > and > > update-grub > > run. > > Seems to be Grub2''s multiboot implementation issue. > > Grub2 breaks backward compatibility in meantime per my opinion. > > Please, advise if i am wrong about that. > > Well, it might be a bug in Xen''s interpretation of the multiboot spec of > course. The basic issue is that no Xen developer has tested GRUB2, and no > GRUB2 developer has tested Xen. :-) No doubt this will get fixed if GRUB2 > gains traction.The xen client XCI tree uses grub2. I seem to recall there was a bug that needed fixing in grub2 to make it work reliably, but I thought this was up-streamed. It''s worth looking to see if there are any grub2 related patches in the XCI tree, though. Ian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Tim Moore
2009-Aug-30 18:14 UTC
[Xen-devel] RE: Failure to start Xen >3.4.1 and xen-3.5-unstable Dom0 using GRUB2
Hi Christian/All,
I have a similar issue with GRUB2 .. I was using grub-legacy for a while, until
I switched to using XCI (Xen Client Initiative) which comes as standard with a
GRUB2. (no option for alternative, as XCI uses LVM so must use GRUB2)
Then I also try GRUB2 multiboot with latest xen-unstable/pvops and received the
attached error .. (jpg)
"Cannot access memory beyond the end of bootstrap direct-map area"
Therefore I have switched back to grub-legacy (0.97) and xen-unstable/pvops
boots fine !
ATMO I am unable to boot XCI as grub-legacy does not support LVM - I am now
looking to chainload GRUB>GRUB2 to enable me to start XCI.
With earlier version of xen-unstable, I was able to boot successfully. There has
been a change in XEN that has broken compatibility with the (incomplete) GRUB2
multiboot specification. I would therefore say that GRUB2 needs the bugfix, but
its XEN that actually broke compatibility.
Rgds,
Tim
-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Christian Tramnitz
Sent: 30 August 2009 14:26
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Re: Failure to setup Xen 3.4.1 Dom0 on top of Ubuntu 9.10
Server HVM DomU ( 2.6.30.2 xenified kernel)
Afaik grub2 does not pass the boot parameters "root=/dev/sda2 ro
console=tty0" to the kernel in multiboot/module combination. I have seen
the same problem on gentoo/grub2 and also read about this before. (This
is not really Xen specific, but multiboot related).
My workaround was to compile the kernel options as static cmdline into
the kernel itself...
Best regards,
Christian
Boris Derzhavets wrote:> Karmic Server HVM DomU setup at Xen 3.4.1 Dom0 F11 via virt-install.
> Attempt to build Xen from source and xenified kernel succeeded.
> Before creating Grub 2 entry for Xen Host directive
"root=UUID=.."
> switched off by editing /etc/default/grub and update-grub run.
>
> Manually created entry /boot/grub/grib.cfg as advised for Debian (Grub 2)
>
> Xen 3.4.1 Ubuntu 9.10 {
> multiboot (hd0,1)/xen-3.4.gz
> module (hd0,1)/vmlinuz-2.6.30.2 root=/dev/sda2 ro console=tty0
> module (hd0,1)/initrd-2.6.30.2.img
> }
>
> Failure when waiting for /dev/sda2 and dropping to grub prompt
>
> HVM itself loads fine.
>
> Boris.
_______________________________________________
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
Tim Moore
2009-Aug-30 18:17 UTC
RE: [Xen-devel] Failure to setup Xen 3.4.1 Dom0 on top of Ubuntu 9.10 Server HVM DomU ( 2.6.30.2 xenified kernel)
I use grub2 from XCI and still have boot issue .. "Cannot access memory beyond the end of bootstrap direct-map area" grub-legacy is fine .. -----Original Message----- From: xen-devel-bounces@lists.xensource.com [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Ian Pratt Sent: 30 August 2009 18:55 To: Keir Fraser; Boris Derzhavets; xen-devel@lists.xensource.com Cc: Ian Pratt Subject: RE: [Xen-devel] Failure to setup Xen 3.4.1 Dom0 on top of Ubuntu 9.10 Server HVM DomU ( 2.6.30.2 xenified kernel)> > Directive "root=UUID=...." switched off via editing /etc/default/grub > and > > update-grub > > run. > > Seems to be Grub2''s multiboot implementation issue. > > Grub2 breaks backward compatibility in meantime per my opinion. > > Please, advise if i am wrong about that. > > Well, it might be a bug in Xen''s interpretation of the multiboot spec of > course. The basic issue is that no Xen developer has tested GRUB2, and no > GRUB2 developer has tested Xen. :-) No doubt this will get fixed if GRUB2 > gains traction.The xen client XCI tree uses grub2. I seem to recall there was a bug that needed fixing in grub2 to make it work reliably, but I thought this was up-streamed. It''s worth looking to see if there are any grub2 related patches in the XCI tree, though. Ian _______________________________________________ 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
Boris Derzhavets
2009-Aug-30 18:19 UTC
Re: [Xen-devel] Re: Failure to setup Xen 3.4.1 Dom0 on top of Ubuntu 9.10 Server HVM DomU ( 2.6.30.2 xenified kernel)
It does help for 2.6.30.2 xenified aka Suse kernel( via Andy Lyon''s Patch Set V.3) and doesn''t help for 2.6.31-rc5 pvops enabled kernel. I can''t build fresh 2-6-31-rc6 at the moment. Make fails. Boris. --- On Sun, 8/30/09, Christian Tramnitz <chris.ace@gmx.net> wrote: From: Christian Tramnitz <chris.ace@gmx.net> Subject: [Xen-devel] Re: Failure to setup Xen 3.4.1 Dom0 on top of Ubuntu 9..10 Server HVM DomU ( 2.6.30.2 xenified kernel) To: xen-devel@lists.xensource.com Date: Sunday, August 30, 2009, 9:26 AM Afaik grub2 does not pass the boot parameters "root=/dev/sda2 ro console=tty0" to the kernel in multiboot/module combination. I have seen the same problem on gentoo/grub2 and also read about this before. (This is not really Xen specific, but multiboot related). My workaround was to compile the kernel options as static cmdline into the kernel itself... Best regards, Christian Boris Derzhavets wrote:> Karmic Server HVM DomU setup at Xen 3.4.1 Dom0 F11 via virt-install. > Attempt to build Xen from source and xenified kernel succeeded. > Before creating Grub 2 entry for Xen Host directive "root=UUID=.." switched off by editing /etc/default/grub and update-grub run. > > Manually created entry /boot/grub/grib.cfg as advised for Debian (Grub 2) > Xen 3.4.1 Ubuntu 9.10 { > multiboot (hd0,1)/xen-3.4.gz > module (hd0,1)/vmlinuz-2.6.30.2 root=/dev/sda2 ro console=tty0 > module (hd0,1)/initrd-2.6.30.2.img > } > > Failure when waiting for /dev/sda2 and dropping to grub prompt > > HVM itself loads fine. > > Boris._______________________________________________ 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
Keir Fraser
2009-Aug-30 18:32 UTC
Re: [Xen-devel] Failure to setup Xen 3.4.1 Dom0 on top of Ubuntu 9.10 Server HVM DomU ( 2.6.30.2 xenified kernel)
Do you use 32-bit Xen? Could you use 64-bit Xen instead? I think the latter will work for you, and if it doesn''t then we''ll fix it, whereas this may not get fixed for 32-bit Xen. -- Keir On 30/08/2009 19:17, "Tim Moore" <timothy.moore@expidas.net> wrote:> I use grub2 from XCI and still have boot issue .. > "Cannot access memory beyond the end of bootstrap direct-map area" > > grub-legacy is fine .. > > -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Ian Pratt > Sent: 30 August 2009 18:55 > To: Keir Fraser; Boris Derzhavets; xen-devel@lists.xensource.com > Cc: Ian Pratt > Subject: RE: [Xen-devel] Failure to setup Xen 3.4.1 Dom0 on top of Ubuntu 9.10 > Server HVM DomU ( 2.6.30.2 xenified kernel) > >>> Directive "root=UUID=...." switched off via editing /etc/default/grub >> and >>> update-grub >>> run. >>> Seems to be Grub2''s multiboot implementation issue. >>> Grub2 breaks backward compatibility in meantime per my opinion. >>> Please, advise if i am wrong about that. >> >> Well, it might be a bug in Xen''s interpretation of the multiboot spec of >> course. The basic issue is that no Xen developer has tested GRUB2, and no >> GRUB2 developer has tested Xen. :-) No doubt this will get fixed if GRUB2 >> gains traction. > > The xen client XCI tree uses grub2. I seem to recall there was a bug that > needed fixing in grub2 to make it work reliably, but I thought this was > up-streamed. It''s worth looking to see if there are any grub2 related patches > in the XCI tree, though. > > Ian > > _______________________________________________ > 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
Boris Derzhavets
2009-Aug-31 07:17 UTC
Re: [Xen-devel] Re: Failure to setup Xen 3.4.1 Dom0 on top of Ubuntu 9.10 Server HVM DomU ( 2.6.30.2 xenified kernel)
The most recent build 2.6.31-rc6 compiled with static cmd line per Chris works as well as xenified kernels via GRUB2 menuentry on Ubuntu 9.10 Server (alpha 4) Boris --- On Sun, 8/30/09, Boris Derzhavets <bderzhavets@yahoo.com> wrote: From: Boris Derzhavets <bderzhavets@yahoo.com> Subject: Re: [Xen-devel] Re: Failure to setup Xen 3.4.1 Dom0 on top of Ubuntu 9.10 Server HVM DomU ( 2.6.30.2 xenified kernel) To: xen-devel@lists.xensource.com, "Christian Tramnitz" <chris.ace@gmx.net> Date: Sunday, August 30, 2009, 2:19 PM It does help for 2.6.30.2 xenified aka Suse kernel( via Andy Lyon''s Patch Set V.3) and doesn''t help for 2.6.31-rc5 pvops enabled kernel. I can''t build fresh 2-6-31-rc6 at the moment. Make fails. Boris. --- On Sun, 8/30/09, Christian Tramnitz <chris.ace@gmx.net> wrote: From: Christian Tramnitz <chris.ace@gmx.net> Subject: [Xen-devel] Re: Failure to setup Xen 3.4.1 Dom0 on top of Ubuntu 9..10 Server HVM DomU ( 2.6.30.2 xenified kernel) To: xen-devel@lists.xensource.com Date: Sunday, August 30, 2009, 9:26 AM Afaik grub2 does not pass the boot parameters "root=/dev/sda2 ro console=tty0" to the kernel in multiboot/module combination. I have seen the same problem on gentoo/grub2 and also read about this before. (This is not really Xen specific, but multiboot related). My workaround was to compile the kernel options as static cmdline into the kernel itself... Best regards, Christian Boris Derzhavets wrote:> Karmic Server HVM DomU setup at Xen 3.4.1 Dom0 F11 via virt-install. > Attempt to build Xen from source and xenified kernel succeeded. > Before creating Grub 2 entry for Xen Host directive "root=UUID=.." switched off by editing /etc/default/grub and update-grub run. > > Manually created entry /boot/grub/grib.cfg as advised for Debian (Grub 2) > Xen 3.4.1 Ubuntu 9.10 { > multiboot (hd0,1)/xen-3.4.gz > module (hd0,1)/vmlinuz-2.6.30.2 root=/dev/sda2 ro console=tty0 > module (hd0,1)/initrd-2.6.30.2.img > } > > Failure when waiting for /dev/sda2 and droppingto grub prompt> > HVM itself loads fine. > > Boris._______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel -----Inline Attachment Follows----- _______________________________________________ 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
Teo,
I attached some experimental patches for you to try to sthorugh Geforce 8400 GS.
Based on my patches posted last Friday, pls follow below instructions:
1. apply xen-load-vbios-file.patch to xen-unstable.hg
this patch supports to load vga bios from a file.
2. apply xen-vBAR-pBAR.patch to xen-unstable.hg
this patch is used to 1:1 map between vBAR and pBAR
3. apply qemu-change-for-vBAR-pBAR.patch to ioemu-remote (qemu tree).
this patch is used to 1:1 map between vBAR and pBAR on qemu side
4. apply qemu-claim-cycle-for-secondary-gfx-passthrough.patch
it's needed if you want to assign the secondary gfx to guest.
5. cd xen-unstable.hg
6. make clean
7. copy the vga bios file to
xen-unstabl.hg/tools/firmware/vgabios/vgabios-pt.bin
8. make; make install
9. reboot the system. or xend restart. then passthrough gfx to guest ...
Regards,
Weidong
________________________________
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Mr. Teo En Ming
(Zhang Enming)
Sent: 2009年8月29日 22:13
To: timothy.moore@expidas.net
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] graphics passthrough with VT-d
Hi Timothy,
Yes, I renamed the firmware file of nVidia Geforce 8400 GS to vgabios-pt.bin and
placed it in the source directory tools/firmware/vgabios.
Weidong had said Intel has the 1:1 mapping patches. Let's hope he will
release the patch soon to do pBAR:vBAR.
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Company Website: http://www.asiasoft.sg/
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 09:29 PM, Tim Moore wrote:
Teo,
Did you rename your Nvidia BIOS and copy it into the hvmloader source tree as
required ?
It should get compiled into roms.h in the hvmloader folder - I made sure it was
there as the xen buildroot seems to delete it randomly ...
I think we are now up against the Base Address Register issue where the Nvidia
driver is expecting to see the card at the Physical BAR Addresses and in the
DomU these are re-mapped to different address space ... this is a problem with
the Nvidia binary driver and therefore a workaround in xen is maybe needed.
That said, I'm not sure if the Nvidia BIOS likes to be re-executed and may
also be an issue ...
Tim
From: Mr. Teo En Ming (Zhang Enming) [mailto:enming.teo@asiasoftsea.net]
Sent: 29 August 2009 14:21
To: enming.teo@asiasoftsea.net<mailto:enming.teo@asiasoftsea.net>
Cc: Tim Moore;
xen-devel@lists.xensource.com<mailto:xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] graphics passthrough with VT-d
Dear All,
I have applied the following patches to xen 3.5-unstable
1) intel-gfx-passthru-patch01.patch
2) intel-gfx-passthru-patch02.patch
3) intel-gfx-passthru-patch03.patch
4) enming-patch04.patch
and compiled xen 3.5-unstable successfully (both hypervisor and tools).
i rebooted into this newly compiled Xen hypervisor which supports loading vga
bios from firmware file of nVidia Geforce 8400 GS PCI Express x16.
After dom0 has booted up, I executed the following script to hide nVidia Geforce
8400 GS from dom0.
[enming@fedora11-x86-64-host scripts]$ cat bind-devices-pci-stub.sh
#!/bin/sh
echo "10de 06e4" > /sys/bus/pci/drivers/pci-stub/new_id
echo "0000:01:00.0" >
/sys/bus/pci/devices/0000:01:00.0/driver/unbind
echo "0000:01:00.0" > /sys/bus/pci/drivers/pci-stub/bind
I also assigned the nVidia Geforce 8400 GS to my Windows XP Home HVM domU.
pci = [ '01:00.0' ]
I also specified gfx_passthru=2.
Do note that I booted up with onboard Intel GMA4500 as the primary video
adapter. Hence dom 0 has onboard graphics and Windows XP HVM domU has nvidia
graphics.
Then I started Windows XP Home HVM DomU.
Very soon, my Dom 0's display was garbaged and X server on Dom 0 totally
froze and became unresponsive. I cannot switch to any ttys.
However, I was still able to vnc into my Windows XP Home HVM Dom U. I had
earlier installed a VNC server into my Windows XP guest. After remoting in to my
Windows XP DomU through vnc, I found that NVIDIA Geforce 8400 GS cannot be
initialized and no resources are available for this graphics card.
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Company Website: http://www.asiasoft.sg/
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 08:25 PM, Mr. Teo En Ming (Zhang Enming) wrote:
Hi All,
I have solved the problem encountered below when building tools for xen
3.5-unstable. The compile problem exists because I downloaded and compiled the
latest version of Intel ACPI Component Architecture compiler version 20090730.
And I used this latest compiler during "make tools" for xen-unstable.
In original xen-unstable source codes cloned from xensoure mercurial repository,
the header files ssdt_pm.h and ssdt_tpm.h in source directory
tools/firmware/hvmloader/acpi/ are generated by
/*
*
* Intel ACPI Component Architecture
* ASL Optimizing Compiler version 20061109 [May 18 2007]
* Copyright (C) 2000 - 2006 Intel Corporation
* Supports ACPI Specification Revision 3.0a
*
* Compilation of "ssdt_pm.asl" - Sun Oct 12 23:57:51 2008
*
* C source code output
*
*/
In original ssdt_pm.h, it has "unsigned char AmlCode_PM[] =".
In original ssdt_tpm.h, it has "unsigned char AmlCode_TPM[] =".
Hence there was no problem with "make tools".
But, I downloaded, compiled and used
/*
*
* Intel ACPI Component Architecture
* ASL Optimizing Compiler version 20090730 [Aug 29 2009]
* Copyright (C) 2000 - 2009 Intel Corporation
* Supports ACPI Specification Revision 4.0
*
* Compilation of "ssdt_pm.asl" - Sat Aug 29 18:55:40 2009
*
* C source code output
*
*/
So the *new* ssdt_pm.h contains:
/*
*
* Intel ACPI Component Architecture
* ASL Optimizing Compiler version 20090730 [Aug 29 2009]
* Copyright (C) 2000 - 2009 Intel Corporation
* Supports ACPI Specification Revision 4.0
*
* Compilation of "ssdt_pm.asl" - Sat Aug 29 18:55:40 2009
*
* C source code output
*
*/
unsigned char AmlCode[] {
0x53,0x53,0x44,0x54,0xD6,0x05,0x00,0x00, /* 00000000
"SSDT...." */
0x02,0xB9,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008
"..Xen..." */
0x48,0x56,0x4D,0x00,0x00,0x00,0x00,0x00, /* 00000010
"HVM....." */
0x00,0x00,0x00,0x00,0x49,0x4E,0x54,0x4C, /* 00000018
"....INTL" */
0x30,0x07,0x09,0x20,0x10,0x41,0x5B,0x5C, /* 00000020 "0..
.A[\" */
0x5F,0x53,0x42,0x5F,0x5B,0x80,0x44,0x42, /* 00000028
"_SB_[.DB" */
0x47,0x41,0x01,0x0B,0x40,0xB0,0x01,0x5B, /* 00000030
"GA..@..["<mailto:GA..@..%5B> */
0x81,0x0B,0x44,0x42,0x47,0x41,0x01,0x44, /* 00000038
"..DBGA.D" */
0x42,0x47,0x31,0x08,0x5B,0x80,0x44,0x42, /* 00000040
"BG1.[.DB" */
0x47,0x42,0x01,0x0B,0x44,0xB0,0x01,0x5B, /* 00000048
"GB..D..[" */
0x81,0x0B,0x44,0x42,0x47,0x42,0x01,0x44, /* 00000050
"..DBGB.D" */
0x42,0x47,0x32,0x08,0x5B,0x80,0x44,0x42, /* 00000058
"BG2.[.DB" */
0x47,0x43,0x01,0x0B,0x46,0xB0,0x01,0x5B, /* 00000060
"GC..F..[" */
0x81,0x0B,0x44,0x42,0x47,0x43,0x01,0x44, /* 00000068
"..DBGC.D" */
0x42,0x47,0x33,0x08,0x5B,0x80,0x44,0x42, /* 00000070
"BG3.[.DB" */
0x47,0x44,0x01,0x0B,0x48,0xB0,0x01,0x5B, /* 00000078
"GD..H..[" */
0x81,0x0B,0x44,0x42,0x47,0x44,0x01,0x44, /* 00000080
"..DBGD.D" */
0x42,0x47,0x34,0x08,0x5B,0x80,0x50,0x52, /* 00000088
"BG4.[.PR" */
0x54,0x31,0x01,0x0A,0xB2,0x0A,0x02,0x5B, /* 00000090
"T1.....[" */
0x81,0x10,0x50,0x52,0x54,0x31,0x01,0x50, /* 00000098
"..PRT1.P" */
0x42,0x32,0x5F,0x08,0x50,0x42,0x32,0x41, /* 000000A0
"B2_.PB2A" */
0x08,0x5B,0x80,0x50,0x52,0x54,0x32,0x01, /* 000000A8
".[.PRT2." */
0x0A,0x86,0x01,0x5B,0x81,0x0B,0x50,0x52, /* 000000B0
"...[..PR" */
0x54,0x32,0x01,0x50,0x38,0x36,0x5F,0x08, /* 000000B8
"T2.P86_." */
0x5B,0x80,0x50,0x52,0x54,0x33,0x01,0x0A, /* 000000C0
"[.PRT3.." */
0x88,0x01,0x5B,0x81,0x0B,0x50,0x52,0x54, /* 000000C8
"..[..PRT" */
0x33,0x01,0x50,0x38,0x38,0x5F,0x08,0x5B, /* 000000D0
"3.P88_.[" */
0x01,0x53,0x59,0x4E,0x43,0x01,0x08,0x42, /* 000000D8
".SYNC..B" */
0x55,0x46,0x30,0x11,0x04,0x0B,0x00,0x01, /* 000000E0
"UF0....." */
0x08,0x42,0x55,0x46,0x31,0x11,0x03,0x0A, /* 000000E8
".BUF1..." */
0x08,0x8B,0x42,0x55,0x46,0x31,0x00,0x42, /* 000000F0
"..BUF1.B" */
0x55,0x46,0x41,0x8B,0x42,0x55,0x46,0x31, /* 000000F8
"UFA.BUF1" */
0x0A,0x04,0x42,0x55,0x46,0x42,0x14,0x14, /* 00000100
"..BUFB.." */
And the *new* ssdt_tpm.h contains:
/*
*
* Intel ACPI Component Architecture
* ASL Optimizing Compiler version 20090730 [Aug 29 2009]
* Copyright (C) 2000 - 2009 Intel Corporation
* Supports ACPI Specification Revision 4.0
*
* Compilation of "ssdt_tpm.asl" - Sat Aug 29 18:55:40 2009
*
* C source code output
*
*/
unsigned char AmlCode[] {
0x53,0x53,0x44,0x54,0x4C,0x00,0x00,0x00, /* 00000000
"SSDTL..." */
0x02,0x2A,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008
".*Xen..." */
0x48,0x56,0x4D,0x00,0x00,0x00,0x00,0x00, /* 00000010
"HVM....." */
0x00,0x00,0x00,0x00,0x49,0x4E,0x54,0x4C, /* 00000018
"....INTL" */
0x30,0x07,0x09,0x20,0x5B,0x82,0x26,0x54, /* 00000020 "0..
[.&T" */
0x50,0x4D,0x5F,0x08,0x5F,0x48,0x49,0x44, /* 00000028
"PM_._HID" */
0x0C,0x41,0xD0,0x0C,0x31,0x08,0x5F,0x43, /* 00000030
".A..1._C" */
0x52,0x53,0x11,0x11,0x0A,0x0E,0x86,0x09, /* 00000038
"RS......" */
0x00,0x01,0x00,0x00,0xD4,0xFE,0x00,0x50, /* 00000040
".......P" */
0x00,0x00,0x79,0x00,
};
which are both wrong.
In ssdt_pm.h, I have to change "unsigned char AmlCode[]" to
"unsigned char AmlCode_PM[]".
In ssdt_tpm.h, I have to change "unsigned char AmlCode[]" to
"unsigned char AmlCode_TPM[]".
Then "make tools" is able to complete successfully.
I have created a patch for anybody who may be using the *latest* version of
Intel ACPI CA compiler version 20090730 and attached it here.
Patch file filename enming-patch04.patch:
<CODE>
Patch created by Teo En Ming (Zhang Enming) on 29 August 2009 Saturday at 8:00
P.M. Singapore Time
Email #1: enming.teo@asiasoftsea.net<mailto:enming.teo@asiasoftsea.net>
Email #2:
space.time.universe@gmail.com<mailto:space.time.universe@gmail.com>
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Mobile Phone: +65-9648-9798
--- ssdt_pm.h 2009-08-29 19:54:52.653088000 +0800
+++ ssdt_pm.h 2009-08-29 19:56:51.813088550 +0800
@@ -10,7 +10,7 @@
* C source code output
*
*/
-unsigned char AmlCode[] +unsigned char AmlCode_PM[] {
0x53,0x53,0x44,0x54,0xD6,0x05,0x00,0x00, /* 00000000
"SSDT...." */
0x02,0xB9,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008
"..Xen..." */
--- ssdt_tpm.h 2009-08-29 19:55:44.578738954 +0800
+++ ssdt_tpm.h 2009-08-29 19:57:27.896638884 +0800
@@ -10,7 +10,7 @@
* C source code output
*
*/
-unsigned char AmlCode[] +unsigned char AmlCode_TPM[] {
0x53,0x53,0x44,0x54,0x4C,0x00,0x00,0x00, /* 00000000
"SSDTL..." */
0x02,0x2A,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008
".*Xen..." */
</CODE>
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Company Website: http://www.asiasoft.sg/
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 07:03 PM, Mr. Teo En Ming (Zhang Enming) wrote:
Hi,
I cloned http://xenbits.xensource.com/xen-unstable.hg again today. I tried
applying the three Intel gfx passthrough patches to xen-unstable. When I
"make tools", I get the same error again:
make[7]: Entering directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader'
make -C acpi all
get-path: will use #!/usr/bin/python2.6 for python programs
make[8]: Entering directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'
make iasl
get-path: will use #!/usr/bin/python2.6 for python programs
make[9]: Entering directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'
make[9]: `/usr/local/bin/iasl' is up to date.
make[9]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'
iasl -tc ssdt_tpm.asl
Intel ACPI Component Architecture
ASL Optimizing Compiler version 20090730 [Aug 29 2009]
Copyright (C) 2000 - 2009 Intel Corporation
Supports ACPI Specification Revision 4.0
ASL Input: ssdt_tpm.asl - 31 lines, 1111 bytes, 3 keywords
AML Output: SSDT_TPM.aml - 76 bytes, 3 named objects, 0 executable opcodes
Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 0 Optimizations
mv ssdt_tpm.hex ssdt_tpm.h
rm -f *.aml
make iasl
get-path: will use #!/usr/bin/python2.6 for python programs
make[9]: Entering directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'
make[9]: `/usr/local/bin/iasl' is up to date.
make[9]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'
iasl -tc ssdt_pm.asl
Intel ACPI Component Architecture
ASL Optimizing Compiler version 20090730 [Aug 29 2009]
Copyright (C) 2000 - 2009 Intel Corporation
Supports ACPI Specification Revision 4.0
ASL Input: ssdt_pm.asl - 425 lines, 12754 bytes, 192 keywords
AML Output: SSDT_PM.aml - 1494 bytes, 64 named objects, 128 executable opcodes
Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 31 Optimizations
mv ssdt_pm.hex ssdt_pm.h
rm -f *.aml
gcc -O1 -fno-omit-frame-pointer -fno-optimize-sibling-calls -m32 -march=i686
-g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value
-Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .build.o.d
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs -Werror
-fno-stack-protector -fno-builtin -msoft-float -I. -I..
-I../../../../tools/include -c -o build.o build.c
In file included from build.c:21:
ssdt_pm.h:13: error: redefinition of ‘AmlCode’
ssdt_tpm.h:13: note: previous definition of ‘AmlCode’ was here
build.c: In function ‘construct_secondary_tables’:
build.c:184: error: ‘AmlCode_PM’ undeclared (first use in this function)
build.c:184: error: (Each undeclared identifier is reported only once
build.c:184: error: for each function it appears in.)
build.c:194: error: ‘AmlCode_TPM’ undeclared (first use in this function)
make[8]: *** [build.o] Error 1
make[8]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'
make[7]: *** [subdir-all-acpi] Error 2
make[7]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader'
make[6]: *** [subdirs-all] Error 2
make[6]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader'
make[5]: *** [subdir-all-hvmloader] Error 2
make[5]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware'
make[4]: *** [subdirs-all] Error 2
make[4]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware'
make[3]: *** [all] Error 2
make[3]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware'
make[2]: *** [subdir-install-firmware] Error 2
make[2]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools'
make: *** [install-tools] Error 2
Any ideas about this Advanced Configuration and Power Interface code?
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Company Website: http://www.asiasoft.sg/
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 02:58 PM, Mr. Teo En Ming (Zhang Enming) wrote:
Hi
Anybody available today? I know it's Saturday. :-)
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Company Website: http://www.asiasoft.sg/
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 11:48 AM, Mr. Teo En Ming (Zhang Enming) wrote:
Dear All,
After applying Intel VGA passthrough patches 1, 2 and 3, I have no problems with
"make xen", and "make install-xen". However, I have errors
with "make tools".
Here is the error output:
msoft-float -I. -I.. -I../../../../tools/include -c -o build.o build.c
build.c: In function ‘construct_secondary_tables’:
build.c:194: error: ‘AmlCode_TPM’ undeclared (first use in this function)
build.c:194: error: (Each undeclared identifier is reported only once
build.c:194: error: for each function it appears in.)
make[8]: *** [build.o] Error 1
make[8]: Leaving directory
`/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader/acpi'
make[7]: *** [subdir-all-acpi] Error 2
make[7]: Leaving directory
`/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader'
make[6]: *** [subdirs-all] Error 2
make[6]: Leaving directory
`/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader'
make[5]: *** [subdir-all-hvmloader] Error 2
make[5]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'
make[4]: *** [subdirs-all] Error 2
make[4]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'
make[2]: *** [subdir-install-firmware] Error 2
make[2]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools'
make: *** [install-tools] Error 2
There is an undeclared identifier in tools/firmware/hvmloader/acpi/build.c
source code. Could you guys help me resolve this issue?
I had no problems compiling xen 3.5-unstable before applying the Intel vga
passthrough patches and before installing the Intel ACPI Component Architecture
compiler.
I have also attached Intel graphics passthrough patches 1, 2 and 3 for your
convenience here.
Thank you very much.
Hope I can get this working during the weekends.
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Company Website: http://www.asiasoft.sg/
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 10:17 AM, Mr. Teo En Ming (Zhang Enming) wrote:
Hi Tim,
I thought it should be gfx_passthru=2 in domU config?
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 06:42 AM, Tim Moore wrote:
Teo,
I have also performed the same exercise as yourself and I now have successfully
compiled all 3x patches into Xen, Qemu and the BIOS File Loading in the
hvmloader, this all compiles find on my system. Suggest you do a "make
clean" on the tools and start again !
After booting with the patched xen-unstable and adding the gfx-passthru=1
parameter to my HVM DomU, as I suspected - it still doesn't work.
I have both a 9500GT and GTX260(primary) in my Intel DX58SO machine, tried
passing through either device and my primary display locks up ! (included hiding
with pci-stub)
I verified that the DomU was functional beforehand, as It also booted
successfully without the gfx-passthru parameter (and a vncviewer/cirrus display)
Unfortunately, I can't debug further as my Primary display corrupts as soon
as the DomU starts. I did notice that in "xm debug" the "Loading
Gfx BIOS File.." message was displayed and the DomU did continue to
initialise the BIOS tables and such before finally locking. I then (blindly)
typed on a corrupt Dom0 console and managed to start kdm and login, so the Dom0
was not completely trashed. But then after a few minutes, the machine totally
froze and had to hit the reset switch.
I`m no specialist but this looks like the VGA BIOS Re-initialisation is playing
havoc with the DomU and possibly the Dom0 graphics. I notice that both are also
using IRQ11 which could play a major part. Furthermore, there was a lot of debug
output in the qemu and xend.log indicating Base Address Register invalid access
and therefore it seems there may be a second obstacle.
Hope you have a better success than me !
For now, I would try re-compiling a fresh xen-unstable with carefully applied
patches .. oh! and don't forget to enable the pci-stub driver for Dom0
(it's not selected by default)
Tim
From:
xen-devel-bounces@lists.xensource.com<mailto:xen-devel-bounces@lists.xensource.com>
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Mr. Teo En Ming
(Zhang Enming)
Sent: 28 August 2009 21:14
To: enming.teo@asiasoftsea.net<mailto:enming.teo@asiasoftsea.net>
Cc: xen-devel@lists.xensource.com<mailto:xen-devel@lists.xensource.com>;
'Lin, Ben Y'; 'Kay, Allen M'; 'Jean Guyader';
Keir.Fraser@eu.citrix.com<mailto:Keir.Fraser@eu.citrix.com>;
weidong.han@intel.com<mailto:weidong.han@intel.com>;
bengheng@eecs.umich.edu<mailto:bengheng@eecs.umich.edu>
Subject: Re: [Xen-devel] [PATCH 2/2] graphics passthrough with VT-d
After applying the 1st and 2nd patch to xen-unstable successfully, I examined
the source codes Makefile and hvmloader.c in tools/firmware/hvmloader, compared
them to Weidong's 3rd patch and I generated my own 3rd patch. Then I used my
own generated 3rd patch to apply patching for loading vga bios from firmware
file.
Here is my own generated 3rd patch instead of using Weidong's 3rd patch:
--- Makefile 2009-08-29 03:24:52.413083774 +0800
+++ Makefile 2009-08-29 03:29:12.763299633 +0800
@@ -50,6 +50,7 @@
roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \
../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h
sh ./mkhex rombios ../rombios/BIOS-bochs-latest > roms.h
+ sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin >> roms.h
sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin >>
roms.h
sh ./mkhex vgabios_cirrusvga \
../vgabios/VGABIOS-lgpl-latest.cirrus.bin >> roms.h
--- hvmloader.c 2009-08-29 03:26:06.911085797 +0800
+++ hvmloader.c 2009-08-29 03:31:43.172084995 +0800
@@ -688,9 +688,9 @@
vgabios_sz = round_option_rom(sizeof(vgabios_stdvga));
break;
case VGA_pt:
- printf("Loading VGABIOS of passthroughed gfx ...\n");
- vgabios_sz
- round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512);
+ printf("Loading Gfx Video BIOS from file ...\n");
+ memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt,
sizeof(vgabios_pt));
+ vgabios_sz = round_option_rom(sizeof(vgabios_pt));
break;
default:
printf("No emulated VGA adaptor ...\n");
I can "make xen" successfully but when I proceeded to "make
tools", errors were encountered.
Please see attached error output. How can I solve this problem?
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 12:59 AM, Mr. Teo En Ming (Zhang Enming) wrote:
OK I believe the 3rd patch is not incomplete but there's a white space issue
when I copied the code from the mailing list into my vi.
See http://www.htdig.org/mail/2000/11/0167.html
When I used the -l flag to patch using the 3rd patch, the number of errors was
reduced.
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -l -p1 <
intel-gfx-passthru-patch-3.patch
patching file tools/firmware/hvmloader/Makefile
patching file tools/firmware/hvmloader/hvmloader.c
Hunk #1 FAILED at 688.
1 out of 1 hunk FAILED -- saving rejects to file
tools/firmware/hvmloader/hvmloader.c.rej
Now patching tools/firmware/hvmloader/Makefile is successful but patching
tools/firmware/hvmloader/hvmloader.c still failed.
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/28/2009 11:55 PM, Mr. Teo En Ming (Zhang Enming) wrote:
Dear Weidong,
A big big thanks for the vga passthrough patches for xen 3.5-unstable!!! These
are eagerly anticipated patches. As I did not study computer science and
computer architecture, I won't be able to write those patches you guys at
Intel wrote.
I applied the following patches
xen-gfx-passthrough.patch<http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin>
and
qemu-gfx-passthrough.patch<http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin>
to xen 3.5-unstable without issues.
Then I tried to apply the 3rd patch you provided at
http://lists.xensource.com/archives/html/xen-devel/2009-08/msg01047.html
I saved the following code
<CODE>
diff -r 494be76c1ad9 tools/firmware/hvmloader/Makefile
--- a/tools/firmware/hvmloader/Makefile Thu Aug 27 16:54:33 2009 +0800
+++ b/tools/firmware/hvmloader/Makefile Thu Aug 27 17:22:01 2009 +0800
@@ -50,6 +50,7 @@ roms.h: ../rombios/BIOS-bochs-latest ../
roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \
../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h
sh ./mkhex rombios ../rombios/BIOS-bochs-latest > roms.h
+ sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin >> roms.h
sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin >> roms.h
sh ./mkhex vgabios_cirrusvga \
../vgabios/VGABIOS-lgpl-latest.cirrus.bin >> roms.h
diff -r 494be76c1ad9 tools/firmware/hvmloader/hvmloader.c
--- a/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 16:54:33 2009 +0800
+++ b/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 17:23:00 2009 +0800
@@ -688,9 +688,9 @@ int main(void)
vgabios_sz = round_option_rom(sizeof(vgabios_stdvga));
break;
case VGA_pt:
- printf("Loading Gfx Video BIOS from 0xC0000 ...\n");
- vgabios_sz
- round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512);
+ printf("Loading Gfx Video BIOS from file ...\n");
+ memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt,
sizeof(vgabios_pt));
+ vgabios_sz = round_option_rom(sizeof(vgabios_pt));
break;
default:
printf("No emulated VGA adaptor ...\n");
</CODE>
as intel-gfx-passthru-patch-3.patch and then I tried to apply the patch to xen
3.5-unstable. I got errors. I think it's because the 3rd patch you provided
is incomplete.
Here's my patching process:
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name vgabios
./tools/firmware/vgabios
./.hg/store/data/tools/firmware/vgabios
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cp ~enming/vgabios-pt.bin
tools/firmware/vgabios/
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ls tools/firmware/vgabios/
biossums.c clext.c Makefile TODO vbe.h
vgabios.h vgatables.h
BUGS COPYING Notes vbe.c vbetables-gen.c
vgabios-pt.bin
ChangeLog dataseghack README vbe_display_api.txt vgabios.c
vgafonts.h
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# pwd
/usr/src/xen-unstable.hg-vgapt
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wget
http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin
--2009-08-28 23:18:21--
http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin
Resolving lists.xensource.com... 70.42.241.110
Connecting to lists.xensource.com|70.42.241.110|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 12565 (12K) [application/octet-stream]
Saving to: `bincPiiAf0QWg.bin'
100%[======================================================================>]
12,565 30.7K/s in 0.4s
2009-08-28 23:18:22 (30.7 KB/s) - `bincPiiAf0QWg.bin' saved [12565/12565]
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv bincPiiAf0QWg.bin
xen-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi xen-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch <
xen-gfx-passthrough.patch
can't find file to patch at input line 4
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff -r 5d7e7a250267 tools/firmware/hvmloader/config.h
|--- a/tools/firmware/hvmloader/config.h Wed Aug 26 18:28:44 2009 +0800
|+++ b/tools/firmware/hvmloader/config.h Thu Aug 27 16:54:24 2009 +0800
--------------------------
File to patch: ^C
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ex xen-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1 <
xen-gfx-passthrough.patch
patching file tools/firmware/hvmloader/config.h
patching file tools/firmware/hvmloader/hvmloader.c
patching file tools/libxc/ia64/xc_ia64_hvm_build.c
patching file tools/libxc/xc_hvm_build.c
patching file tools/libxc/xc_linux.c
patching file tools/libxc/xenctrl.h
patching file tools/libxc/xenguest.h
patching file tools/python/xen/lowlevel/xc/xc.c
patching file tools/python/xen/xend/XendConfig.py
Hunk #1 succeeded at 174 (offset -1 lines).
patching file tools/python/xen/xend/image.py
Hunk #1 succeeded at 780 (offset -6 lines).
Hunk #3 succeeded at 895 (offset -6 lines).
patching file tools/python/xen/xm/create.py
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wget
http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin
--2009-08-28 23:21:35--
http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin
Resolving lists.xensource.com... 70.42.241.110
Connecting to lists.xensource.com|70.42.241.110|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9841 (9.6K) [application/octet-stream]
Saving to: `binglLqkeq4Rj.bin'
100%[======================================================================>]
9,841 24.3K/s in 0.4s
2009-08-28 23:21:36 (24.3 KB/s) - `binglLqkeq4Rj.bin' saved [9841/9841]
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv binglLqkeq4Rj.bin
qemu-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi qemu-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name hw
./tools/ioemu-remote/hw
./.hg/store/data/tools/ioemu/hw
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv qemu-gfx-passthrough.patch
tools/ioemu-remote/
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cd tools/ioemu-remote/
[root@fedora11-x86-64-host ioemu-remote]# patch -p1 < qemu-
qemu-aio.h qemu-img.c qemu-sockets.c
qemu-binfmt-conf.sh qemu-img.texi qemu-tech.texi
qemu-char.c qemu-lock.h qemu-timer.h
qemu-char.h qemu-log.h qemu-tool.c
qemu-common.h qemu-malloc.c qemu-xen.h
qemu-doc.texi qemu-nbd.c
qemu-gfx-passthrough.patch qemu-nbd.texi
[root@fedora11-x86-64-host ioemu-remote]# patch -p1 <
qemu-gfx-passthrough.patch
patching file hw/pass-through.c
patching file hw/pass-through.h
patching file hw/pc.c
patching file vl.c
[root@fedora11-x86-64-host ioemu-remote]# cd ..
[root@fedora11-x86-64-host tools]# cd ..
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi
intel-gfx-passthru-patch-3.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1 <
intel-gfx-passthru-patch-3.patch
patching file tools/firmware/hvmloader/Makefile
Hunk #1 FAILED at 50.
1 out of 1 hunk FAILED -- saving rejects to file
tools/firmware/hvmloader/Makefile.rej
patching file tools/firmware/hvmloader/hvmloader.c
patch: **** malformed patch at line 24: sizeof(vgabios_pt));
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi
intel-gfx-passthru-patch-3.patch
For everybody's convenience, I have attached
intel-gfx-passthru-patch-3.patch and the firmware for my nVidia GeForce 8400 GS
PCI Express x16 graphics card in this email.
Please help me complete intel-gfx-passthru-patch-3.patch as I really need it.
Thank you very much!!!
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
This patch supports basic gfx passthrough on QEMU:
- disable emulated VGA adpater if there is passthroughed gfx
- register/unregister legacy VGA I/O ports and MMIOs for passthroughed gfx
Signed-off-by: Ben Lin
<ben.y.lin@intel.com><mailto:ben.y.lin@intel.com>
Signed-off-by: Weidong Han
<weidong.han@intel.com><mailto:weidong.han@intel.com>
No virus found in this incoming message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 8.5.409 / Virus Database: 270.13.69/2328 - Release Date: 08/27/09
18:02:00
No virus found in this outgoing message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 8.5.409 / Virus Database: 270.13.71/2330 - Release Date: 08/27/09
18:02:00
________________________________
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com<mailto:Xen-devel@lists.xensource.com>
http://lists.xensource.com/xen-devel
________________________________
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com<mailto:Xen-devel@lists.xensource.com>
http://lists.xensource.com/xen-devel
________________________________
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com<mailto: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
Mr. Teo En Ming (Zhang Enming)
2009-Aug-31 14:54 UTC
Re: [Xen-devel] graphics passthrough with VT-d
Dear Weidong, Thank you for releasing the experimental patches for vga passthrough. I have patched xen-unstable with your initial 2 patches and the patches which you released today. However, it can''t work. It caused my Dom 0 to crash and Dom U cannot start. -- Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) Technical Support Engineer Information Technology Department Asiasoft Online Pte Ltd Tampines Central 1 #04-01 Tampines Plaza Singapore 529541 Republic of Singapore Company Website: http://www.asiasoft.sg/ Mobile: +65-9648-9798 MSN: teoenming@hotmail.com Alma Maters: Singapore Polytechnic, National University of Singapore On 08/31/2009 04:47 PM, Han, Weidong wrote:> Teo, > I attached some experimental patches for you to try to sthorugh > Geforce 8400 GS. > Based on my patches posted last Friday, pls follow below instructions: > 1. apply xen-load-vbios-file.patch to xen-unstable.hg > this patch supports to load vga bios from a file. > 2. apply xen-vBAR-pBAR.patch to xen-unstable.hg > this patch is used to 1:1 map between vBAR and pBAR > 3. apply qemu-change-for-vBAR-pBAR.patch to ioemu-remote (qemu tree). > this patch is used to 1:1 map between vBAR and pBAR on qemu side > 4. apply qemu-claim-cycle-for-secondary-gfx-passthrough.patch > it''s needed if you want to assign the secondary gfx to guest. > 5. cd xen-unstable.hg > 6. make clean > 7. copy the vga bios file to > xen-unstabl.hg/tools/firmware/vgabios/vgabios-pt.bin > 8. make; make install > 9. reboot the system. or xend restart. then passthrough gfx to guest ... > Regards, > Weidong > > ------------------------------------------------------------------------ > *From:* xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] *On Behalf Of *Mr. Teo > En Ming (Zhang Enming) > *Sent:* 2009年8月29日 22:13 > *To:* timothy.moore@expidas.net > *Cc:* xen-devel@lists.xensource.com > *Subject:* Re: [Xen-devel] graphics passthrough with VT-d > > Hi Timothy, > > Yes, I renamed the firmware file of nVidia Geforce 8400 GS to > vgabios-pt.bin and placed it in the source directory > tools/firmware/vgabios. > > Weidong had said Intel has the 1:1 mapping patches. Let''s hope he will > release the patch soon to do pBAR:vBAR. > > -- > Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) > Technical Support Engineer > Information Technology Department > Asiasoft Online Pte Ltd > Tampines Central 1 #04-01 Tampines Plaza > Singapore 529541 > Republic of Singapore > Company Website: http://www.asiasoft.sg/ > Mobile: +65-9648-9798 > MSN: teoenming@hotmail.com > Alma Maters: Singapore Polytechnic, National University of Singapore > > > On 08/29/2009 09:29 PM, Tim Moore wrote: >> >> Teo, >> >> Did you rename your Nvidia BIOS and copy it into the hvmloader source >> tree as required ? >> >> It should get compiled into roms.h in the hvmloader folder - I made >> sure it was there as the xen buildroot seems to delete it randomly ... >> >> I think we are now up against the Base Address Register issue where >> the Nvidia driver is expecting to see the card at the Physical BAR >> Addresses and in the DomU these are re-mapped to different address >> space ... this is a problem with the Nvidia binary driver and >> therefore a workaround in xen is maybe needed. >> >> That said, I''m not sure if the Nvidia BIOS likes to be re-executed >> and may also be an issue ... >> >> Tim >> >> *From:* Mr. Teo En Ming (Zhang Enming) >> [mailto:enming.teo@asiasoftsea.net] >> *Sent:* 29 August 2009 14:21 >> *To:* enming.teo@asiasoftsea.net >> *Cc:* Tim Moore; xen-devel@lists.xensource.com >> *Subject:* Re: [Xen-devel] graphics passthrough with VT-d >> >> Dear All, >> >> I have applied the following patches to xen 3.5-unstable >> >> 1) intel-gfx-passthru-patch01.patch >> 2) intel-gfx-passthru-patch02.patch >> 3) intel-gfx-passthru-patch03.patch >> 4) enming-patch04.patch >> >> and compiled xen 3.5-unstable successfully (both hypervisor and tools). >> >> i rebooted into this newly compiled Xen hypervisor which supports >> loading vga bios from firmware file of nVidia Geforce 8400 GS PCI >> Express x16. >> >> After dom0 has booted up, I executed the following script to hide >> nVidia Geforce 8400 GS from dom0. >> >> [enming@fedora11-x86-64-host scripts]$ cat bind-devices-pci-stub.sh >> #!/bin/sh >> echo "10de 06e4" > /sys/bus/pci/drivers/pci-stub/new_id >> echo "0000:01:00.0" > /sys/bus/pci/devices/0000:01:00.0/driver/unbind >> echo "0000:01:00.0" > /sys/bus/pci/drivers/pci-stub/bind >> >> I also assigned the nVidia Geforce 8400 GS to my Windows XP Home HVM >> domU. >> >> pci = [ ''01:00.0'' ] >> >> I also specified gfx_passthru=2. >> >> Do note that I booted up with onboard Intel GMA4500 as the primary >> video adapter. Hence dom 0 has onboard graphics and Windows XP HVM >> domU has nvidia graphics. >> >> Then I started Windows XP Home HVM DomU. >> >> Very soon, my Dom 0''s display was garbaged and X server on Dom 0 >> totally froze and became unresponsive. I cannot switch to any ttys. >> >> However, I was still able to vnc into my Windows XP Home HVM Dom U. I >> had earlier installed a VNC server into my Windows XP guest. After >> remoting in to my Windows XP DomU through vnc, I found that NVIDIA >> Geforce 8400 GS cannot be initialized and no resources are available >> for this graphics card. >> >> >> -- >> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >> Technical Support Engineer >> Information Technology Department >> Asiasoft Online Pte Ltd >> Tampines Central 1 #04-01 Tampines Plaza >> Singapore 529541 >> Republic of Singapore >> Company Website: http://www.asiasoft.sg/ >> Mobile: +65-9648-9798 >> MSN: teoenming@hotmail.com <mailto:teoenming@hotmail.com> >> Alma Maters: Singapore Polytechnic, National University of Singapore >> >> >> >> On 08/29/2009 08:25 PM, Mr. Teo En Ming (Zhang Enming) wrote: >> >> Hi All, >> >> I have solved the problem encountered below when building tools for >> xen 3.5-unstable. The compile problem exists because I downloaded and >> compiled the latest version of Intel ACPI Component Architecture >> compiler version 20090730. And I used this latest compiler during >> "make tools" for xen-unstable. >> >> In original xen-unstable source codes cloned from xensoure mercurial >> repository, the header files ssdt_pm.h and ssdt_tpm.h in source >> directory tools/firmware/hvmloader/acpi/ are generated by >> >> /* >> * >> * Intel ACPI Component Architecture >> * ASL Optimizing Compiler version 20061109 [May 18 2007] >> * Copyright (C) 2000 - 2006 Intel Corporation >> * Supports ACPI Specification Revision 3.0a >> * >> * Compilation of "ssdt_pm.asl" - Sun Oct 12 23:57:51 2008 >> * >> * C source code output >> * >> */ >> >> In original ssdt_pm.h, it has "unsigned char AmlCode_PM[] =". >> >> In original ssdt_tpm.h, it has "unsigned char AmlCode_TPM[] =". >> >> Hence there was no problem with "make tools". >> >> But, I downloaded, compiled and used >> >> /* >> * >> * Intel ACPI Component Architecture >> * ASL Optimizing Compiler version 20090730 [Aug 29 2009] >> * Copyright (C) 2000 - 2009 Intel Corporation >> * Supports ACPI Specification Revision 4.0 >> * >> * Compilation of "ssdt_pm.asl" - Sat Aug 29 18:55:40 2009 >> * >> * C source code output >> * >> */ >> >> So the *new* ssdt_pm.h contains: >> >> /* >> * >> * Intel ACPI Component Architecture >> * ASL Optimizing Compiler version 20090730 [Aug 29 2009] >> * Copyright (C) 2000 - 2009 Intel Corporation >> * Supports ACPI Specification Revision 4.0 >> * >> * Compilation of "ssdt_pm.asl" - Sat Aug 29 18:55:40 2009 >> * >> * C source code output >> * >> */ >> unsigned char AmlCode[] >> { >> 0x53,0x53,0x44,0x54,0xD6,0x05,0x00,0x00, /* 00000000 "SSDT...." */ >> 0x02,0xB9,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008 "..Xen..." */ >> 0x48,0x56,0x4D,0x00,0x00,0x00,0x00,0x00, /* 00000010 "HVM....." */ >> 0x00,0x00,0x00,0x00,0x49,0x4E,0x54,0x4C, /* 00000018 "....INTL" */ >> 0x30,0x07,0x09,0x20,0x10,0x41,0x5B,0x5C, /* 00000020 "0.. .A[\" */ >> 0x5F,0x53,0x42,0x5F,0x5B,0x80,0x44,0x42, /* 00000028 "_SB_[.DB" */ >> 0x47,0x41,0x01,0x0B,0x40,0xB0,0x01,0x5B, /* 00000030 "GA..@..[" >> <mailto:GA..@..%5B> */ >> 0x81,0x0B,0x44,0x42,0x47,0x41,0x01,0x44, /* 00000038 "..DBGA.D" */ >> 0x42,0x47,0x31,0x08,0x5B,0x80,0x44,0x42, /* 00000040 "BG1.[.DB" */ >> 0x47,0x42,0x01,0x0B,0x44,0xB0,0x01,0x5B, /* 00000048 "GB..D..[" */ >> 0x81,0x0B,0x44,0x42,0x47,0x42,0x01,0x44, /* 00000050 "..DBGB.D" */ >> 0x42,0x47,0x32,0x08,0x5B,0x80,0x44,0x42, /* 00000058 "BG2.[.DB" */ >> 0x47,0x43,0x01,0x0B,0x46,0xB0,0x01,0x5B, /* 00000060 "GC..F..[" */ >> 0x81,0x0B,0x44,0x42,0x47,0x43,0x01,0x44, /* 00000068 "..DBGC.D" */ >> 0x42,0x47,0x33,0x08,0x5B,0x80,0x44,0x42, /* 00000070 "BG3.[.DB" */ >> 0x47,0x44,0x01,0x0B,0x48,0xB0,0x01,0x5B, /* 00000078 "GD..H..[" */ >> 0x81,0x0B,0x44,0x42,0x47,0x44,0x01,0x44, /* 00000080 "..DBGD.D" */ >> 0x42,0x47,0x34,0x08,0x5B,0x80,0x50,0x52, /* 00000088 "BG4.[.PR" */ >> 0x54,0x31,0x01,0x0A,0xB2,0x0A,0x02,0x5B, /* 00000090 "T1.....[" */ >> 0x81,0x10,0x50,0x52,0x54,0x31,0x01,0x50, /* 00000098 "..PRT1.P" */ >> 0x42,0x32,0x5F,0x08,0x50,0x42,0x32,0x41, /* 000000A0 "B2_.PB2A" */ >> 0x08,0x5B,0x80,0x50,0x52,0x54,0x32,0x01, /* 000000A8 ".[.PRT2." */ >> 0x0A,0x86,0x01,0x5B,0x81,0x0B,0x50,0x52, /* 000000B0 "...[..PR" */ >> 0x54,0x32,0x01,0x50,0x38,0x36,0x5F,0x08, /* 000000B8 "T2.P86_." */ >> 0x5B,0x80,0x50,0x52,0x54,0x33,0x01,0x0A, /* 000000C0 "[.PRT3.." */ >> 0x88,0x01,0x5B,0x81,0x0B,0x50,0x52,0x54, /* 000000C8 "..[..PRT" */ >> 0x33,0x01,0x50,0x38,0x38,0x5F,0x08,0x5B, /* 000000D0 "3.P88_.[" */ >> 0x01,0x53,0x59,0x4E,0x43,0x01,0x08,0x42, /* 000000D8 ".SYNC..B" */ >> 0x55,0x46,0x30,0x11,0x04,0x0B,0x00,0x01, /* 000000E0 "UF0....." */ >> 0x08,0x42,0x55,0x46,0x31,0x11,0x03,0x0A, /* 000000E8 ".BUF1..." */ >> 0x08,0x8B,0x42,0x55,0x46,0x31,0x00,0x42, /* 000000F0 "..BUF1.B" */ >> 0x55,0x46,0x41,0x8B,0x42,0x55,0x46,0x31, /* 000000F8 "UFA.BUF1" */ >> 0x0A,0x04,0x42,0x55,0x46,0x42,0x14,0x14, /* 00000100 "..BUFB.." */ >> >> And the *new* ssdt_tpm.h contains: >> >> /* >> * >> * Intel ACPI Component Architecture >> * ASL Optimizing Compiler version 20090730 [Aug 29 2009] >> * Copyright (C) 2000 - 2009 Intel Corporation >> * Supports ACPI Specification Revision 4.0 >> * >> * Compilation of "ssdt_tpm.asl" - Sat Aug 29 18:55:40 2009 >> * >> * C source code output >> * >> */ >> unsigned char AmlCode[] >> { >> 0x53,0x53,0x44,0x54,0x4C,0x00,0x00,0x00, /* 00000000 "SSDTL..." */ >> 0x02,0x2A,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008 ".*Xen..." */ >> 0x48,0x56,0x4D,0x00,0x00,0x00,0x00,0x00, /* 00000010 "HVM....." */ >> 0x00,0x00,0x00,0x00,0x49,0x4E,0x54,0x4C, /* 00000018 "....INTL" */ >> 0x30,0x07,0x09,0x20,0x5B,0x82,0x26,0x54, /* 00000020 "0.. [.&T" */ >> 0x50,0x4D,0x5F,0x08,0x5F,0x48,0x49,0x44, /* 00000028 "PM_._HID" */ >> 0x0C,0x41,0xD0,0x0C,0x31,0x08,0x5F,0x43, /* 00000030 ".A..1._C" */ >> 0x52,0x53,0x11,0x11,0x0A,0x0E,0x86,0x09, /* 00000038 "RS......" */ >> 0x00,0x01,0x00,0x00,0xD4,0xFE,0x00,0x50, /* 00000040 ".......P" */ >> 0x00,0x00,0x79,0x00, >> }; >> >> which are both wrong. >> >> In ssdt_pm.h, I have to change "unsigned char AmlCode[]" to "unsigned >> char AmlCode_PM[]". >> >> In ssdt_tpm.h, I have to change "unsigned char AmlCode[]" to >> "unsigned char AmlCode_TPM[]". >> >> Then "make tools" is able to complete successfully. >> >> I have created a patch for anybody who may be using the *latest* >> version of Intel ACPI CA compiler version 20090730 and attached it here. >> >> Patch file filename enming-patch04.patch: >> >> <CODE> >> >> Patch created by Teo En Ming (Zhang Enming) on 29 August 2009 >> Saturday at 8:00 P.M. Singapore Time >> Email #1: enming.teo@asiasoftsea.net <mailto:enming.teo@asiasoftsea.net> >> Email #2: space.time.universe@gmail.com >> <mailto:space.time.universe@gmail.com> >> MSN: teoenming@hotmail.com <mailto:teoenming@hotmail.com> >> Mobile Phone: +65-9648-9798 >> >> --- ssdt_pm.h 2009-08-29 19:54:52.653088000 +0800 >> +++ ssdt_pm.h 2009-08-29 19:56:51.813088550 +0800 >> @@ -10,7 +10,7 @@ >> * C source code output >> * >> */ >> -unsigned char AmlCode[] >> +unsigned char AmlCode_PM[] >> { >> 0x53,0x53,0x44,0x54,0xD6,0x05,0x00,0x00, /* 00000000 "SSDT...." */ >> 0x02,0xB9,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008 "..Xen..." */ >> --- ssdt_tpm.h 2009-08-29 19:55:44.578738954 +0800 >> +++ ssdt_tpm.h 2009-08-29 19:57:27.896638884 +0800 >> @@ -10,7 +10,7 @@ >> * C source code output >> * >> */ >> -unsigned char AmlCode[] >> +unsigned char AmlCode_TPM[] >> { >> 0x53,0x53,0x44,0x54,0x4C,0x00,0x00,0x00, /* 00000000 "SSDTL..." */ >> 0x02,0x2A,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008 ".*Xen..." */ >> >> </CODE> >> >> >> -- >> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >> Technical Support Engineer >> Information Technology Department >> Asiasoft Online Pte Ltd >> Tampines Central 1 #04-01 Tampines Plaza >> Singapore 529541 >> Republic of Singapore >> Company Website: http://www.asiasoft.sg/ >> Mobile: +65-9648-9798 >> MSN: teoenming@hotmail.com <mailto:teoenming@hotmail.com> >> Alma Maters: Singapore Polytechnic, National University of Singapore >> >> >> >> On 08/29/2009 07:03 PM, Mr. Teo En Ming (Zhang Enming) wrote: >> >> Hi, >> >> I cloned http://xenbits.xensource.com/xen-unstable.hg again today. I tried applying the three Intel gfx passthrough patches to xen-unstable. When I "make tools", I get the same error again: >> >> make[7]: Entering directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader'' >> make -C acpi all >> get-path: will use #!/usr/bin/python2.6 for python programs >> make[8]: Entering directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' >> make iasl >> get-path: will use #!/usr/bin/python2.6 for python programs >> make[9]: Entering directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' >> make[9]: `/usr/local/bin/iasl'' is up to date. >> make[9]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' >> iasl -tc ssdt_tpm.asl >> >> Intel ACPI Component Architecture >> ASL Optimizing Compiler version 20090730 [Aug 29 2009] >> Copyright (C) 2000 - 2009 Intel Corporation >> Supports ACPI Specification Revision 4.0 >> >> ASL Input: ssdt_tpm.asl - 31 lines, 1111 bytes, 3 keywords >> AML Output: SSDT_TPM.aml - 76 bytes, 3 named objects, 0 executable opcodes >> >> Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 0 Optimizations >> mv ssdt_tpm.hex ssdt_tpm.h >> rm -f *.aml >> make iasl >> get-path: will use #!/usr/bin/python2.6 for python programs >> make[9]: Entering directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' >> make[9]: `/usr/local/bin/iasl'' is up to date. >> make[9]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' >> iasl -tc ssdt_pm.asl >> >> Intel ACPI Component Architecture >> ASL Optimizing Compiler version 20090730 [Aug 29 2009] >> Copyright (C) 2000 - 2009 Intel Corporation >> Supports ACPI Specification Revision 4.0 >> >> ASL Input: ssdt_pm.asl - 425 lines, 12754 bytes, 192 keywords >> AML Output: SSDT_PM.aml - 1494 bytes, 64 named objects, 128 executable opcodes >> >> Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 31 Optimizations >> mv ssdt_pm.hex ssdt_pm.h >> rm -f *.aml >> gcc -O1 -fno-omit-frame-pointer -fno-optimize-sibling-calls -m32 -march=i686 -g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value -Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .build.o.d -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs -Werror -fno-stack-protector -fno-builtin -msoft-float -I. -I.. -I../../../../tools/include -c -o build.o build.c >> In file included from build.c:21: >> ssdt_pm.h:13: error: redefinition of ‘AmlCode’ >> ssdt_tpm.h:13: note: previous definition of ‘AmlCode’ was here >> build.c: In function ‘construct_secondary_tables’: >> build.c:184: error: ‘AmlCode_PM’ undeclared (first use in this function) >> build.c:184: error: (Each undeclared identifier is reported only once >> build.c:184: error: for each function it appears in.) >> build.c:194: error: ‘AmlCode_TPM’ undeclared (first use in this function) >> make[8]: *** [build.o] Error 1 >> make[8]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'' >> make[7]: *** [subdir-all-acpi] Error 2 >> make[7]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader'' >> make[6]: *** [subdirs-all] Error 2 >> make[6]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader'' >> make[5]: *** [subdir-all-hvmloader] Error 2 >> make[5]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware'' >> make[4]: *** [subdirs-all] Error 2 >> make[4]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware'' >> make[3]: *** [all] Error 2 >> make[3]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools/firmware'' >> make[2]: *** [subdir-install-firmware] Error 2 >> make[2]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools'' >> make[1]: *** [subdirs-install] Error 2 >> make[1]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools'' >> make: *** [install-tools] Error 2 >> >> Any ideas about this Advanced Configuration and Power Interface code? >> >> -- >> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >> Technical Support Engineer >> Information Technology Department >> Asiasoft Online Pte Ltd >> Tampines Central 1 #04-01 Tampines Plaza >> Singapore 529541 >> Republic of Singapore >> Company Website: http://www.asiasoft.sg/ >> Mobile: +65-9648-9798 >> MSN: teoenming@hotmail.com <mailto:teoenming@hotmail.com> >> Alma Maters: Singapore Polytechnic, National University of Singapore >> >> >> >> On 08/29/2009 02:58 PM, Mr. Teo En Ming (Zhang Enming) wrote: >> >> Hi >> >> Anybody available today? I know it''s Saturday. :-) >> >> >> -- >> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >> Technical Support Engineer >> Information Technology Department >> Asiasoft Online Pte Ltd >> Tampines Central 1 #04-01 Tampines Plaza >> Singapore 529541 >> Republic of Singapore >> Company Website: http://www.asiasoft.sg/ >> Mobile: +65-9648-9798 >> MSN: teoenming@hotmail.com <mailto:teoenming@hotmail.com> >> Alma Maters: Singapore Polytechnic, National University of Singapore >> >> >> >> On 08/29/2009 11:48 AM, Mr. Teo En Ming (Zhang Enming) wrote: >> >> >> >> Dear All, >> >> After applying Intel VGA passthrough patches 1, 2 and 3, I have no problems with "make xen", and "make install-xen". However, I have errors with "make tools". >> >> Here is the error output: >> >> msoft-float -I. -I.. -I../../../../tools/include -c -o build.o build.c >> build.c: In function ‘construct_secondary_tables’: >> build.c:194: error: ‘AmlCode_TPM’ undeclared (first use in this function) >> build.c:194: error: (Each undeclared identifier is reported only once >> build.c:194: error: for each function it appears in.) >> make[8]: *** [build.o] Error 1 >> make[8]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader/acpi'' >> make[7]: *** [subdir-all-acpi] Error 2 >> make[7]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader'' >> make[6]: *** [subdirs-all] Error 2 >> make[6]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader'' >> make[5]: *** [subdir-all-hvmloader] Error 2 >> make[5]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'' >> make[4]: *** [subdirs-all] Error 2 >> make[4]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'' >> make[3]: *** [all] Error 2 >> make[3]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'' >> make[2]: *** [subdir-install-firmware] Error 2 >> make[2]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools'' >> make[1]: *** [subdirs-install] Error 2 >> make[1]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools'' >> make: *** [install-tools] Error 2 >> >> There is an undeclared identifier in tools/firmware/hvmloader/acpi/build.c source code. Could you guys help me resolve this issue? >> >> I had no problems compiling xen 3.5-unstable before applying the Intel vga passthrough patches and before installing the Intel ACPI Component Architecture compiler. >> >> I have also attached Intel graphics passthrough patches 1, 2 and 3 for your convenience here. >> >> Thank you very much. >> >> Hope I can get this working during the weekends. >> >> -- >> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >> Technical Support Engineer >> Information Technology Department >> Asiasoft Online Pte Ltd >> Tampines Central 1 #04-01 Tampines Plaza >> Singapore 529541 >> Republic of Singapore >> Company Website: http://www.asiasoft.sg/ >> Mobile: +65-9648-9798 >> MSN: teoenming@hotmail.com <mailto:teoenming@hotmail.com> >> Alma Maters: Singapore Polytechnic, National University of Singapore >> >> >> >> On 08/29/2009 10:17 AM, Mr. Teo En Ming (Zhang Enming) wrote: >> >> Hi Tim, >> >> I thought it should be gfx_passthru=2 in domU config? >> >> -- >> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >> Technical Support Engineer >> Information Technology Department >> Asiasoft Online Pte Ltd >> Tampines Central 1 #04-01 Tampines Plaza >> Singapore 529541 >> Republic of Singapore >> Mobile: +65-9648-9798 >> MSN: teoenming@hotmail.com <mailto:teoenming@hotmail.com> >> Alma Maters: Singapore Polytechnic, National University of Singapore >> >> >> >> On 08/29/2009 06:42 AM, Tim Moore wrote: >> >> Teo, >> >> I have also performed the same exercise as yourself and I now have >> successfully compiled all 3x patches into Xen, Qemu and the BIOS File >> Loading in the hvmloader, this all compiles find on my system. >> Suggest you do a "make clean" on the tools and start again ! >> >> After booting with the patched xen-unstable and adding the >> gfx-passthru=1 parameter to my HVM DomU, as I suspected - it still >> doesn''t work. >> >> I have both a 9500GT and GTX260(primary) in my Intel DX58SO machine, >> tried passing through either device and my primary display locks up ! >> (included hiding with pci-stub) >> >> I verified that the DomU was functional beforehand, as It also booted >> successfully without the gfx-passthru parameter (and a >> vncviewer/cirrus display) >> >> Unfortunately, I can''t debug further as my Primary display corrupts >> as soon as the DomU starts. I did notice that in "xm debug" the >> "Loading Gfx BIOS File.." message was displayed and the DomU did >> continue to initialise the BIOS tables and such before finally >> locking. I then (blindly) typed on a corrupt Dom0 console and managed >> to start kdm and login, so the Dom0 was not completely trashed. But >> then after a few minutes, the machine totally froze and had to hit >> the reset switch. >> >> I`m no specialist but this looks like the VGA BIOS Re-initialisation >> is playing havoc with the DomU and possibly the Dom0 graphics. I >> notice that both are also using IRQ11 which could play a major part. >> Furthermore, there was a lot of debug output in the qemu and xend.log >> indicating Base Address Register invalid access and therefore it >> seems there may be a second obstacle. >> >> Hope you have a better success than me ! >> >> For now, I would try re-compiling a fresh xen-unstable with carefully >> applied patches .. oh! and don''t forget to enable the pci-stub driver >> for Dom0 (it''s not selected by default) >> >> Tim >> >> *From:* xen-devel-bounces@lists.xensource.com >> <mailto:xen-devel-bounces@lists.xensource.com> >> [mailto:xen-devel-bounces@lists.xensource.com] *On Behalf Of *Mr. Teo >> En Ming (Zhang Enming) >> *Sent:* 28 August 2009 21:14 >> *To:* enming.teo@asiasoftsea.net <mailto:enming.teo@asiasoftsea.net> >> *Cc:* xen-devel@lists.xensource.com >> <mailto:xen-devel@lists.xensource.com>; ''Lin, Ben Y''; ''Kay, Allen M''; >> ''Jean Guyader''; Keir.Fraser@eu.citrix.com >> <mailto:Keir.Fraser@eu.citrix.com>; weidong.han@intel.com >> <mailto:weidong.han@intel.com>; bengheng@eecs.umich.edu >> <mailto:bengheng@eecs.umich.edu> >> *Subject:* Re: [Xen-devel] [PATCH 2/2] graphics passthrough with VT-d >> >> After applying the 1st and 2nd patch to xen-unstable successfully, I examined the source codes Makefile and hvmloader.c in tools/firmware/hvmloader, compared them to Weidong''s 3rd patch and I generated my own 3rd patch. Then I used my own generated 3rd patch to apply patching for loading vga bios from firmware file. >> >> Here is my own generated 3rd patch instead of using Weidong''s 3rd patch: >> >> --- Makefile 2009-08-29 03:24:52.413083774 +0800 >> +++ Makefile 2009-08-29 03:29:12.763299633 +0800 >> @@ -50,6 +50,7 @@ >> roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \ >> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h >> sh ./mkhex rombios ../rombios/BIOS-bochs-latest > roms.h >> + sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin >> roms.h >> sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin >> roms.h >> sh ./mkhex vgabios_cirrusvga \ >> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin >> roms.h >> --- hvmloader.c 2009-08-29 03:26:06.911085797 +0800 >> +++ hvmloader.c 2009-08-29 03:31:43.172084995 +0800 >> @@ -688,9 +688,9 @@ >> vgabios_sz = round_option_rom(sizeof(vgabios_stdvga)); >> break; >> case VGA_pt: >> - printf("Loading VGABIOS of passthroughed gfx ...\n"); >> - vgabios_sz >> - round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512); >> + printf("Loading Gfx Video BIOS from file ...\n"); >> + memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt, sizeof(vgabios_pt)); >> + vgabios_sz = round_option_rom(sizeof(vgabios_pt)); >> break; >> default: >> printf("No emulated VGA adaptor ...\n"); >> >> >> I can "make xen" successfully but when I proceeded to "make tools", errors were encountered. >> >> Please see attached error output. How can I solve this problem? >> >> >> -- >> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >> Technical Support Engineer >> Information Technology Department >> Asiasoft Online Pte Ltd >> Tampines Central 1 #04-01 Tampines Plaza >> Singapore 529541 >> Republic of Singapore >> Mobile: +65-9648-9798 >> MSN: teoenming@hotmail.com <mailto:teoenming@hotmail.com> >> Alma Maters: Singapore Polytechnic, National University of Singapore >> >> >> >> On 08/29/2009 12:59 AM, Mr. Teo En Ming (Zhang Enming) wrote: >> >> OK I believe the 3rd patch is not incomplete but there''s a white space issue when I copied the code from the mailing list into my vi. >> >> See http://www.htdig.org/mail/2000/11/0167.html >> >> When I used the -l flag to patch using the 3rd patch, the number of errors was reduced. >> >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -l -p1 < intel-gfx-passthru-patch-3.patch >> patching file tools/firmware/hvmloader/Makefile >> patching file tools/firmware/hvmloader/hvmloader.c >> Hunk #1 FAILED at 688. >> 1 out of 1 hunk FAILED -- saving rejects to file tools/firmware/hvmloader/hvmloader.c.rej >> >> Now patching tools/firmware/hvmloader/Makefile is successful but patching tools/firmware/hvmloader/hvmloader.c still failed. >> >> -- >> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >> Technical Support Engineer >> Information Technology Department >> Asiasoft Online Pte Ltd >> Tampines Central 1 #04-01 Tampines Plaza >> Singapore 529541 >> Republic of Singapore >> Mobile: +65-9648-9798 >> MSN: teoenming@hotmail.com <mailto:teoenming@hotmail.com> >> Alma Maters: Singapore Polytechnic, National University of Singapore >> >> >> >> >> On 08/28/2009 11:55 PM, Mr. Teo En Ming (Zhang Enming) wrote: >> >> Dear Weidong, >> >> A big big thanks for the vga passthrough patches for xen >> 3.5-unstable!!! These are eagerly anticipated patches. As I did not >> study computer science and computer architecture, I won''t be able to >> write those patches you guys at Intel wrote. >> >> I applied the following patches *xen-gfx-passthrough.patch >> <http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin> >> and qemu-gfx-passthrough.patch >> <http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin> >> to xen 3.5-unstable without issues.* >> >> Then I tried to apply the 3rd patch you provided at >> http://lists.xensource.com/archives/html/xen-devel/2009-08/msg01047.html >> >> I saved the following code >> >> <CODE> >> >> diff -r 494be76c1ad9 tools/firmware/hvmloader/Makefile >> --- a/tools/firmware/hvmloader/Makefile Thu Aug 27 16:54:33 2009 +0800 >> +++ b/tools/firmware/hvmloader/Makefile Thu Aug 27 17:22:01 2009 +0800 >> @@ -50,6 +50,7 @@ roms.h: ../rombios/BIOS-bochs-latest ../ >> roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \ >> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h >> sh ./mkhex rombios ../rombios/BIOS-bochs-latest > roms.h >> + sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin >> roms.h >> sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin >> roms.h >> sh ./mkhex vgabios_cirrusvga \ >> ../vgabios/VGABIOS-lgpl-latest.cirrus.bin >> roms.h >> diff -r 494be76c1ad9 tools/firmware/hvmloader/hvmloader.c >> --- a/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 16:54:33 2009 +0800 >> +++ b/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 17:23:00 2009 +0800 >> @@ -688,9 +688,9 @@ int main(void) >> vgabios_sz = round_option_rom(sizeof(vgabios_stdvga)); >> break; >> case VGA_pt: >> - printf("Loading Gfx Video BIOS from 0xC0000 ...\n"); >> - vgabios_sz >> - round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512); >> + printf("Loading Gfx Video BIOS from file ...\n"); >> + memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt, >> sizeof(vgabios_pt)); >> + vgabios_sz = round_option_rom(sizeof(vgabios_pt)); >> break; >> default: >> printf("No emulated VGA adaptor ...\n"); >> >> </CODE> >> >> as intel-gfx-passthru-patch-3.patch and then I tried to apply the patch to xen 3.5-unstable. I got errors. I think it''s because the 3rd patch you provided is incomplete. >> >> Here''s my patching process: >> >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name vgabios >> ./tools/firmware/vgabios >> ./.hg/store/data/tools/firmware/vgabios >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cp ~enming/vgabios-pt.bin tools/firmware/vgabios/ >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ls tools/firmware/vgabios/ >> biossums.c clext.c Makefile TODO vbe.h vgabios.h vgatables.h >> BUGS COPYING Notes vbe.c vbetables-gen.c vgabios-pt.bin >> ChangeLog dataseghack README vbe_display_api.txt vgabios.c vgafonts.h >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# pwd >> /usr/src/xen-unstable.hg-vgapt >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wget http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin >> --2009-08-28 23:18:21-- http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin >> Resolving lists.xensource.com... 70.42.241.110 >> Connecting to lists.xensource.com|70.42.241.110|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 12565 (12K) [application/octet-stream] >> Saving to: `bincPiiAf0QWg.bin'' >> >> 100%[======================================================================>] 12,565 30.7K/s in 0.4s >> >> 2009-08-28 23:18:22 (30.7 KB/s) - `bincPiiAf0QWg.bin'' saved [12565/12565] >> >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv bincPiiAf0QWg.bin xen-gfx-passthrough.patch >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi xen-gfx-passthrough.patch >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch < xen-gfx-passthrough.patch >> can''t find file to patch at input line 4 >> Perhaps you should have used the -p or --strip option? >> The text leading up to this was: >> -------------------------- >> |diff -r 5d7e7a250267 tools/firmware/hvmloader/config.h >> |--- a/tools/firmware/hvmloader/config.h Wed Aug 26 18:28:44 2009 +0800 >> |+++ b/tools/firmware/hvmloader/config.h Thu Aug 27 16:54:24 2009 +0800 >> -------------------------- >> File to patch: ^C >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ex xen-gfx-passthrough.patch >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1 < xen-gfx-passthrough.patch >> patching file tools/firmware/hvmloader/config.h >> patching file tools/firmware/hvmloader/hvmloader.c >> patching file tools/libxc/ia64/xc_ia64_hvm_build.c >> patching file tools/libxc/xc_hvm_build.c >> patching file tools/libxc/xc_linux.c >> patching file tools/libxc/xenctrl.h >> patching file tools/libxc/xenguest.h >> patching file tools/python/xen/lowlevel/xc/xc.c >> patching file tools/python/xen/xend/XendConfig.py >> Hunk #1 succeeded at 174 (offset -1 lines). >> patching file tools/python/xen/xend/image.py >> Hunk #1 succeeded at 780 (offset -6 lines). >> Hunk #3 succeeded at 895 (offset -6 lines). >> patching file tools/python/xen/xm/create.py >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wget http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin >> --2009-08-28 23:21:35-- http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin >> Resolving lists.xensource.com... 70.42.241.110 >> Connecting to lists.xensource.com|70.42.241.110|:80... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: 9841 (9.6K) [application/octet-stream] >> Saving to: `binglLqkeq4Rj.bin'' >> >> 100%[======================================================================>] 9,841 24.3K/s in 0.4s >> >> 2009-08-28 23:21:36 (24.3 KB/s) - `binglLqkeq4Rj.bin'' saved [9841/9841] >> >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv binglLqkeq4Rj.bin qemu-gfx-passthrough.patch >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi qemu-gfx-passthrough.patch >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name hw >> ./tools/ioemu-remote/hw >> ./.hg/store/data/tools/ioemu/hw >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv qemu-gfx-passthrough.patch tools/ioemu-remote/ >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cd tools/ioemu-remote/ >> [root@fedora11-x86-64-host ioemu-remote]# patch -p1 < qemu- >> qemu-aio.h qemu-img.c qemu-sockets.c >> qemu-binfmt-conf.sh qemu-img.texi qemu-tech.texi >> qemu-char.c qemu-lock.h qemu-timer.h >> qemu-char.h qemu-log.h qemu-tool.c >> qemu-common.h qemu-malloc.c qemu-xen.h >> qemu-doc.texi qemu-nbd.c >> qemu-gfx-passthrough.patch qemu-nbd.texi >> [root@fedora11-x86-64-host ioemu-remote]# patch -p1 < qemu-gfx-passthrough.patch >> patching file hw/pass-through.c >> patching file hw/pass-through.h >> patching file hw/pc.c >> patching file vl.c >> [root@fedora11-x86-64-host ioemu-remote]# cd .. >> [root@fedora11-x86-64-host tools]# cd .. >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi intel-gfx-passthru-patch-3.patch >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1 < intel-gfx-passthru-patch-3.patch >> patching file tools/firmware/hvmloader/Makefile >> Hunk #1 FAILED at 50. >> 1 out of 1 hunk FAILED -- saving rejects to file tools/firmware/hvmloader/Makefile.rej >> patching file tools/firmware/hvmloader/hvmloader.c >> patch: **** malformed patch at line 24: sizeof(vgabios_pt)); >> >> [root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi intel-gfx-passthru-patch-3.patch >> >> For everybody''s convenience, I have attached intel-gfx-passthru-patch-3.patch and the firmware for my nVidia GeForce 8400 GS PCI Express x16 graphics card in this email. >> >> Please help me complete intel-gfx-passthru-patch-3.patch as I really need it. >> >> Thank you very much!!! >> >> -- >> Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) >> Technical Support Engineer >> Information Technology Department >> Asiasoft Online Pte Ltd >> Tampines Central 1 #04-01 Tampines Plaza >> Singapore 529541 >> Republic of Singapore >> Mobile: +65-9648-9798 >> MSN: teoenming@hotmail.com <mailto:teoenming@hotmail.com> >> Alma Maters: Singapore Polytechnic, National University of Singapore >> >> This patch supports basic gfx passthrough on QEMU: >> >> - disable emulated VGA adpater if there is passthroughed gfx >> >> - register/unregister legacy VGA I/O ports and MMIOs for passthroughed gfx >> >> >> >> Signed-off-by: Ben Lin <ben.y.lin@intel.com> <mailto:ben.y.lin@intel.com> >> >> Signed-off-by: Weidong Han <weidong.han@intel.com> <mailto:weidong.han@intel.com> >> >> No virus found in this incoming message. >> >> Checked by AVG - www.avg.com <http://www.avg.com> >> >> Version: 8.5.409 / Virus Database: 270.13.69/2328 - Release Date: 08/27/09 >> >> 18:02:00 >> >> >> >> No virus found in this outgoing message. >> >> Checked by AVG - www.avg.com <http://www.avg.com> >> >> Version: 8.5.409 / Virus Database: 270.13.71/2330 - Release Date: 08/27/09 >> >> 18:02:00 >> >> >> >> ------------------------------------------------------------------------ >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> Xen-devel mailing list >> >> Xen-devel@lists.xensource.com <mailto:Xen-devel@lists.xensource.com> >> >> http://lists.xensource.com/xen-devel >> >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> >> >> >> >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com <mailto:Xen-devel@lists.xensource.com> >> http://lists.xensource.com/xen-devel >> >> >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> >> >> >> _______________________________________________ >> Xen-devel mailing list >> Xen-devel@lists.xensource.com <mailto: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
I took a snapshot from xen-unstable and applied those patches.
However when trying to create a HVM domU the following error comes up:
# xm create test2.xm
Error: local variable ''str'' referenced before assignment
Using config file "/etc/xen/test2.xm".
And xend-debug.log gives some more info:
[2009-08-31 18:10:23 6189] DEBUG (XendDomainInfo:99)
XendDomainInfo.create([''vm'', [''name'',
''TEST2''], [''memory'', 4096],
[''vcpus'', 8], [''on_xend_start'',
''ignore''], [''on_xend_stop'',
''ignore''],
[''uuid'',
''06ed00ff-1162-4fc4-b5d8-11993ee4a8c0''],
[''image'', [''hvm'',
[''kernel'', ''/usr/lib/xen/boot/hvmloader''],
[''videoram'', 4],
[''device_model'',
''/usr/lib/xen/bin/qemu-dm''], [''pae'', 1],
[''vcpus'', 8],
[''boot'', ''c''], [''fda'',
''''], [''fdb'', ''''],
[''timer_mode'', 1],
[''localtime'', 0], [''serial'',
''''], [''stdvga'', 0],
[''isa'', 0],
[''nographic'', 0], [''soundhw'',
''''], [''vncunused'', 1],
[''display'',
'':0.0''], [''xauthority'',
''/root/.xauthPdEBhy''], [''rtc_timeoffset'',
0],
[''monitor'', 0], [''acpi'', 1],
[''apic'', 1], [''usb'', 0],
[''usbdevice'', ''''],
[''keymap'', ''''], [''pci'',
[[''0x0000'', ''0x03'',
''0x00'', ''0x0'', ''0x100'',
[],
''03:00.0'']]], [''hpet'', 0],
[''guest_os_type'', ''default''],
[''hap'', 1],
[''cpuid'', []], [''cpuid_check'', []],
[''viridian'', 0],
[''pci_msitranslate'', 1], [''vpt_align'', 1],
[''pci_power_mgmt'', 0],
[''xen_platform_pci'', 1], [''gfx_passthru'',
2]]], [''s3_integrity'', 1],
[''device'', [''vbd'',
[''uname'', ''phy:vgtest/test2''],
[''dev'', ''xvda''],
[''mode'', ''w'']]],
[''device'', [''pci'', [''dev'',
[''slot'', ''0x00''],
[''domain'',
''0x0000''], [''key'',
''03:00.0''], [''bus'',
''0x03''], [''vdevfn'',
''0x100''],
[''func'', ''0x0'']]]],
[''device'', [''vif'',
[''bridge'', ''eth0''],
[''mac'',
''00:16:3e:00:00:22''], [''type'',
''netfront'']]]])
[2009-08-31 18:10:23 6189] DEBUG (XendDomainInfo:2366)
XendDomainInfo.constructDomain
[2009-08-31 18:10:23 6189] DEBUG (balloon:181) Balloon: 4101688 KiB
free; need 4096; done.
[2009-08-31 18:10:23 6189] ERROR (XendDomainInfo:467) VM start failed
Traceback (most recent call last):
File "/usr/lib/python2.6/site-packages/xen/xend/XendDomainInfo.py",
line 452, in start
XendTask.log_progress(0, 30, self._constructDomain)
File "/usr/lib/python2.6/site-packages/xen/xend/XendTask.py", line
209, in log_progress
retval = func(*args, **kwds)
File "/usr/lib/python2.6/site-packages/xen/xend/XendDomainInfo.py",
line 2470, in _constructDomain
pci_str = str(pci)
UnboundLocalError: local variable ''str'' referenced before
assignment
Is this error related to the patches or is something else broken? I have
to admit that I''ve not been using xen-unstable for some time, only
release-3.4.1 and recently Xenclient, so I don''t know if this is also a
problem on unpatched xen-unstable.
The error disappears when I omit the "pci=" line, but obviously this
is
not a good scenario to test gfx passthrough ;-)
My config file for the test-domU:
kernel = "/usr/lib/xen/boot/hvmloader"
builder=''hvm''
memory = 4096
name = "TEST2"
vcpus=8
vif = [ ''type=netfront, mac=00:16:3e:ff:ff:22, bridge=eth0'' ]
disk = [ ''phy:vgtest/test2,xvda,w'' ]
#viridian = 1
device_model = ''/usr/lib/xen/bin/qemu-dm''
#boot="cd"
#sdl=0
#opengl=0
#vnc=1
#vnclisten="127.0.0.1"
#vncdisplay=1
#vncpasswd=''''
#stdvga=0
gfx_passthru=2
pci=[''03:00.0'']
Thanks,
Christian
Han, Weidong wrote:> Teo,
>
> I attached some experimental patches for you to try to sthorugh Geforce
> 8400 GS.
>
> Based on my patches posted last Friday, pls follow below instructions:
> 1. apply xen-load-vbios-file.patch to xen-unstable.hg
> this patch supports to load vga bios from a file.
> 2. apply xen-vBAR-pBAR.patch to xen-unstable.hg
> this patch is used to 1:1 map between vBAR and pBAR
> 3. apply qemu-change-for-vBAR-pBAR.patch to ioemu-remote (qemu tree).
> this patch is used to 1:1 map between vBAR and pBAR on qemu side
> 4. apply qemu-claim-cycle-for-secondary-gfx-passthrough.patch
> it''s needed if you want to assign the secondary gfx to guest.
> 5. cd xen-unstable.hg
> 6. make clean
> 7. copy the vga bios file to
> xen-unstabl.hg/tools/firmware/vgabios/vgabios-pt.bin
> 8. make; make install
> 9. reboot the system. or xend restart. then passthrough gfx to guest ...
>
>
> Regards,
> Weidong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
<djmagee@mageenet.net>
2009-Aug-31 17:03 UTC
RE: [Xen-devel] Re: graphics passthrough with VT-d
I had the same problem with unpatched xen-unstable that was up-to-date
this morning. This was simply in trying to pass through a usb
controller, to test xen-unstable before I went ahead and applied the gfx
passthrough patches.
This seems like a bug in xen-unstable.
-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Christian
Tramnitz
Sent: Monday, August 31, 2009 12:48 PM
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Re: graphics passthrough with VT-d
I took a snapshot from xen-unstable and applied those patches.
However when trying to create a HVM domU the following error comes up:
# xm create test2.xm
Error: local variable ''str'' referenced before assignment
Using config file "/etc/xen/test2.xm".
And xend-debug.log gives some more info:
[2009-08-31 18:10:23 6189] DEBUG (XendDomainInfo:99)
XendDomainInfo.create([''vm'', [''name'',
''TEST2''], [''memory'', 4096],
[''vcpus'', 8], [''on_xend_start'',
''ignore''], [''on_xend_stop'',
''ignore''],
[''uuid'',
''06ed00ff-1162-4fc4-b5d8-11993ee4a8c0''],
[''image'', [''hvm'',
[''kernel'', ''/usr/lib/xen/boot/hvmloader''],
[''videoram'', 4],
[''device_model'',
''/usr/lib/xen/bin/qemu-dm''], [''pae'', 1],
[''vcpus'', 8],
[''boot'', ''c''], [''fda'',
''''], [''fdb'', ''''],
[''timer_mode'', 1],
[''localtime'', 0], [''serial'',
''''], [''stdvga'', 0],
[''isa'', 0],
[''nographic'', 0], [''soundhw'',
''''], [''vncunused'', 1],
[''display'',
'':0.0''], [''xauthority'',
''/root/.xauthPdEBhy''], [''rtc_timeoffset'',
0],
[''monitor'', 0], [''acpi'', 1],
[''apic'', 1], [''usb'', 0],
[''usbdevice'', ''''],
[''keymap'', ''''], [''pci'',
[[''0x0000'', ''0x03'',
''0x00'', ''0x0'', ''0x100'',
[],
''03:00.0'']]], [''hpet'', 0],
[''guest_os_type'', ''default''],
[''hap'', 1],
[''cpuid'', []], [''cpuid_check'', []],
[''viridian'', 0],
[''pci_msitranslate'', 1], [''vpt_align'', 1],
[''pci_power_mgmt'', 0],
[''xen_platform_pci'', 1], [''gfx_passthru'',
2]]], [''s3_integrity'', 1],
[''device'', [''vbd'',
[''uname'', ''phy:vgtest/test2''],
[''dev'', ''xvda''],
[''mode'', ''w'']]],
[''device'', [''pci'', [''dev'',
[''slot'', ''0x00''],
[''domain'',
''0x0000''], [''key'',
''03:00.0''], [''bus'',
''0x03''], [''vdevfn'',
''0x100''],
[''func'', ''0x0'']]]],
[''device'', [''vif'',
[''bridge'', ''eth0''],
[''mac'',
''00:16:3e:00:00:22''], [''type'',
''netfront'']]]])
[2009-08-31 18:10:23 6189] DEBUG (XendDomainInfo:2366)
XendDomainInfo.constructDomain
[2009-08-31 18:10:23 6189] DEBUG (balloon:181) Balloon: 4101688 KiB
free; need 4096; done.
[2009-08-31 18:10:23 6189] ERROR (XendDomainInfo:467) VM start failed
Traceback (most recent call last):
File "/usr/lib/python2.6/site-packages/xen/xend/XendDomainInfo.py",
line 452, in start
XendTask.log_progress(0, 30, self._constructDomain)
File "/usr/lib/python2.6/site-packages/xen/xend/XendTask.py", line
209, in log_progress
retval = func(*args, **kwds)
File "/usr/lib/python2.6/site-packages/xen/xend/XendDomainInfo.py",
line 2470, in _constructDomain
pci_str = str(pci)
UnboundLocalError: local variable ''str'' referenced before
assignment
Is this error related to the patches or is something else broken? I have
to admit that I''ve not been using xen-unstable for some time, only
release-3.4.1 and recently Xenclient, so I don''t know if this is also a
problem on unpatched xen-unstable.
The error disappears when I omit the "pci=" line, but obviously this
is
not a good scenario to test gfx passthrough ;-)
My config file for the test-domU:
kernel = "/usr/lib/xen/boot/hvmloader"
builder=''hvm''
memory = 4096
name = "TEST2"
vcpus=8
vif = [ ''type=netfront, mac=00:16:3e:ff:ff:22, bridge=eth0'' ]
disk = [ ''phy:vgtest/test2,xvda,w'' ]
#viridian = 1
device_model = ''/usr/lib/xen/bin/qemu-dm''
#boot="cd"
#sdl=0
#opengl=0
#vnc=1
#vnclisten="127.0.0.1"
#vncdisplay=1
#vncpasswd=''''
#stdvga=0
gfx_passthru=2
pci=[''03:00.0'']
Thanks,
Christian
Han, Weidong wrote:> Teo,
>
> I attached some experimental patches for you to try to sthorugh
Geforce > 8400 GS.
>
> Based on my patches posted last Friday, pls follow below instructions:
> 1. apply xen-load-vbios-file.patch to xen-unstable.hg
> this patch supports to load vga bios from a file.
> 2. apply xen-vBAR-pBAR.patch to xen-unstable.hg
> this patch is used to 1:1 map between vBAR and pBAR
> 3. apply qemu-change-for-vBAR-pBAR.patch to ioemu-remote (qemu tree).
> this patch is used to 1:1 map between vBAR and pBAR on qemu side
> 4. apply qemu-claim-cycle-for-secondary-gfx-passthrough.patch
> it''s needed if you want to assign the secondary gfx to guest.
> 5. cd xen-unstable.hg
> 6. make clean
> 7. copy the vga bios file to
> xen-unstabl.hg/tools/firmware/vgabios/vgabios-pt.bin
> 8. make; make install
> 9. reboot the system. or xend restart. then passthrough gfx to guest
...>
>
> Regards,
> Weidong
_______________________________________________
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
This is probably due to c/s 20137 and now fixed by c/s 20141. Thanks, Keir On 31/08/2009 18:03, "djmagee@mageenet.net" <djmagee@mageenet.net> wrote:> I had the same problem with unpatched xen-unstable that was up-to-date > this morning. This was simply in trying to pass through a usb > controller, to test xen-unstable before I went ahead and applied the gfx > passthrough patches. > > This seems like a bug in xen-unstable. > > -----Original Message----- > From: xen-devel-bounces@lists.xensource.com > [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Christian > Tramnitz > Sent: Monday, August 31, 2009 12:48 PM > To: xen-devel@lists.xensource.com > Subject: [Xen-devel] Re: graphics passthrough with VT-d > > I took a snapshot from xen-unstable and applied those patches. > However when trying to create a HVM domU the following error comes up: > # xm create test2.xm > Error: local variable ''str'' referenced before assignment > Using config file "/etc/xen/test2.xm". > > And xend-debug.log gives some more info: > [2009-08-31 18:10:23 6189] DEBUG (XendDomainInfo:99) > XendDomainInfo.create([''vm'', [''name'', ''TEST2''], [''memory'', 4096], > [''vcpus'', 8], [''on_xend_start'', ''ignore''], [''on_xend_stop'', ''ignore''], > [''uuid'', ''06ed00ff-1162-4fc4-b5d8-11993ee4a8c0''], [''image'', [''hvm'', > [''kernel'', ''/usr/lib/xen/boot/hvmloader''], [''videoram'', 4], > [''device_model'', ''/usr/lib/xen/bin/qemu-dm''], [''pae'', 1], [''vcpus'', 8], > [''boot'', ''c''], [''fda'', ''''], [''fdb'', ''''], [''timer_mode'', 1], > [''localtime'', 0], [''serial'', ''''], [''stdvga'', 0], [''isa'', 0], > [''nographic'', 0], [''soundhw'', ''''], [''vncunused'', 1], [''display'', > '':0.0''], [''xauthority'', ''/root/.xauthPdEBhy''], [''rtc_timeoffset'', 0], > [''monitor'', 0], [''acpi'', 1], [''apic'', 1], [''usb'', 0], [''usbdevice'', ''''], > [''keymap'', ''''], [''pci'', [[''0x0000'', ''0x03'', ''0x00'', ''0x0'', ''0x100'', [], > ''03:00.0'']]], [''hpet'', 0], [''guest_os_type'', ''default''], [''hap'', 1], > [''cpuid'', []], [''cpuid_check'', []], [''viridian'', 0], > [''pci_msitranslate'', 1], [''vpt_align'', 1], [''pci_power_mgmt'', 0], > [''xen_platform_pci'', 1], [''gfx_passthru'', 2]]], [''s3_integrity'', 1], > [''device'', [''vbd'', [''uname'', ''phy:vgtest/test2''], [''dev'', ''xvda''], > [''mode'', ''w'']]], [''device'', [''pci'', [''dev'', [''slot'', ''0x00''], [''domain'', > ''0x0000''], [''key'', ''03:00.0''], [''bus'', ''0x03''], [''vdevfn'', ''0x100''], > [''func'', ''0x0'']]]], [''device'', [''vif'', [''bridge'', ''eth0''], [''mac'', > ''00:16:3e:00:00:22''], [''type'', ''netfront'']]]]) > [2009-08-31 18:10:23 6189] DEBUG (XendDomainInfo:2366) > XendDomainInfo.constructDomain > [2009-08-31 18:10:23 6189] DEBUG (balloon:181) Balloon: 4101688 KiB > free; need 4096; done. > [2009-08-31 18:10:23 6189] ERROR (XendDomainInfo:467) VM start failed > Traceback (most recent call last): > File "/usr/lib/python2.6/site-packages/xen/xend/XendDomainInfo.py", > line 452, in start > XendTask.log_progress(0, 30, self._constructDomain) > File "/usr/lib/python2.6/site-packages/xen/xend/XendTask.py", line > 209, in log_progress > retval = func(*args, **kwds) > File "/usr/lib/python2.6/site-packages/xen/xend/XendDomainInfo.py", > line 2470, in _constructDomain > pci_str = str(pci) > UnboundLocalError: local variable ''str'' referenced before assignment > > > Is this error related to the patches or is something else broken? I have > to admit that I''ve not been using xen-unstable for some time, only > release-3.4.1 and recently Xenclient, so I don''t know if this is also a > problem on unpatched xen-unstable. > The error disappears when I omit the "pci=" line, but obviously this is > not a good scenario to test gfx passthrough ;-) > > > My config file for the test-domU: > kernel = "/usr/lib/xen/boot/hvmloader" > builder=''hvm'' > memory = 4096 > name = "TEST2" > vcpus=8 > vif = [ ''type=netfront, mac=00:16:3e:ff:ff:22, bridge=eth0'' ] > disk = [ ''phy:vgtest/test2,xvda,w'' ] > #viridian = 1 > device_model = ''/usr/lib/xen/bin/qemu-dm'' > #boot="cd" > #sdl=0 > #opengl=0 > #vnc=1 > #vnclisten="127.0.0.1" > #vncdisplay=1 > #vncpasswd='''' > #stdvga=0 > gfx_passthru=2 > pci=[''03:00.0''] > > > Thanks, > Christian > > > Han, Weidong wrote: >> Teo, >> >> I attached some experimental patches for you to try to sthorugh > Geforce >> 8400 GS. >> >> Based on my patches posted last Friday, pls follow below instructions: >> 1. apply xen-load-vbios-file.patch to xen-unstable.hg >> this patch supports to load vga bios from a file. >> 2. apply xen-vBAR-pBAR.patch to xen-unstable.hg >> this patch is used to 1:1 map between vBAR and pBAR >> 3. apply qemu-change-for-vBAR-pBAR.patch to ioemu-remote (qemu tree). >> this patch is used to 1:1 map between vBAR and pBAR on qemu side >> 4. apply qemu-claim-cycle-for-secondary-gfx-passthrough.patch >> it''s needed if you want to assign the secondary gfx to guest. >> 5. cd xen-unstable.hg >> 6. make clean >> 7. copy the vga bios file to >> xen-unstabl.hg/tools/firmware/vgabios/vgabios-pt.bin >> 8. make; make install >> 9. reboot the system. or xend restart. then passthrough gfx to guest > ... >> >> >> Regards, >> Weidong > > > _______________________________________________ > 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_______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Mr. Teo En Ming (Zhang Enming)
2009-Aug-31 17:22 UTC
Re: [Xen-devel] Re: graphics passthrough with VT-d
Hi Guys, Do you have any success after applying Weidong''s gfx passthrough and 1:1 bar mapping patches to xen-unstable? -- Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering) BEng(Hons)(Mechanical Engineering) Technical Support Engineer Information Technology Department Asiasoft Online Pte Ltd Tampines Central 1 #04-01 Tampines Plaza Singapore 529541 Republic of Singapore Company Website: http://www.asiasoft.sg/ Mobile: +65-9648-9798 MSN: teoenming@hotmail.com Alma Maters: Singapore Polytechnic, National University of Singapore On 09/01/2009 01:18 AM, Keir Fraser wrote:> This is probably due to c/s 20137 and now fixed by c/s 20141. > > Thanks, > Keir > > On 31/08/2009 18:03, "djmagee@mageenet.net"<djmagee@mageenet.net> wrote: > > >> I had the same problem with unpatched xen-unstable that was up-to-date >> this morning. This was simply in trying to pass through a usb >> controller, to test xen-unstable before I went ahead and applied the gfx >> passthrough patches. >> >> This seems like a bug in xen-unstable. >> >> -----Original Message----- >> From: xen-devel-bounces@lists.xensource.com >> [mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Christian >> Tramnitz >> Sent: Monday, August 31, 2009 12:48 PM >> To: xen-devel@lists.xensource.com >> Subject: [Xen-devel] Re: graphics passthrough with VT-d >> >> I took a snapshot from xen-unstable and applied those patches. >> However when trying to create a HVM domU the following error comes up: >> # xm create test2.xm >> Error: local variable ''str'' referenced before assignment >> Using config file "/etc/xen/test2.xm". >> >> And xend-debug.log gives some more info: >> [2009-08-31 18:10:23 6189] DEBUG (XendDomainInfo:99) >> XendDomainInfo.create([''vm'', [''name'', ''TEST2''], [''memory'', 4096], >> [''vcpus'', 8], [''on_xend_start'', ''ignore''], [''on_xend_stop'', ''ignore''], >> [''uuid'', ''06ed00ff-1162-4fc4-b5d8-11993ee4a8c0''], [''image'', [''hvm'', >> [''kernel'', ''/usr/lib/xen/boot/hvmloader''], [''videoram'', 4], >> [''device_model'', ''/usr/lib/xen/bin/qemu-dm''], [''pae'', 1], [''vcpus'', 8], >> [''boot'', ''c''], [''fda'', ''''], [''fdb'', ''''], [''timer_mode'', 1], >> [''localtime'', 0], [''serial'', ''''], [''stdvga'', 0], [''isa'', 0], >> [''nographic'', 0], [''soundhw'', ''''], [''vncunused'', 1], [''display'', >> '':0.0''], [''xauthority'', ''/root/.xauthPdEBhy''], [''rtc_timeoffset'', 0], >> [''monitor'', 0], [''acpi'', 1], [''apic'', 1], [''usb'', 0], [''usbdevice'', ''''], >> [''keymap'', ''''], [''pci'', [[''0x0000'', ''0x03'', ''0x00'', ''0x0'', ''0x100'', [], >> ''03:00.0'']]], [''hpet'', 0], [''guest_os_type'', ''default''], [''hap'', 1], >> [''cpuid'', []], [''cpuid_check'', []], [''viridian'', 0], >> [''pci_msitranslate'', 1], [''vpt_align'', 1], [''pci_power_mgmt'', 0], >> [''xen_platform_pci'', 1], [''gfx_passthru'', 2]]], [''s3_integrity'', 1], >> [''device'', [''vbd'', [''uname'', ''phy:vgtest/test2''], [''dev'', ''xvda''], >> [''mode'', ''w'']]], [''device'', [''pci'', [''dev'', [''slot'', ''0x00''], [''domain'', >> ''0x0000''], [''key'', ''03:00.0''], [''bus'', ''0x03''], [''vdevfn'', ''0x100''], >> [''func'', ''0x0'']]]], [''device'', [''vif'', [''bridge'', ''eth0''], [''mac'', >> ''00:16:3e:00:00:22''], [''type'', ''netfront'']]]]) >> [2009-08-31 18:10:23 6189] DEBUG (XendDomainInfo:2366) >> XendDomainInfo.constructDomain >> [2009-08-31 18:10:23 6189] DEBUG (balloon:181) Balloon: 4101688 KiB >> free; need 4096; done. >> [2009-08-31 18:10:23 6189] ERROR (XendDomainInfo:467) VM start failed >> Traceback (most recent call last): >> File "/usr/lib/python2.6/site-packages/xen/xend/XendDomainInfo.py", >> line 452, in start >> XendTask.log_progress(0, 30, self._constructDomain) >> File "/usr/lib/python2.6/site-packages/xen/xend/XendTask.py", line >> 209, in log_progress >> retval = func(*args, **kwds) >> File "/usr/lib/python2.6/site-packages/xen/xend/XendDomainInfo.py", >> line 2470, in _constructDomain >> pci_str = str(pci) >> UnboundLocalError: local variable ''str'' referenced before assignment >> >> >> Is this error related to the patches or is something else broken? I have >> to admit that I''ve not been using xen-unstable for some time, only >> release-3.4.1 and recently Xenclient, so I don''t know if this is also a >> problem on unpatched xen-unstable. >> The error disappears when I omit the "pci=" line, but obviously this is >> not a good scenario to test gfx passthrough ;-) >> >> >> My config file for the test-domU: >> kernel = "/usr/lib/xen/boot/hvmloader" >> builder=''hvm'' >> memory = 4096 >> name = "TEST2" >> vcpus=8 >> vif = [ ''type=netfront, mac=00:16:3e:ff:ff:22, bridge=eth0'' ] >> disk = [ ''phy:vgtest/test2,xvda,w'' ] >> #viridian = 1 >> device_model = ''/usr/lib/xen/bin/qemu-dm'' >> #boot="cd" >> #sdl=0 >> #opengl=0 >> #vnc=1 >> #vnclisten="127.0.0.1" >> #vncdisplay=1 >> #vncpasswd='''' >> #stdvga=0 >> gfx_passthru=2 >> pci=[''03:00.0''] >> >> >> Thanks, >> Christian >> >> >> Han, Weidong wrote: >> >>> Teo, >>> >>> I attached some experimental patches for you to try to sthorugh >>> >> Geforce >> >>> 8400 GS. >>> >>> Based on my patches posted last Friday, pls follow below instructions: >>> 1. apply xen-load-vbios-file.patch to xen-unstable.hg >>> this patch supports to load vga bios from a file. >>> 2. apply xen-vBAR-pBAR.patch to xen-unstable.hg >>> this patch is used to 1:1 map between vBAR and pBAR >>> 3. apply qemu-change-for-vBAR-pBAR.patch to ioemu-remote (qemu tree). >>> this patch is used to 1:1 map between vBAR and pBAR on qemu side >>> 4. apply qemu-claim-cycle-for-secondary-gfx-passthrough.patch >>> it''s needed if you want to assign the secondary gfx to guest. >>> 5. cd xen-unstable.hg >>> 6. make clean >>> 7. copy the vga bios file to >>> xen-unstabl.hg/tools/firmware/vgabios/vgabios-pt.bin >>> 8. make; make install >>> 9. reboot the system. or xend restart. then passthrough gfx to guest >>> >> ... >> >>> >>> >>> Regards, >>> Weidong >>> >> >> _______________________________________________ >> 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 >> > > > _______________________________________________ > 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
Hi Weidong,
Here are my findings so far, it still doesn’t work but I have not experienced a
crash or Dom0 lockup, and I have switched to 2.6.18-Dom0 which may also help ...
64bit Hypervisor (xen-unstable.hg 31/08/09)
Dom0 - 2.6.18-xen-dom0 (from xenbits)
Patches applied:
./qemu-gfx-passthrough.patch
./qemu-change-for-vBAR-pBAR.patch
./qemu-claim-vga-cycle-for-secondary-gfx-passthrough.patch
./xen-vBAR-pBAR.patch
./xen-gfx-passthrough.patch
./xen-load-vbios-file.patch
02:00.0 - Primary GFX (Dom0) Console: NVidia Geforce GTX260
03:00.0 - Secondary GFX (DomU): NVidia Geforce 9500GT
Qemu:
Warning: attempted read from physical address 0xe0000000 in xen platform mmio
space
And
pt_pci_write_config: Warning: Guest attempt to set address to unused Base
Address Register. [00:04.0][Offset:30h][Length:4]
Hope this helps,
Tim
From: Han, Weidong [mailto:weidong.han@intel.com]
Sent: 31 August 2009 09:47
To: ''enming.teo@asiasoftsea.net''; Tim Moore
Cc: ''xen-devel@lists.xensource.com''
Subject: RE: [Xen-devel] graphics passthrough with VT-d
Teo,
I attached some experimental patches for you to try to sthorugh Geforce 8400 GS.
Based on my patches posted last Friday, pls follow below instructions:
1. apply xen-load-vbios-file.patch to xen-unstable.hg
this patch supports to load vga bios from a file.
2. apply xen-vBAR-pBAR.patch to xen-unstable.hg
this patch is used to 1:1 map between vBAR and pBAR
3. apply qemu-change-for-vBAR-pBAR.patch to ioemu-remote (qemu tree).
this patch is used to 1:1 map between vBAR and pBAR on qemu side
4. apply qemu-claim-cycle-for-secondary-gfx-passthrough.patch
it''s needed if you want to assign the secondary gfx to guest.
5. cd xen-unstable.hg
6. make clean
7. copy the vga bios file to
xen-unstabl.hg/tools/firmware/vgabios/vgabios-pt.bin
8. make; make install
9. reboot the system. or xend restart. then passthrough gfx to guest ...
Regards,
Weidong
________________________________
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Mr. Teo En Ming
(Zhang Enming)
Sent: 2009年8月29日 22:13
To: timothy.moore@expidas.net
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] graphics passthrough with VT-d
Hi Timothy,
Yes, I renamed the firmware file of nVidia Geforce 8400 GS to vgabios-pt.bin and
placed it in the source directory tools/firmware/vgabios.
Weidong had said Intel has the 1:1 mapping patches. Let''s hope he will
release the patch soon to do pBAR:vBAR.
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Company Website: http://www.asiasoft.sg/
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 09:29 PM, Tim Moore wrote:
Teo,
Did you rename your Nvidia BIOS and copy it into the hvmloader source tree as
required ?
It should get compiled into roms.h in the hvmloader folder - I made sure it was
there as the xen buildroot seems to delete it randomly ...
I think we are now up against the Base Address Register issue where the Nvidia
driver is expecting to see the card at the Physical BAR Addresses and in the
DomU these are re-mapped to different address space ... this is a problem with
the Nvidia binary driver and therefore a workaround in xen is maybe needed.
That said, I''m not sure if the Nvidia BIOS likes to be re-executed and
may also be an issue ...
Tim
From: Mr. Teo En Ming (Zhang Enming) [mailto:enming.teo@asiasoftsea.net]
Sent: 29 August 2009 14:21
To: enming.teo@asiasoftsea.net<mailto:enming.teo@asiasoftsea.net>
Cc: Tim Moore;
xen-devel@lists.xensource.com<mailto:xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] graphics passthrough with VT-d
Dear All,
I have applied the following patches to xen 3.5-unstable
1) intel-gfx-passthru-patch01.patch
2) intel-gfx-passthru-patch02.patch
3) intel-gfx-passthru-patch03.patch
4) enming-patch04.patch
and compiled xen 3.5-unstable successfully (both hypervisor and tools).
i rebooted into this newly compiled Xen hypervisor which supports loading vga
bios from firmware file of nVidia Geforce 8400 GS PCI Express x16.
After dom0 has booted up, I executed the following script to hide nVidia Geforce
8400 GS from dom0.
[enming@fedora11-x86-64-host scripts]$ cat bind-devices-pci-stub.sh
#!/bin/sh
echo "10de 06e4" > /sys/bus/pci/drivers/pci-stub/new_id
echo "0000:01:00.0" >
/sys/bus/pci/devices/0000:01:00.0/driver/unbind
echo "0000:01:00.0" > /sys/bus/pci/drivers/pci-stub/bind
I also assigned the nVidia Geforce 8400 GS to my Windows XP Home HVM domU.
pci = [ ''01:00.0'' ]
I also specified gfx_passthru=2.
Do note that I booted up with onboard Intel GMA4500 as the primary video
adapter. Hence dom 0 has onboard graphics and Windows XP HVM domU has nvidia
graphics.
Then I started Windows XP Home HVM DomU.
Very soon, my Dom 0''s display was garbaged and X server on Dom 0
totally froze and became unresponsive. I cannot switch to any ttys.
However, I was still able to vnc into my Windows XP Home HVM Dom U. I had
earlier installed a VNC server into my Windows XP guest. After remoting in to my
Windows XP DomU through vnc, I found that NVIDIA Geforce 8400 GS cannot be
initialized and no resources are available for this graphics card.
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Company Website: http://www.asiasoft.sg/
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 08:25 PM, Mr. Teo En Ming (Zhang Enming) wrote:
Hi All,
I have solved the problem encountered below when building tools for xen
3.5-unstable. The compile problem exists because I downloaded and compiled the
latest version of Intel ACPI Component Architecture compiler version 20090730.
And I used this latest compiler during "make tools" for xen-unstable.
In original xen-unstable source codes cloned from xensoure mercurial repository,
the header files ssdt_pm.h and ssdt_tpm.h in source directory
tools/firmware/hvmloader/acpi/ are generated by
/*
*
* Intel ACPI Component Architecture
* ASL Optimizing Compiler version 20061109 [May 18 2007]
* Copyright (C) 2000 - 2006 Intel Corporation
* Supports ACPI Specification Revision 3.0a
*
* Compilation of "ssdt_pm.asl" - Sun Oct 12 23:57:51 2008
*
* C source code output
*
*/
In original ssdt_pm.h, it has "unsigned char AmlCode_PM[] =".
In original ssdt_tpm.h, it has "unsigned char AmlCode_TPM[] =".
Hence there was no problem with "make tools".
But, I downloaded, compiled and used
/*
*
* Intel ACPI Component Architecture
* ASL Optimizing Compiler version 20090730 [Aug 29 2009]
* Copyright (C) 2000 - 2009 Intel Corporation
* Supports ACPI Specification Revision 4.0
*
* Compilation of "ssdt_pm.asl" - Sat Aug 29 18:55:40 2009
*
* C source code output
*
*/
So the *new* ssdt_pm.h contains:
/*
*
* Intel ACPI Component Architecture
* ASL Optimizing Compiler version 20090730 [Aug 29 2009]
* Copyright (C) 2000 - 2009 Intel Corporation
* Supports ACPI Specification Revision 4.0
*
* Compilation of "ssdt_pm.asl" - Sat Aug 29 18:55:40 2009
*
* C source code output
*
*/
unsigned char AmlCode[] {
0x53,0x53,0x44,0x54,0xD6,0x05,0x00,0x00, /* 00000000
"SSDT...." */
0x02,0xB9,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008
"..Xen..." */
0x48,0x56,0x4D,0x00,0x00,0x00,0x00,0x00, /* 00000010
"HVM....." */
0x00,0x00,0x00,0x00,0x49,0x4E,0x54,0x4C, /* 00000018
"....INTL" */
0x30,0x07,0x09,0x20,0x10,0x41,0x5B,0x5C, /* 00000020 "0..
.A[\" */
0x5F,0x53,0x42,0x5F,0x5B,0x80,0x44,0x42, /* 00000028
"_SB_[.DB" */
0x47,0x41,0x01,0x0B,0x40,0xB0,0x01,0x5B, /* 00000030
"GA..@..["<mailto:GA..@..%5B> */
0x81,0x0B,0x44,0x42,0x47,0x41,0x01,0x44, /* 00000038
"..DBGA.D" */
0x42,0x47,0x31,0x08,0x5B,0x80,0x44,0x42, /* 00000040
"BG1.[.DB" */
0x47,0x42,0x01,0x0B,0x44,0xB0,0x01,0x5B, /* 00000048
"GB..D..[" */
0x81,0x0B,0x44,0x42,0x47,0x42,0x01,0x44, /* 00000050
"..DBGB.D" */
0x42,0x47,0x32,0x08,0x5B,0x80,0x44,0x42, /* 00000058
"BG2.[.DB" */
0x47,0x43,0x01,0x0B,0x46,0xB0,0x01,0x5B, /* 00000060
"GC..F..[" */
0x81,0x0B,0x44,0x42,0x47,0x43,0x01,0x44, /* 00000068
"..DBGC.D" */
0x42,0x47,0x33,0x08,0x5B,0x80,0x44,0x42, /* 00000070
"BG3.[.DB" */
0x47,0x44,0x01,0x0B,0x48,0xB0,0x01,0x5B, /* 00000078
"GD..H..[" */
0x81,0x0B,0x44,0x42,0x47,0x44,0x01,0x44, /* 00000080
"..DBGD.D" */
0x42,0x47,0x34,0x08,0x5B,0x80,0x50,0x52, /* 00000088
"BG4.[.PR" */
0x54,0x31,0x01,0x0A,0xB2,0x0A,0x02,0x5B, /* 00000090
"T1.....[" */
0x81,0x10,0x50,0x52,0x54,0x31,0x01,0x50, /* 00000098
"..PRT1.P" */
0x42,0x32,0x5F,0x08,0x50,0x42,0x32,0x41, /* 000000A0
"B2_.PB2A" */
0x08,0x5B,0x80,0x50,0x52,0x54,0x32,0x01, /* 000000A8
".[.PRT2." */
0x0A,0x86,0x01,0x5B,0x81,0x0B,0x50,0x52, /* 000000B0
"...[..PR" */
0x54,0x32,0x01,0x50,0x38,0x36,0x5F,0x08, /* 000000B8
"T2.P86_." */
0x5B,0x80,0x50,0x52,0x54,0x33,0x01,0x0A, /* 000000C0
"[.PRT3.." */
0x88,0x01,0x5B,0x81,0x0B,0x50,0x52,0x54, /* 000000C8
"..[..PRT" */
0x33,0x01,0x50,0x38,0x38,0x5F,0x08,0x5B, /* 000000D0
"3.P88_.[" */
0x01,0x53,0x59,0x4E,0x43,0x01,0x08,0x42, /* 000000D8
".SYNC..B" */
0x55,0x46,0x30,0x11,0x04,0x0B,0x00,0x01, /* 000000E0
"UF0....." */
0x08,0x42,0x55,0x46,0x31,0x11,0x03,0x0A, /* 000000E8
".BUF1..." */
0x08,0x8B,0x42,0x55,0x46,0x31,0x00,0x42, /* 000000F0
"..BUF1.B" */
0x55,0x46,0x41,0x8B,0x42,0x55,0x46,0x31, /* 000000F8
"UFA.BUF1" */
0x0A,0x04,0x42,0x55,0x46,0x42,0x14,0x14, /* 00000100
"..BUFB.." */
And the *new* ssdt_tpm.h contains:
/*
*
* Intel ACPI Component Architecture
* ASL Optimizing Compiler version 20090730 [Aug 29 2009]
* Copyright (C) 2000 - 2009 Intel Corporation
* Supports ACPI Specification Revision 4.0
*
* Compilation of "ssdt_tpm.asl" - Sat Aug 29 18:55:40 2009
*
* C source code output
*
*/
unsigned char AmlCode[] {
0x53,0x53,0x44,0x54,0x4C,0x00,0x00,0x00, /* 00000000
"SSDTL..." */
0x02,0x2A,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008
".*Xen..." */
0x48,0x56,0x4D,0x00,0x00,0x00,0x00,0x00, /* 00000010
"HVM....." */
0x00,0x00,0x00,0x00,0x49,0x4E,0x54,0x4C, /* 00000018
"....INTL" */
0x30,0x07,0x09,0x20,0x5B,0x82,0x26,0x54, /* 00000020 "0..
[.&T" */
0x50,0x4D,0x5F,0x08,0x5F,0x48,0x49,0x44, /* 00000028
"PM_._HID" */
0x0C,0x41,0xD0,0x0C,0x31,0x08,0x5F,0x43, /* 00000030
".A..1._C" */
0x52,0x53,0x11,0x11,0x0A,0x0E,0x86,0x09, /* 00000038
"RS......" */
0x00,0x01,0x00,0x00,0xD4,0xFE,0x00,0x50, /* 00000040
".......P" */
0x00,0x00,0x79,0x00,
};
which are both wrong.
In ssdt_pm.h, I have to change "unsigned char AmlCode[]" to
"unsigned char AmlCode_PM[]".
In ssdt_tpm.h, I have to change "unsigned char AmlCode[]" to
"unsigned char AmlCode_TPM[]".
Then "make tools" is able to complete successfully.
I have created a patch for anybody who may be using the *latest* version of
Intel ACPI CA compiler version 20090730 and attached it here.
Patch file filename enming-patch04.patch:
<CODE>
Patch created by Teo En Ming (Zhang Enming) on 29 August 2009 Saturday at 8:00
P.M. Singapore Time
Email #1: enming.teo@asiasoftsea.net<mailto:enming.teo@asiasoftsea.net>
Email #2:
space.time.universe@gmail.com<mailto:space.time.universe@gmail.com>
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Mobile Phone: +65-9648-9798
--- ssdt_pm.h 2009-08-29 19:54:52.653088000 +0800
+++ ssdt_pm.h 2009-08-29 19:56:51.813088550 +0800
@@ -10,7 +10,7 @@
* C source code output
*
*/
-unsigned char AmlCode[] +unsigned char AmlCode_PM[] {
0x53,0x53,0x44,0x54,0xD6,0x05,0x00,0x00, /* 00000000
"SSDT...." */
0x02,0xB9,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008
"..Xen..." */
--- ssdt_tpm.h 2009-08-29 19:55:44.578738954 +0800
+++ ssdt_tpm.h 2009-08-29 19:57:27.896638884 +0800
@@ -10,7 +10,7 @@
* C source code output
*
*/
-unsigned char AmlCode[] +unsigned char AmlCode_TPM[] {
0x53,0x53,0x44,0x54,0x4C,0x00,0x00,0x00, /* 00000000
"SSDTL..." */
0x02,0x2A,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008
".*Xen..." */
</CODE>
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Company Website: http://www.asiasoft.sg/
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 07:03 PM, Mr. Teo En Ming (Zhang Enming) wrote:
Hi,
I cloned http://xenbits.xensource.com/xen-unstable.hg again today. I tried
applying the three Intel gfx passthrough patches to xen-unstable. When I
"make tools", I get the same error again:
make[7]: Entering directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader''
make -C acpi all
get-path: will use #!/usr/bin/python2.6 for python programs
make[8]: Entering directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi''
make iasl
get-path: will use #!/usr/bin/python2.6 for python programs
make[9]: Entering directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi''
make[9]: `/usr/local/bin/iasl'' is up to date.
make[9]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi''
iasl -tc ssdt_tpm.asl
Intel ACPI Component Architecture
ASL Optimizing Compiler version 20090730 [Aug 29 2009]
Copyright (C) 2000 - 2009 Intel Corporation
Supports ACPI Specification Revision 4.0
ASL Input: ssdt_tpm.asl - 31 lines, 1111 bytes, 3 keywords
AML Output: SSDT_TPM.aml - 76 bytes, 3 named objects, 0 executable opcodes
Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 0 Optimizations
mv ssdt_tpm.hex ssdt_tpm.h
rm -f *.aml
make iasl
get-path: will use #!/usr/bin/python2.6 for python programs
make[9]: Entering directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi''
make[9]: `/usr/local/bin/iasl'' is up to date.
make[9]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi''
iasl -tc ssdt_pm.asl
Intel ACPI Component Architecture
ASL Optimizing Compiler version 20090730 [Aug 29 2009]
Copyright (C) 2000 - 2009 Intel Corporation
Supports ACPI Specification Revision 4.0
ASL Input: ssdt_pm.asl - 425 lines, 12754 bytes, 192 keywords
AML Output: SSDT_PM.aml - 1494 bytes, 64 named objects, 128 executable opcodes
Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 31 Optimizations
mv ssdt_pm.hex ssdt_pm.h
rm -f *.aml
gcc -O1 -fno-omit-frame-pointer -fno-optimize-sibling-calls -m32 -march=i686
-g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value
-Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .build.o.d
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs -Werror
-fno-stack-protector -fno-builtin -msoft-float -I. -I..
-I../../../../tools/include -c -o build.o build.c
In file included from build.c:21:
ssdt_pm.h:13: error: redefinition of ‘AmlCode’
ssdt_tpm.h:13: note: previous definition of ‘AmlCode’ was here
build.c: In function ‘construct_secondary_tables’:
build.c:184: error: ‘AmlCode_PM’ undeclared (first use in this function)
build.c:184: error: (Each undeclared identifier is reported only once
build.c:184: error: for each function it appears in.)
build.c:194: error: ‘AmlCode_TPM’ undeclared (first use in this function)
make[8]: *** [build.o] Error 1
make[8]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi''
make[7]: *** [subdir-all-acpi] Error 2
make[7]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader''
make[6]: *** [subdirs-all] Error 2
make[6]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader''
make[5]: *** [subdir-all-hvmloader] Error 2
make[5]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware''
make[4]: *** [subdirs-all] Error 2
make[4]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware''
make[3]: *** [all] Error 2
make[3]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware''
make[2]: *** [subdir-install-firmware] Error 2
make[2]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools''
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools''
make: *** [install-tools] Error 2
Any ideas about this Advanced Configuration and Power Interface code?
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Company Website: http://www.asiasoft.sg/
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 02:58 PM, Mr. Teo En Ming (Zhang Enming) wrote:
Hi
Anybody available today? I know it''s Saturday. :-)
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Company Website: http://www.asiasoft.sg/
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 11:48 AM, Mr. Teo En Ming (Zhang Enming) wrote:
Dear All,
After applying Intel VGA passthrough patches 1, 2 and 3, I have no problems with
"make xen", and "make install-xen". However, I have errors
with "make tools".
Here is the error output:
msoft-float -I. -I.. -I../../../../tools/include -c -o build.o build.c
build.c: In function ‘construct_secondary_tables’:
build.c:194: error: ‘AmlCode_TPM’ undeclared (first use in this function)
build.c:194: error: (Each undeclared identifier is reported only once
build.c:194: error: for each function it appears in.)
make[8]: *** [build.o] Error 1
make[8]: Leaving directory
`/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader/acpi''
make[7]: *** [subdir-all-acpi] Error 2
make[7]: Leaving directory
`/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader''
make[6]: *** [subdirs-all] Error 2
make[6]: Leaving directory
`/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader''
make[5]: *** [subdir-all-hvmloader] Error 2
make[5]: Leaving directory
`/usr/src/xen-unstable.hg-vgapt/tools/firmware''
make[4]: *** [subdirs-all] Error 2
make[4]: Leaving directory
`/usr/src/xen-unstable.hg-vgapt/tools/firmware''
make[3]: *** [all] Error 2
make[3]: Leaving directory
`/usr/src/xen-unstable.hg-vgapt/tools/firmware''
make[2]: *** [subdir-install-firmware] Error 2
make[2]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools''
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools''
make: *** [install-tools] Error 2
There is an undeclared identifier in tools/firmware/hvmloader/acpi/build.c
source code. Could you guys help me resolve this issue?
I had no problems compiling xen 3.5-unstable before applying the Intel vga
passthrough patches and before installing the Intel ACPI Component Architecture
compiler.
I have also attached Intel graphics passthrough patches 1, 2 and 3 for your
convenience here.
Thank you very much.
Hope I can get this working during the weekends.
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Company Website: http://www.asiasoft.sg/
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 10:17 AM, Mr. Teo En Ming (Zhang Enming) wrote:
Hi Tim,
I thought it should be gfx_passthru=2 in domU config?
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 06:42 AM, Tim Moore wrote:
Teo,
I have also performed the same exercise as yourself and I now have successfully
compiled all 3x patches into Xen, Qemu and the BIOS File Loading in the
hvmloader, this all compiles find on my system. Suggest you do a "make
clean" on the tools and start again !
After booting with the patched xen-unstable and adding the gfx-passthru=1
parameter to my HVM DomU, as I suspected - it still doesn''t work.
I have both a 9500GT and GTX260(primary) in my Intel DX58SO machine, tried
passing through either device and my primary display locks up ! (included hiding
with pci-stub)
I verified that the DomU was functional beforehand, as It also booted
successfully without the gfx-passthru parameter (and a vncviewer/cirrus display)
Unfortunately, I can''t debug further as my Primary display corrupts as
soon as the DomU starts. I did notice that in "xm debug" the
"Loading Gfx BIOS File.." message was displayed and the DomU did
continue to initialise the BIOS tables and such before finally locking. I then
(blindly) typed on a corrupt Dom0 console and managed to start kdm and login, so
the Dom0 was not completely trashed. But then after a few minutes, the machine
totally froze and had to hit the reset switch.
I`m no specialist but this looks like the VGA BIOS Re-initialisation is playing
havoc with the DomU and possibly the Dom0 graphics. I notice that both are also
using IRQ11 which could play a major part. Furthermore, there was a lot of debug
output in the qemu and xend.log indicating Base Address Register invalid access
and therefore it seems there may be a second obstacle.
Hope you have a better success than me !
For now, I would try re-compiling a fresh xen-unstable with carefully applied
patches .. oh! and don''t forget to enable the pci-stub driver for Dom0
(it''s not selected by default)
Tim
From:
xen-devel-bounces@lists.xensource.com<mailto:xen-devel-bounces@lists.xensource.com>
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Mr. Teo En Ming
(Zhang Enming)
Sent: 28 August 2009 21:14
To: enming.teo@asiasoftsea.net<mailto:enming.teo@asiasoftsea.net>
Cc: xen-devel@lists.xensource.com<mailto:xen-devel@lists.xensource.com>;
''Lin, Ben Y''; ''Kay, Allen M''; ''Jean
Guyader'';
Keir.Fraser@eu.citrix.com<mailto:Keir.Fraser@eu.citrix.com>;
weidong.han@intel.com<mailto:weidong.han@intel.com>;
bengheng@eecs.umich.edu<mailto:bengheng@eecs.umich.edu>
Subject: Re: [Xen-devel] [PATCH 2/2] graphics passthrough with VT-d
After applying the 1st and 2nd patch to xen-unstable successfully, I examined
the source codes Makefile and hvmloader.c in tools/firmware/hvmloader, compared
them to Weidong''s 3rd patch and I generated my own 3rd patch. Then I
used my own generated 3rd patch to apply patching for loading vga bios from
firmware file.
Here is my own generated 3rd patch instead of using Weidong''s 3rd
patch:
--- Makefile 2009-08-29 03:24:52.413083774 +0800
+++ Makefile 2009-08-29 03:29:12.763299633 +0800
@@ -50,6 +50,7 @@
roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \
../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h
sh ./mkhex rombios ../rombios/BIOS-bochs-latest > roms.h
+ sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin >> roms.h
sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin >>
roms.h
sh ./mkhex vgabios_cirrusvga \
../vgabios/VGABIOS-lgpl-latest.cirrus.bin >> roms.h
--- hvmloader.c 2009-08-29 03:26:06.911085797 +0800
+++ hvmloader.c 2009-08-29 03:31:43.172084995 +0800
@@ -688,9 +688,9 @@
vgabios_sz = round_option_rom(sizeof(vgabios_stdvga));
break;
case VGA_pt:
- printf("Loading VGABIOS of passthroughed gfx ...\n");
- vgabios_sz
- round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512);
+ printf("Loading Gfx Video BIOS from file ...\n");
+ memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt,
sizeof(vgabios_pt));
+ vgabios_sz = round_option_rom(sizeof(vgabios_pt));
break;
default:
printf("No emulated VGA adaptor ...\n");
I can "make xen" successfully but when I proceeded to "make
tools", errors were encountered.
Please see attached error output. How can I solve this problem?
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 12:59 AM, Mr. Teo En Ming (Zhang Enming) wrote:
OK I believe the 3rd patch is not incomplete but there''s a white space
issue when I copied the code from the mailing list into my vi.
See http://www.htdig.org/mail/2000/11/0167.html
When I used the -l flag to patch using the 3rd patch, the number of errors was
reduced.
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -l -p1 <
intel-gfx-passthru-patch-3.patch
patching file tools/firmware/hvmloader/Makefile
patching file tools/firmware/hvmloader/hvmloader.c
Hunk #1 FAILED at 688.
1 out of 1 hunk FAILED -- saving rejects to file
tools/firmware/hvmloader/hvmloader.c.rej
Now patching tools/firmware/hvmloader/Makefile is successful but patching
tools/firmware/hvmloader/hvmloader.c still failed.
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/28/2009 11:55 PM, Mr. Teo En Ming (Zhang Enming) wrote:
Dear Weidong,
A big big thanks for the vga passthrough patches for xen 3.5-unstable!!! These
are eagerly anticipated patches. As I did not study computer science and
computer architecture, I won''t be able to write those patches you guys
at Intel wrote.
I applied the following patches
xen-gfx-passthrough.patch<http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin>
and
qemu-gfx-passthrough.patch<http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin>
to xen 3.5-unstable without issues.
Then I tried to apply the 3rd patch you provided at
http://lists.xensource.com/archives/html/xen-devel/2009-08/msg01047.html
I saved the following code
<CODE>
diff -r 494be76c1ad9 tools/firmware/hvmloader/Makefile
--- a/tools/firmware/hvmloader/Makefile Thu Aug 27 16:54:33 2009 +0800
+++ b/tools/firmware/hvmloader/Makefile Thu Aug 27 17:22:01 2009 +0800
@@ -50,6 +50,7 @@ roms.h: ../rombios/BIOS-bochs-latest ../
roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \
../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h
sh ./mkhex rombios ../rombios/BIOS-bochs-latest > roms.h
+ sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin >> roms.h
sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin >> roms.h
sh ./mkhex vgabios_cirrusvga \
../vgabios/VGABIOS-lgpl-latest.cirrus.bin >> roms.h
diff -r 494be76c1ad9 tools/firmware/hvmloader/hvmloader.c
--- a/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 16:54:33 2009 +0800
+++ b/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 17:23:00 2009 +0800
@@ -688,9 +688,9 @@ int main(void)
vgabios_sz = round_option_rom(sizeof(vgabios_stdvga));
break;
case VGA_pt:
- printf("Loading Gfx Video BIOS from 0xC0000 ...\n");
- vgabios_sz
- round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512);
+ printf("Loading Gfx Video BIOS from file ...\n");
+ memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt,
sizeof(vgabios_pt));
+ vgabios_sz = round_option_rom(sizeof(vgabios_pt));
break;
default:
printf("No emulated VGA adaptor ...\n");
</CODE>
as intel-gfx-passthru-patch-3.patch and then I tried to apply the patch to xen
3.5-unstable. I got errors. I think it''s because the 3rd patch you
provided is incomplete.
Here''s my patching process:
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name vgabios
./tools/firmware/vgabios
./.hg/store/data/tools/firmware/vgabios
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cp ~enming/vgabios-pt.bin
tools/firmware/vgabios/
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ls tools/firmware/vgabios/
biossums.c clext.c Makefile TODO vbe.h
vgabios.h vgatables.h
BUGS COPYING Notes vbe.c vbetables-gen.c
vgabios-pt.bin
ChangeLog dataseghack README vbe_display_api.txt vgabios.c
vgafonts.h
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# pwd
/usr/src/xen-unstable.hg-vgapt
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wget
http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin
--2009-08-28 23:18:21--
http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin
Resolving lists.xensource.com... 70.42.241.110
Connecting to lists.xensource.com|70.42.241.110|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 12565 (12K) [application/octet-stream]
Saving to: `bincPiiAf0QWg.bin''
100%[======================================================================>]
12,565 30.7K/s in 0.4s
2009-08-28 23:18:22 (30.7 KB/s) - `bincPiiAf0QWg.bin'' saved
[12565/12565]
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv bincPiiAf0QWg.bin
xen-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi xen-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch <
xen-gfx-passthrough.patch
can''t find file to patch at input line 4
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff -r 5d7e7a250267 tools/firmware/hvmloader/config.h
|--- a/tools/firmware/hvmloader/config.h Wed Aug 26 18:28:44 2009 +0800
|+++ b/tools/firmware/hvmloader/config.h Thu Aug 27 16:54:24 2009 +0800
--------------------------
File to patch: ^C
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ex xen-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1 <
xen-gfx-passthrough.patch
patching file tools/firmware/hvmloader/config.h
patching file tools/firmware/hvmloader/hvmloader.c
patching file tools/libxc/ia64/xc_ia64_hvm_build.c
patching file tools/libxc/xc_hvm_build.c
patching file tools/libxc/xc_linux.c
patching file tools/libxc/xenctrl.h
patching file tools/libxc/xenguest.h
patching file tools/python/xen/lowlevel/xc/xc.c
patching file tools/python/xen/xend/XendConfig.py
Hunk #1 succeeded at 174 (offset -1 lines).
patching file tools/python/xen/xend/image.py
Hunk #1 succeeded at 780 (offset -6 lines).
Hunk #3 succeeded at 895 (offset -6 lines).
patching file tools/python/xen/xm/create.py
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wget
http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin
--2009-08-28 23:21:35--
http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin
Resolving lists.xensource.com... 70.42.241.110
Connecting to lists.xensource.com|70.42.241.110|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9841 (9.6K) [application/octet-stream]
Saving to: `binglLqkeq4Rj.bin''
100%[======================================================================>]
9,841 24.3K/s in 0.4s
2009-08-28 23:21:36 (24.3 KB/s) - `binglLqkeq4Rj.bin'' saved [9841/9841]
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv binglLqkeq4Rj.bin
qemu-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi qemu-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name hw
./tools/ioemu-remote/hw
./.hg/store/data/tools/ioemu/hw
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv qemu-gfx-passthrough.patch
tools/ioemu-remote/
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cd tools/ioemu-remote/
[root@fedora11-x86-64-host ioemu-remote]# patch -p1 < qemu-
qemu-aio.h qemu-img.c qemu-sockets.c
qemu-binfmt-conf.sh qemu-img.texi qemu-tech.texi
qemu-char.c qemu-lock.h qemu-timer.h
qemu-char.h qemu-log.h qemu-tool.c
qemu-common.h qemu-malloc.c qemu-xen.h
qemu-doc.texi qemu-nbd.c
qemu-gfx-passthrough.patch qemu-nbd.texi
[root@fedora11-x86-64-host ioemu-remote]# patch -p1 <
qemu-gfx-passthrough.patch
patching file hw/pass-through.c
patching file hw/pass-through.h
patching file hw/pc.c
patching file vl.c
[root@fedora11-x86-64-host ioemu-remote]# cd ..
[root@fedora11-x86-64-host tools]# cd ..
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi
intel-gfx-passthru-patch-3.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1 <
intel-gfx-passthru-patch-3.patch
patching file tools/firmware/hvmloader/Makefile
Hunk #1 FAILED at 50.
1 out of 1 hunk FAILED -- saving rejects to file
tools/firmware/hvmloader/Makefile.rej
patching file tools/firmware/hvmloader/hvmloader.c
patch: **** malformed patch at line 24: sizeof(vgabios_pt));
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi
intel-gfx-passthru-patch-3.patch
For everybody''s convenience, I have attached
intel-gfx-passthru-patch-3.patch and the firmware for my nVidia GeForce 8400 GS
PCI Express x16 graphics card in this email.
Please help me complete intel-gfx-passthru-patch-3.patch as I really need it.
Thank you very much!!!
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
This patch supports basic gfx passthrough on QEMU:
- disable emulated VGA adpater if there is passthroughed gfx
- register/unregister legacy VGA I/O ports and MMIOs for passthroughed gfx
Signed-off-by: Ben Lin
<ben.y.lin@intel.com><mailto:ben.y.lin@intel.com>
Signed-off-by: Weidong Han
<weidong.han@intel.com><mailto:weidong.han@intel.com>
No virus found in this incoming message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 8.5.409 / Virus Database: 270.13.69/2328 - Release Date: 08/27/09
18:02:00
No virus found in this outgoing message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 8.5.409 / Virus Database: 270.13.71/2330 - Release Date: 08/27/09
18:02:00
________________________________
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com<mailto:Xen-devel@lists.xensource.com>
http://lists.xensource.com/xen-devel
________________________________
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com<mailto:Xen-devel@lists.xensource.com>
http://lists.xensource.com/xen-devel
________________________________
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com<mailto: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
Actually yes, that helped a lot. And finally some progress on VGA
passthrough:
I have a X58 board with two ATI PCIe cards (RV770 and RV370). Currently
the RV770 is the primary card that is used during bootup and also with
Xorg in dom0 (radeonhd-only no fglrx).
With the latest patches in this thread and a recent Xenclient kernel
(haven''t tested 2.6.18 in a while) I was able to passthrough the RV370
to a HVM domu, seeing the BIOS boot and the OS loading in text mode and
then going into graphics mode.
Windows (both pre-installed images I had and new installation attempts
from CD) isn''t working yet, telling me I don''t have a fully
ACPI
compliant BIOS and quiting with a BSOD and STOP 0x5A, but I guess thats
a minor thing because I''ve got a stock Knoppix to boot and load in gfx
mode on the passthrough graphics card.
I really haven''t expected that much progress since I haven''t
heard about
any ATI tests at all for a while. Now I''m looking to get the STOP 0x5A
resolved and then passthrough additional devices (USB, Sound, Network,
Storage controller) and I''ll also try to swap the RV370 and RV770 to
get
some 3D performance into the HVM domU.
Observations so far:
- when creating the domU while I''m in text mode the dom0 stalls. It
doesn''t lock up completely but the terminal and keyboard are frozen.
When I create the domU while dom0 is running X everything is fine.
- none of the HVM domU''s have picked up the USB bus I tried to
passthrough (with keyboard and mouse attached). Not sure if I just
passed through the wrong bus or something else is broken
- after a domU is stopped it will still show the last image on the
passthrough gfx card (Knoppix desktop or Windows BSOD in my case)
- after a couple of restarts (xm destroy/ the hard way due to lack of
mouse/keyboard in domU) the secondary ATI gliteched and only showed a
gren screen, had to reboot to get it working again.
- I''ve tried Windows domUs with and without Viridian enabled,
didn''t
make a difference in regards to the STOP
I''ll continue to work on that and keep you posted. Any hints regarding
the STOP 0x5A and Keyboard/Mouse passthrough would be much appreciated.
(I actually have two keyboards connected, one on legacy PS/2 meant for
dom0 and a USB keyboard and USB mouse that I''d like to passthrough)
Best regards,
Christian
Keir Fraser wrote:> This is probably due to c/s 20137 and now fixed by c/s 20141.
>
> Thanks,
> Keir
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
I forgot to mention that you should change memory addresses in
xen-vBAR-pBAR.patch according to your MMIO BARs of your assigned gfx card.
For example, the output of 'lspci -s 01:00.0 -v':
01:00.0 VGA compatible controller: nVidia Corporation Unknown device
05ff (rev a1) (prog-if 00 [VGA controller])
Subsystem: nVidia Corporation Unknown device 0661
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at c2000000 (32-bit, non-prefetchable) [size=16M]
Memory at e0000000 (64-bit, prefetchable) [size=256M]
Memory at c0000000 (64-bit, non-prefetchable) [size=32M]
I/O ports at 9c00 [size=128]
Expansion ROM at bff00000 [disabled] [size=512K]
Capabilities: [60] Power Management version 3
Capabilities: [68] Message Signalled Interrupts: 64bit+ Queue=0/0
Enable+
Capabilities: [78] Express Endpoint IRQ 0
you can see I reserve above memories in dsdt.asl in xen-vBAR-pBAR.patch. you
should replace them with memories of your gfx.
Regards,
Weidong
________________________________
From: Tim Moore [mailto:timothy.moore@expidas.net]
Sent: 2009年9月1日 3:35
To: Han, Weidong
Cc: 'xen-devel@lists.xensource.com';
'enming.teo@asiasoftsea.net'
Subject: RE: [Xen-devel] graphics passthrough with VT-d
Hi Weidong,
Here are my findings so far, it still doesn’t work but I have not experienced a
crash or Dom0 lockup, and I have switched to 2.6.18-Dom0 which may also help ...
64bit Hypervisor (xen-unstable.hg 31/08/09)
Dom0 – 2.6.18-xen-dom0 (from xenbits)
Patches applied:
./qemu-gfx-passthrough.patch
./qemu-change-for-vBAR-pBAR.patch
./qemu-claim-vga-cycle-for-secondary-gfx-passthrough.patch
./xen-vBAR-pBAR.patch
./xen-gfx-passthrough.patch
./xen-load-vbios-file.patch
02:00.0 - Primary GFX (Dom0) Console: NVidia Geforce GTX260
03:00.0 - Secondary GFX (DomU): NVidia Geforce 9500GT
Qemu:
Warning: attempted read from physical address 0xe0000000 in xen platform mmio
space
And
pt_pci_write_config: Warning: Guest attempt to set address to unused Base
Address Register. [00:04.0][Offset:30h][Length:4]
Hope this helps,
Tim
From: Han, Weidong [mailto:weidong.han@intel.com]
Sent: 31 August 2009 09:47
To: 'enming.teo@asiasoftsea.net'; Tim Moore
Cc: 'xen-devel@lists.xensource.com'
Subject: RE: [Xen-devel] graphics passthrough with VT-d
Teo,
I attached some experimental patches for you to try to sthorugh Geforce 8400 GS.
Based on my patches posted last Friday, pls follow below instructions:
1. apply xen-load-vbios-file.patch to xen-unstable.hg
this patch supports to load vga bios from a file.
2. apply xen-vBAR-pBAR.patch to xen-unstable.hg
this patch is used to 1:1 map between vBAR and pBAR
3. apply qemu-change-for-vBAR-pBAR.patch to ioemu-remote (qemu tree).
this patch is used to 1:1 map between vBAR and pBAR on qemu side
4. apply qemu-claim-cycle-for-secondary-gfx-passthrough.patch
it's needed if you want to assign the secondary gfx to guest.
5. cd xen-unstable.hg
6. make clean
7. copy the vga bios file to
xen-unstabl.hg/tools/firmware/vgabios/vgabios-pt.bin
8. make; make install
9. reboot the system. or xend restart. then passthrough gfx to guest ...
Regards,
Weidong
________________________________
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Mr. Teo En Ming
(Zhang Enming)
Sent: 2009年8月29日 22:13
To: timothy.moore@expidas.net
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] graphics passthrough with VT-d
Hi Timothy,
Yes, I renamed the firmware file of nVidia Geforce 8400 GS to vgabios-pt.bin and
placed it in the source directory tools/firmware/vgabios.
Weidong had said Intel has the 1:1 mapping patches. Let's hope he will
release the patch soon to do pBAR:vBAR.
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Company Website: http://www.asiasoft.sg/
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 09:29 PM, Tim Moore wrote:
Teo,
Did you rename your Nvidia BIOS and copy it into the hvmloader source tree as
required ?
It should get compiled into roms.h in the hvmloader folder - I made sure it was
there as the xen buildroot seems to delete it randomly ...
I think we are now up against the Base Address Register issue where the Nvidia
driver is expecting to see the card at the Physical BAR Addresses and in the
DomU these are re-mapped to different address space ... this is a problem with
the Nvidia binary driver and therefore a workaround in xen is maybe needed.
That said, I'm not sure if the Nvidia BIOS likes to be re-executed and may
also be an issue ...
Tim
From: Mr. Teo En Ming (Zhang Enming) [mailto:enming.teo@asiasoftsea.net]
Sent: 29 August 2009 14:21
To: enming.teo@asiasoftsea.net<mailto:enming.teo@asiasoftsea.net>
Cc: Tim Moore;
xen-devel@lists.xensource.com<mailto:xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] graphics passthrough with VT-d
Dear All,
I have applied the following patches to xen 3.5-unstable
1) intel-gfx-passthru-patch01.patch
2) intel-gfx-passthru-patch02.patch
3) intel-gfx-passthru-patch03.patch
4) enming-patch04.patch
and compiled xen 3.5-unstable successfully (both hypervisor and tools).
i rebooted into this newly compiled Xen hypervisor which supports loading vga
bios from firmware file of nVidia Geforce 8400 GS PCI Express x16.
After dom0 has booted up, I executed the following script to hide nVidia Geforce
8400 GS from dom0.
[enming@fedora11-x86-64-host scripts]$ cat bind-devices-pci-stub.sh
#!/bin/sh
echo "10de 06e4" > /sys/bus/pci/drivers/pci-stub/new_id
echo "0000:01:00.0" >
/sys/bus/pci/devices/0000:01:00.0/driver/unbind
echo "0000:01:00.0" > /sys/bus/pci/drivers/pci-stub/bind
I also assigned the nVidia Geforce 8400 GS to my Windows XP Home HVM domU.
pci = [ '01:00.0' ]
I also specified gfx_passthru=2.
Do note that I booted up with onboard Intel GMA4500 as the primary video
adapter. Hence dom 0 has onboard graphics and Windows XP HVM domU has nvidia
graphics.
Then I started Windows XP Home HVM DomU.
Very soon, my Dom 0's display was garbaged and X server on Dom 0 totally
froze and became unresponsive. I cannot switch to any ttys.
However, I was still able to vnc into my Windows XP Home HVM Dom U. I had
earlier installed a VNC server into my Windows XP guest. After remoting in to my
Windows XP DomU through vnc, I found that NVIDIA Geforce 8400 GS cannot be
initialized and no resources are available for this graphics card.
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Company Website: http://www.asiasoft.sg/
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 08:25 PM, Mr. Teo En Ming (Zhang Enming) wrote:
Hi All,
I have solved the problem encountered below when building tools for xen
3.5-unstable. The compile problem exists because I downloaded and compiled the
latest version of Intel ACPI Component Architecture compiler version 20090730.
And I used this latest compiler during "make tools" for xen-unstable.
In original xen-unstable source codes cloned from xensoure mercurial repository,
the header files ssdt_pm.h and ssdt_tpm.h in source directory
tools/firmware/hvmloader/acpi/ are generated by
/*
*
* Intel ACPI Component Architecture
* ASL Optimizing Compiler version 20061109 [May 18 2007]
* Copyright (C) 2000 - 2006 Intel Corporation
* Supports ACPI Specification Revision 3.0a
*
* Compilation of "ssdt_pm.asl" - Sun Oct 12 23:57:51 2008
*
* C source code output
*
*/
In original ssdt_pm.h, it has "unsigned char AmlCode_PM[] =".
In original ssdt_tpm.h, it has "unsigned char AmlCode_TPM[] =".
Hence there was no problem with "make tools".
But, I downloaded, compiled and used
/*
*
* Intel ACPI Component Architecture
* ASL Optimizing Compiler version 20090730 [Aug 29 2009]
* Copyright (C) 2000 - 2009 Intel Corporation
* Supports ACPI Specification Revision 4.0
*
* Compilation of "ssdt_pm.asl" - Sat Aug 29 18:55:40 2009
*
* C source code output
*
*/
So the *new* ssdt_pm.h contains:
/*
*
* Intel ACPI Component Architecture
* ASL Optimizing Compiler version 20090730 [Aug 29 2009]
* Copyright (C) 2000 - 2009 Intel Corporation
* Supports ACPI Specification Revision 4.0
*
* Compilation of "ssdt_pm.asl" - Sat Aug 29 18:55:40 2009
*
* C source code output
*
*/
unsigned char AmlCode[] {
0x53,0x53,0x44,0x54,0xD6,0x05,0x00,0x00, /* 00000000
"SSDT...." */
0x02,0xB9,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008
"..Xen..." */
0x48,0x56,0x4D,0x00,0x00,0x00,0x00,0x00, /* 00000010
"HVM....." */
0x00,0x00,0x00,0x00,0x49,0x4E,0x54,0x4C, /* 00000018
"....INTL" */
0x30,0x07,0x09,0x20,0x10,0x41,0x5B,0x5C, /* 00000020 "0..
.A[\" */
0x5F,0x53,0x42,0x5F,0x5B,0x80,0x44,0x42, /* 00000028
"_SB_[.DB" */
0x47,0x41,0x01,0x0B,0x40,0xB0,0x01,0x5B, /* 00000030
"GA..@..["<mailto:GA..@..%5B> */
0x81,0x0B,0x44,0x42,0x47,0x41,0x01,0x44, /* 00000038
"..DBGA.D" */
0x42,0x47,0x31,0x08,0x5B,0x80,0x44,0x42, /* 00000040
"BG1.[.DB" */
0x47,0x42,0x01,0x0B,0x44,0xB0,0x01,0x5B, /* 00000048
"GB..D..[" */
0x81,0x0B,0x44,0x42,0x47,0x42,0x01,0x44, /* 00000050
"..DBGB.D" */
0x42,0x47,0x32,0x08,0x5B,0x80,0x44,0x42, /* 00000058
"BG2.[.DB" */
0x47,0x43,0x01,0x0B,0x46,0xB0,0x01,0x5B, /* 00000060
"GC..F..[" */
0x81,0x0B,0x44,0x42,0x47,0x43,0x01,0x44, /* 00000068
"..DBGC.D" */
0x42,0x47,0x33,0x08,0x5B,0x80,0x44,0x42, /* 00000070
"BG3.[.DB" */
0x47,0x44,0x01,0x0B,0x48,0xB0,0x01,0x5B, /* 00000078
"GD..H..[" */
0x81,0x0B,0x44,0x42,0x47,0x44,0x01,0x44, /* 00000080
"..DBGD.D" */
0x42,0x47,0x34,0x08,0x5B,0x80,0x50,0x52, /* 00000088
"BG4.[.PR" */
0x54,0x31,0x01,0x0A,0xB2,0x0A,0x02,0x5B, /* 00000090
"T1.....[" */
0x81,0x10,0x50,0x52,0x54,0x31,0x01,0x50, /* 00000098
"..PRT1.P" */
0x42,0x32,0x5F,0x08,0x50,0x42,0x32,0x41, /* 000000A0
"B2_.PB2A" */
0x08,0x5B,0x80,0x50,0x52,0x54,0x32,0x01, /* 000000A8
".[.PRT2." */
0x0A,0x86,0x01,0x5B,0x81,0x0B,0x50,0x52, /* 000000B0
"...[..PR" */
0x54,0x32,0x01,0x50,0x38,0x36,0x5F,0x08, /* 000000B8
"T2.P86_." */
0x5B,0x80,0x50,0x52,0x54,0x33,0x01,0x0A, /* 000000C0
"[.PRT3.." */
0x88,0x01,0x5B,0x81,0x0B,0x50,0x52,0x54, /* 000000C8
"..[..PRT" */
0x33,0x01,0x50,0x38,0x38,0x5F,0x08,0x5B, /* 000000D0
"3.P88_.[" */
0x01,0x53,0x59,0x4E,0x43,0x01,0x08,0x42, /* 000000D8
".SYNC..B" */
0x55,0x46,0x30,0x11,0x04,0x0B,0x00,0x01, /* 000000E0
"UF0....." */
0x08,0x42,0x55,0x46,0x31,0x11,0x03,0x0A, /* 000000E8
".BUF1..." */
0x08,0x8B,0x42,0x55,0x46,0x31,0x00,0x42, /* 000000F0
"..BUF1.B" */
0x55,0x46,0x41,0x8B,0x42,0x55,0x46,0x31, /* 000000F8
"UFA.BUF1" */
0x0A,0x04,0x42,0x55,0x46,0x42,0x14,0x14, /* 00000100
"..BUFB.." */
And the *new* ssdt_tpm.h contains:
/*
*
* Intel ACPI Component Architecture
* ASL Optimizing Compiler version 20090730 [Aug 29 2009]
* Copyright (C) 2000 - 2009 Intel Corporation
* Supports ACPI Specification Revision 4.0
*
* Compilation of "ssdt_tpm.asl" - Sat Aug 29 18:55:40 2009
*
* C source code output
*
*/
unsigned char AmlCode[] {
0x53,0x53,0x44,0x54,0x4C,0x00,0x00,0x00, /* 00000000
"SSDTL..." */
0x02,0x2A,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008
".*Xen..." */
0x48,0x56,0x4D,0x00,0x00,0x00,0x00,0x00, /* 00000010
"HVM....." */
0x00,0x00,0x00,0x00,0x49,0x4E,0x54,0x4C, /* 00000018
"....INTL" */
0x30,0x07,0x09,0x20,0x5B,0x82,0x26,0x54, /* 00000020 "0..
[.&T" */
0x50,0x4D,0x5F,0x08,0x5F,0x48,0x49,0x44, /* 00000028
"PM_._HID" */
0x0C,0x41,0xD0,0x0C,0x31,0x08,0x5F,0x43, /* 00000030
".A..1._C" */
0x52,0x53,0x11,0x11,0x0A,0x0E,0x86,0x09, /* 00000038
"RS......" */
0x00,0x01,0x00,0x00,0xD4,0xFE,0x00,0x50, /* 00000040
".......P" */
0x00,0x00,0x79,0x00,
};
which are both wrong.
In ssdt_pm.h, I have to change "unsigned char AmlCode[]" to
"unsigned char AmlCode_PM[]".
In ssdt_tpm.h, I have to change "unsigned char AmlCode[]" to
"unsigned char AmlCode_TPM[]".
Then "make tools" is able to complete successfully.
I have created a patch for anybody who may be using the *latest* version of
Intel ACPI CA compiler version 20090730 and attached it here.
Patch file filename enming-patch04.patch:
<CODE>
Patch created by Teo En Ming (Zhang Enming) on 29 August 2009 Saturday at 8:00
P.M. Singapore Time
Email #1: enming.teo@asiasoftsea.net<mailto:enming.teo@asiasoftsea.net>
Email #2:
space.time.universe@gmail.com<mailto:space.time.universe@gmail.com>
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Mobile Phone: +65-9648-9798
--- ssdt_pm.h 2009-08-29 19:54:52.653088000 +0800
+++ ssdt_pm.h 2009-08-29 19:56:51.813088550 +0800
@@ -10,7 +10,7 @@
* C source code output
*
*/
-unsigned char AmlCode[] +unsigned char AmlCode_PM[] {
0x53,0x53,0x44,0x54,0xD6,0x05,0x00,0x00, /* 00000000
"SSDT...." */
0x02,0xB9,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008
"..Xen..." */
--- ssdt_tpm.h 2009-08-29 19:55:44.578738954 +0800
+++ ssdt_tpm.h 2009-08-29 19:57:27.896638884 +0800
@@ -10,7 +10,7 @@
* C source code output
*
*/
-unsigned char AmlCode[] +unsigned char AmlCode_TPM[] {
0x53,0x53,0x44,0x54,0x4C,0x00,0x00,0x00, /* 00000000
"SSDTL..." */
0x02,0x2A,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008
".*Xen..." */
</CODE>
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Company Website: http://www.asiasoft.sg/
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 07:03 PM, Mr. Teo En Ming (Zhang Enming) wrote:
Hi,
I cloned http://xenbits.xensource.com/xen-unstable.hg again today. I tried
applying the three Intel gfx passthrough patches to xen-unstable. When I
"make tools", I get the same error again:
make[7]: Entering directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader'
make -C acpi all
get-path: will use #!/usr/bin/python2.6 for python programs
make[8]: Entering directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'
make iasl
get-path: will use #!/usr/bin/python2.6 for python programs
make[9]: Entering directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'
make[9]: `/usr/local/bin/iasl' is up to date.
make[9]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'
iasl -tc ssdt_tpm.asl
Intel ACPI Component Architecture
ASL Optimizing Compiler version 20090730 [Aug 29 2009]
Copyright (C) 2000 - 2009 Intel Corporation
Supports ACPI Specification Revision 4.0
ASL Input: ssdt_tpm.asl - 31 lines, 1111 bytes, 3 keywords
AML Output: SSDT_TPM.aml - 76 bytes, 3 named objects, 0 executable opcodes
Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 0 Optimizations
mv ssdt_tpm.hex ssdt_tpm.h
rm -f *.aml
make iasl
get-path: will use #!/usr/bin/python2.6 for python programs
make[9]: Entering directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'
make[9]: `/usr/local/bin/iasl' is up to date.
make[9]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'
iasl -tc ssdt_pm.asl
Intel ACPI Component Architecture
ASL Optimizing Compiler version 20090730 [Aug 29 2009]
Copyright (C) 2000 - 2009 Intel Corporation
Supports ACPI Specification Revision 4.0
ASL Input: ssdt_pm.asl - 425 lines, 12754 bytes, 192 keywords
AML Output: SSDT_PM.aml - 1494 bytes, 64 named objects, 128 executable opcodes
Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 31 Optimizations
mv ssdt_pm.hex ssdt_pm.h
rm -f *.aml
gcc -O1 -fno-omit-frame-pointer -fno-optimize-sibling-calls -m32 -march=i686
-g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value
-Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .build.o.d
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs -Werror
-fno-stack-protector -fno-builtin -msoft-float -I. -I..
-I../../../../tools/include -c -o build.o build.c
In file included from build.c:21:
ssdt_pm.h:13: error: redefinition of ‘AmlCode’
ssdt_tpm.h:13: note: previous definition of ‘AmlCode’ was here
build.c: In function ‘construct_secondary_tables’:
build.c:184: error: ‘AmlCode_PM’ undeclared (first use in this function)
build.c:184: error: (Each undeclared identifier is reported only once
build.c:184: error: for each function it appears in.)
build.c:194: error: ‘AmlCode_TPM’ undeclared (first use in this function)
make[8]: *** [build.o] Error 1
make[8]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'
make[7]: *** [subdir-all-acpi] Error 2
make[7]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader'
make[6]: *** [subdirs-all] Error 2
make[6]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader'
make[5]: *** [subdir-all-hvmloader] Error 2
make[5]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware'
make[4]: *** [subdirs-all] Error 2
make[4]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware'
make[3]: *** [all] Error 2
make[3]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware'
make[2]: *** [subdir-install-firmware] Error 2
make[2]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools'
make: *** [install-tools] Error 2
Any ideas about this Advanced Configuration and Power Interface code?
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Company Website: http://www.asiasoft.sg/
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 02:58 PM, Mr. Teo En Ming (Zhang Enming) wrote:
Hi
Anybody available today? I know it's Saturday. :-)
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Company Website: http://www.asiasoft.sg/
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 11:48 AM, Mr. Teo En Ming (Zhang Enming) wrote:
Dear All,
After applying Intel VGA passthrough patches 1, 2 and 3, I have no problems with
"make xen", and "make install-xen". However, I have errors
with "make tools".
Here is the error output:
msoft-float -I. -I.. -I../../../../tools/include -c -o build.o build.c
build.c: In function ‘construct_secondary_tables’:
build.c:194: error: ‘AmlCode_TPM’ undeclared (first use in this function)
build.c:194: error: (Each undeclared identifier is reported only once
build.c:194: error: for each function it appears in.)
make[8]: *** [build.o] Error 1
make[8]: Leaving directory
`/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader/acpi'
make[7]: *** [subdir-all-acpi] Error 2
make[7]: Leaving directory
`/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader'
make[6]: *** [subdirs-all] Error 2
make[6]: Leaving directory
`/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader'
make[5]: *** [subdir-all-hvmloader] Error 2
make[5]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'
make[4]: *** [subdirs-all] Error 2
make[4]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'
make[2]: *** [subdir-install-firmware] Error 2
make[2]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools'
make: *** [install-tools] Error 2
There is an undeclared identifier in tools/firmware/hvmloader/acpi/build.c
source code. Could you guys help me resolve this issue?
I had no problems compiling xen 3.5-unstable before applying the Intel vga
passthrough patches and before installing the Intel ACPI Component Architecture
compiler.
I have also attached Intel graphics passthrough patches 1, 2 and 3 for your
convenience here.
Thank you very much.
Hope I can get this working during the weekends.
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Company Website: http://www.asiasoft.sg/
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 10:17 AM, Mr. Teo En Ming (Zhang Enming) wrote:
Hi Tim,
I thought it should be gfx_passthru=2 in domU config?
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 06:42 AM, Tim Moore wrote:
Teo,
I have also performed the same exercise as yourself and I now have successfully
compiled all 3x patches into Xen, Qemu and the BIOS File Loading in the
hvmloader, this all compiles find on my system. Suggest you do a "make
clean" on the tools and start again !
After booting with the patched xen-unstable and adding the gfx-passthru=1
parameter to my HVM DomU, as I suspected - it still doesn't work.
I have both a 9500GT and GTX260(primary) in my Intel DX58SO machine, tried
passing through either device and my primary display locks up ! (included hiding
with pci-stub)
I verified that the DomU was functional beforehand, as It also booted
successfully without the gfx-passthru parameter (and a vncviewer/cirrus display)
Unfortunately, I can't debug further as my Primary display corrupts as soon
as the DomU starts. I did notice that in "xm debug" the "Loading
Gfx BIOS File.." message was displayed and the DomU did continue to
initialise the BIOS tables and such before finally locking. I then (blindly)
typed on a corrupt Dom0 console and managed to start kdm and login, so the Dom0
was not completely trashed. But then after a few minutes, the machine totally
froze and had to hit the reset switch.
I`m no specialist but this looks like the VGA BIOS Re-initialisation is playing
havoc with the DomU and possibly the Dom0 graphics. I notice that both are also
using IRQ11 which could play a major part. Furthermore, there was a lot of debug
output in the qemu and xend.log indicating Base Address Register invalid access
and therefore it seems there may be a second obstacle.
Hope you have a better success than me !
For now, I would try re-compiling a fresh xen-unstable with carefully applied
patches .. oh! and don't forget to enable the pci-stub driver for Dom0
(it's not selected by default)
Tim
From:
xen-devel-bounces@lists.xensource.com<mailto:xen-devel-bounces@lists.xensource.com>
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Mr. Teo En Ming
(Zhang Enming)
Sent: 28 August 2009 21:14
To: enming.teo@asiasoftsea.net<mailto:enming.teo@asiasoftsea.net>
Cc: xen-devel@lists.xensource.com<mailto:xen-devel@lists.xensource.com>;
'Lin, Ben Y'; 'Kay, Allen M'; 'Jean Guyader';
Keir.Fraser@eu.citrix.com<mailto:Keir.Fraser@eu.citrix.com>;
weidong.han@intel.com<mailto:weidong.han@intel.com>;
bengheng@eecs.umich.edu<mailto:bengheng@eecs.umich.edu>
Subject: Re: [Xen-devel] [PATCH 2/2] graphics passthrough with VT-d
After applying the 1st and 2nd patch to xen-unstable successfully, I examined
the source codes Makefile and hvmloader.c in tools/firmware/hvmloader, compared
them to Weidong's 3rd patch and I generated my own 3rd patch. Then I used my
own generated 3rd patch to apply patching for loading vga bios from firmware
file.
Here is my own generated 3rd patch instead of using Weidong's 3rd patch:
--- Makefile 2009-08-29 03:24:52.413083774 +0800
+++ Makefile 2009-08-29 03:29:12.763299633 +0800
@@ -50,6 +50,7 @@
roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \
../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h
sh ./mkhex rombios ../rombios/BIOS-bochs-latest > roms.h
+ sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin >> roms.h
sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin >>
roms.h
sh ./mkhex vgabios_cirrusvga \
../vgabios/VGABIOS-lgpl-latest.cirrus.bin >> roms.h
--- hvmloader.c 2009-08-29 03:26:06.911085797 +0800
+++ hvmloader.c 2009-08-29 03:31:43.172084995 +0800
@@ -688,9 +688,9 @@
vgabios_sz = round_option_rom(sizeof(vgabios_stdvga));
break;
case VGA_pt:
- printf("Loading VGABIOS of passthroughed gfx ...\n");
- vgabios_sz
- round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512);
+ printf("Loading Gfx Video BIOS from file ...\n");
+ memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt,
sizeof(vgabios_pt));
+ vgabios_sz = round_option_rom(sizeof(vgabios_pt));
break;
default:
printf("No emulated VGA adaptor ...\n");
I can "make xen" successfully but when I proceeded to "make
tools", errors were encountered.
Please see attached error output. How can I solve this problem?
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 12:59 AM, Mr. Teo En Ming (Zhang Enming) wrote:
OK I believe the 3rd patch is not incomplete but there's a white space issue
when I copied the code from the mailing list into my vi.
See http://www.htdig.org/mail/2000/11/0167.html
When I used the -l flag to patch using the 3rd patch, the number of errors was
reduced.
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -l -p1 <
intel-gfx-passthru-patch-3.patch
patching file tools/firmware/hvmloader/Makefile
patching file tools/firmware/hvmloader/hvmloader.c
Hunk #1 FAILED at 688.
1 out of 1 hunk FAILED -- saving rejects to file
tools/firmware/hvmloader/hvmloader.c.rej
Now patching tools/firmware/hvmloader/Makefile is successful but patching
tools/firmware/hvmloader/hvmloader.c still failed.
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/28/2009 11:55 PM, Mr. Teo En Ming (Zhang Enming) wrote:
Dear Weidong,
A big big thanks for the vga passthrough patches for xen 3.5-unstable!!! These
are eagerly anticipated patches. As I did not study computer science and
computer architecture, I won't be able to write those patches you guys at
Intel wrote.
I applied the following patches
xen-gfx-passthrough.patch<http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin>
and
qemu-gfx-passthrough.patch<http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin>
to xen 3.5-unstable without issues.
Then I tried to apply the 3rd patch you provided at
http://lists.xensource.com/archives/html/xen-devel/2009-08/msg01047.html
I saved the following code
<CODE>
diff -r 494be76c1ad9 tools/firmware/hvmloader/Makefile
--- a/tools/firmware/hvmloader/Makefile Thu Aug 27 16:54:33 2009 +0800
+++ b/tools/firmware/hvmloader/Makefile Thu Aug 27 17:22:01 2009 +0800
@@ -50,6 +50,7 @@ roms.h: ../rombios/BIOS-bochs-latest ../
roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \
../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h
sh ./mkhex rombios ../rombios/BIOS-bochs-latest > roms.h
+ sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin >> roms.h
sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin >> roms.h
sh ./mkhex vgabios_cirrusvga \
../vgabios/VGABIOS-lgpl-latest.cirrus.bin >> roms.h
diff -r 494be76c1ad9 tools/firmware/hvmloader/hvmloader.c
--- a/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 16:54:33 2009 +0800
+++ b/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 17:23:00 2009 +0800
@@ -688,9 +688,9 @@ int main(void)
vgabios_sz = round_option_rom(sizeof(vgabios_stdvga));
break;
case VGA_pt:
- printf("Loading Gfx Video BIOS from 0xC0000 ...\n");
- vgabios_sz
- round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512);
+ printf("Loading Gfx Video BIOS from file ...\n");
+ memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt,
sizeof(vgabios_pt));
+ vgabios_sz = round_option_rom(sizeof(vgabios_pt));
break;
default:
printf("No emulated VGA adaptor ...\n");
</CODE>
as intel-gfx-passthru-patch-3.patch and then I tried to apply the patch to xen
3.5-unstable. I got errors. I think it's because the 3rd patch you provided
is incomplete.
Here's my patching process:
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name vgabios
./tools/firmware/vgabios
./.hg/store/data/tools/firmware/vgabios
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cp ~enming/vgabios-pt.bin
tools/firmware/vgabios/
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ls tools/firmware/vgabios/
biossums.c clext.c Makefile TODO vbe.h
vgabios.h vgatables.h
BUGS COPYING Notes vbe.c vbetables-gen.c
vgabios-pt.bin
ChangeLog dataseghack README vbe_display_api.txt vgabios.c
vgafonts.h
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# pwd
/usr/src/xen-unstable.hg-vgapt
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wget
http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin
--2009-08-28 23:18:21--
http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin
Resolving lists.xensource.com... 70.42.241.110
Connecting to lists.xensource.com|70.42.241.110|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 12565 (12K) [application/octet-stream]
Saving to: `bincPiiAf0QWg.bin'
100%[======================================================================>]
12,565 30.7K/s in 0.4s
2009-08-28 23:18:22 (30.7 KB/s) - `bincPiiAf0QWg.bin' saved [12565/12565]
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv bincPiiAf0QWg.bin
xen-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi xen-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch <
xen-gfx-passthrough.patch
can't find file to patch at input line 4
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff -r 5d7e7a250267 tools/firmware/hvmloader/config.h
|--- a/tools/firmware/hvmloader/config.h Wed Aug 26 18:28:44 2009 +0800
|+++ b/tools/firmware/hvmloader/config.h Thu Aug 27 16:54:24 2009 +0800
--------------------------
File to patch: ^C
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ex xen-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1 <
xen-gfx-passthrough.patch
patching file tools/firmware/hvmloader/config.h
patching file tools/firmware/hvmloader/hvmloader.c
patching file tools/libxc/ia64/xc_ia64_hvm_build.c
patching file tools/libxc/xc_hvm_build.c
patching file tools/libxc/xc_linux.c
patching file tools/libxc/xenctrl.h
patching file tools/libxc/xenguest.h
patching file tools/python/xen/lowlevel/xc/xc.c
patching file tools/python/xen/xend/XendConfig.py
Hunk #1 succeeded at 174 (offset -1 lines).
patching file tools/python/xen/xend/image.py
Hunk #1 succeeded at 780 (offset -6 lines).
Hunk #3 succeeded at 895 (offset -6 lines).
patching file tools/python/xen/xm/create.py
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wget
http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin
--2009-08-28 23:21:35--
http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin
Resolving lists.xensource.com... 70.42.241.110
Connecting to lists.xensource.com|70.42.241.110|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9841 (9.6K) [application/octet-stream]
Saving to: `binglLqkeq4Rj.bin'
100%[======================================================================>]
9,841 24.3K/s in 0.4s
2009-08-28 23:21:36 (24.3 KB/s) - `binglLqkeq4Rj.bin' saved [9841/9841]
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv binglLqkeq4Rj.bin
qemu-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi qemu-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name hw
./tools/ioemu-remote/hw
./.hg/store/data/tools/ioemu/hw
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv qemu-gfx-passthrough.patch
tools/ioemu-remote/
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cd tools/ioemu-remote/
[root@fedora11-x86-64-host ioemu-remote]# patch -p1 < qemu-
qemu-aio.h qemu-img.c qemu-sockets.c
qemu-binfmt-conf.sh qemu-img.texi qemu-tech.texi
qemu-char.c qemu-lock.h qemu-timer.h
qemu-char.h qemu-log.h qemu-tool.c
qemu-common.h qemu-malloc.c qemu-xen.h
qemu-doc.texi qemu-nbd.c
qemu-gfx-passthrough.patch qemu-nbd.texi
[root@fedora11-x86-64-host ioemu-remote]# patch -p1 <
qemu-gfx-passthrough.patch
patching file hw/pass-through.c
patching file hw/pass-through.h
patching file hw/pc.c
patching file vl.c
[root@fedora11-x86-64-host ioemu-remote]# cd ..
[root@fedora11-x86-64-host tools]# cd ..
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi
intel-gfx-passthru-patch-3.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1 <
intel-gfx-passthru-patch-3.patch
patching file tools/firmware/hvmloader/Makefile
Hunk #1 FAILED at 50.
1 out of 1 hunk FAILED -- saving rejects to file
tools/firmware/hvmloader/Makefile.rej
patching file tools/firmware/hvmloader/hvmloader.c
patch: **** malformed patch at line 24: sizeof(vgabios_pt));
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi
intel-gfx-passthru-patch-3.patch
For everybody's convenience, I have attached
intel-gfx-passthru-patch-3.patch and the firmware for my nVidia GeForce 8400 GS
PCI Express x16 graphics card in this email.
Please help me complete intel-gfx-passthru-patch-3.patch as I really need it.
Thank you very much!!!
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
This patch supports basic gfx passthrough on QEMU:
- disable emulated VGA adpater if there is passthroughed gfx
- register/unregister legacy VGA I/O ports and MMIOs for passthroughed gfx
Signed-off-by: Ben Lin
<ben.y.lin@intel.com><mailto:ben.y.lin@intel.com>
Signed-off-by: Weidong Han
<weidong.han@intel.com><mailto:weidong.han@intel.com>
No virus found in this incoming message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 8.5.409 / Virus Database: 270.13.69/2328 - Release Date: 08/27/09
18:02:00
No virus found in this outgoing message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 8.5.409 / Virus Database: 270.13.71/2330 - Release Date: 08/27/09
18:02:00
________________________________
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com<mailto:Xen-devel@lists.xensource.com>
http://lists.xensource.com/xen-devel
________________________________
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com<mailto:Xen-devel@lists.xensource.com>
http://lists.xensource.com/xen-devel
________________________________
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com<mailto: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
Hi Tim,
I suspect your vga bios file is incorrect, its size is very small. I found
following VGA bios in xm_dmesg.log:
...
(XEN) HVM1: BIOS map:
(XEN) HVM1: c0000-c07ff: VGA BIOS
...
You can check if the VGA bios is really loaded. You can use 'xxd
vgabios-pt.bin' to see the VGA bios content, of course you can see the size.
After you apply the patches I posted and mak the code, you can see vgabios_pt[]
in xen-unstable.hg/tools/firmware/hvmloader/roms.h. content of vgabios_pt[]
should be the same with output of 'xxd vgabios-pt.bin'.
Regards,
Weidong
________________________________
From: Tim Moore [mailto:timothy.moore@expidas.net]
Sent: 2009年9月1日 3:35
To: Han, Weidong
Cc: 'xen-devel@lists.xensource.com';
'enming.teo@asiasoftsea.net'
Subject: RE: [Xen-devel] graphics passthrough with VT-d
Hi Weidong,
Here are my findings so far, it still doesn’t work but I have not experienced a
crash or Dom0 lockup, and I have switched to 2.6.18-Dom0 which may also help ...
64bit Hypervisor (xen-unstable.hg 31/08/09)
Dom0 – 2.6.18-xen-dom0 (from xenbits)
Patches applied:
./qemu-gfx-passthrough.patch
./qemu-change-for-vBAR-pBAR.patch
./qemu-claim-vga-cycle-for-secondary-gfx-passthrough.patch
./xen-vBAR-pBAR.patch
./xen-gfx-passthrough.patch
./xen-load-vbios-file.patch
02:00.0 - Primary GFX (Dom0) Console: NVidia Geforce GTX260
03:00.0 - Secondary GFX (DomU): NVidia Geforce 9500GT
Qemu:
Warning: attempted read from physical address 0xe0000000 in xen platform mmio
space
And
pt_pci_write_config: Warning: Guest attempt to set address to unused Base
Address Register. [00:04.0][Offset:30h][Length:4]
Hope this helps,
Tim
From: Han, Weidong [mailto:weidong.han@intel.com]
Sent: 31 August 2009 09:47
To: 'enming.teo@asiasoftsea.net'; Tim Moore
Cc: 'xen-devel@lists.xensource.com'
Subject: RE: [Xen-devel] graphics passthrough with VT-d
Teo,
I attached some experimental patches for you to try to sthorugh Geforce 8400 GS.
Based on my patches posted last Friday, pls follow below instructions:
1. apply xen-load-vbios-file.patch to xen-unstable.hg
this patch supports to load vga bios from a file.
2. apply xen-vBAR-pBAR.patch to xen-unstable.hg
this patch is used to 1:1 map between vBAR and pBAR
3. apply qemu-change-for-vBAR-pBAR.patch to ioemu-remote (qemu tree).
this patch is used to 1:1 map between vBAR and pBAR on qemu side
4. apply qemu-claim-cycle-for-secondary-gfx-passthrough.patch
it's needed if you want to assign the secondary gfx to guest.
5. cd xen-unstable.hg
6. make clean
7. copy the vga bios file to
xen-unstabl.hg/tools/firmware/vgabios/vgabios-pt.bin
8. make; make install
9. reboot the system. or xend restart. then passthrough gfx to guest ...
Regards,
Weidong
________________________________
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Mr. Teo En Ming
(Zhang Enming)
Sent: 2009年8月29日 22:13
To: timothy.moore@expidas.net
Cc: xen-devel@lists.xensource.com
Subject: Re: [Xen-devel] graphics passthrough with VT-d
Hi Timothy,
Yes, I renamed the firmware file of nVidia Geforce 8400 GS to vgabios-pt.bin and
placed it in the source directory tools/firmware/vgabios.
Weidong had said Intel has the 1:1 mapping patches. Let's hope he will
release the patch soon to do pBAR:vBAR.
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Company Website: http://www.asiasoft.sg/
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 09:29 PM, Tim Moore wrote:
Teo,
Did you rename your Nvidia BIOS and copy it into the hvmloader source tree as
required ?
It should get compiled into roms.h in the hvmloader folder - I made sure it was
there as the xen buildroot seems to delete it randomly ...
I think we are now up against the Base Address Register issue where the Nvidia
driver is expecting to see the card at the Physical BAR Addresses and in the
DomU these are re-mapped to different address space ... this is a problem with
the Nvidia binary driver and therefore a workaround in xen is maybe needed.
That said, I'm not sure if the Nvidia BIOS likes to be re-executed and may
also be an issue ...
Tim
From: Mr. Teo En Ming (Zhang Enming) [mailto:enming.teo@asiasoftsea.net]
Sent: 29 August 2009 14:21
To: enming.teo@asiasoftsea.net<mailto:enming.teo@asiasoftsea.net>
Cc: Tim Moore;
xen-devel@lists.xensource.com<mailto:xen-devel@lists.xensource.com>
Subject: Re: [Xen-devel] graphics passthrough with VT-d
Dear All,
I have applied the following patches to xen 3.5-unstable
1) intel-gfx-passthru-patch01.patch
2) intel-gfx-passthru-patch02.patch
3) intel-gfx-passthru-patch03.patch
4) enming-patch04.patch
and compiled xen 3.5-unstable successfully (both hypervisor and tools).
i rebooted into this newly compiled Xen hypervisor which supports loading vga
bios from firmware file of nVidia Geforce 8400 GS PCI Express x16.
After dom0 has booted up, I executed the following script to hide nVidia Geforce
8400 GS from dom0.
[enming@fedora11-x86-64-host scripts]$ cat bind-devices-pci-stub.sh
#!/bin/sh
echo "10de 06e4" > /sys/bus/pci/drivers/pci-stub/new_id
echo "0000:01:00.0" >
/sys/bus/pci/devices/0000:01:00.0/driver/unbind
echo "0000:01:00.0" > /sys/bus/pci/drivers/pci-stub/bind
I also assigned the nVidia Geforce 8400 GS to my Windows XP Home HVM domU.
pci = [ '01:00.0' ]
I also specified gfx_passthru=2.
Do note that I booted up with onboard Intel GMA4500 as the primary video
adapter. Hence dom 0 has onboard graphics and Windows XP HVM domU has nvidia
graphics.
Then I started Windows XP Home HVM DomU.
Very soon, my Dom 0's display was garbaged and X server on Dom 0 totally
froze and became unresponsive. I cannot switch to any ttys.
However, I was still able to vnc into my Windows XP Home HVM Dom U. I had
earlier installed a VNC server into my Windows XP guest. After remoting in to my
Windows XP DomU through vnc, I found that NVIDIA Geforce 8400 GS cannot be
initialized and no resources are available for this graphics card.
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Company Website: http://www.asiasoft.sg/
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 08:25 PM, Mr. Teo En Ming (Zhang Enming) wrote:
Hi All,
I have solved the problem encountered below when building tools for xen
3.5-unstable. The compile problem exists because I downloaded and compiled the
latest version of Intel ACPI Component Architecture compiler version 20090730.
And I used this latest compiler during "make tools" for xen-unstable.
In original xen-unstable source codes cloned from xensoure mercurial repository,
the header files ssdt_pm.h and ssdt_tpm.h in source directory
tools/firmware/hvmloader/acpi/ are generated by
/*
*
* Intel ACPI Component Architecture
* ASL Optimizing Compiler version 20061109 [May 18 2007]
* Copyright (C) 2000 - 2006 Intel Corporation
* Supports ACPI Specification Revision 3.0a
*
* Compilation of "ssdt_pm.asl" - Sun Oct 12 23:57:51 2008
*
* C source code output
*
*/
In original ssdt_pm.h, it has "unsigned char AmlCode_PM[] =".
In original ssdt_tpm.h, it has "unsigned char AmlCode_TPM[] =".
Hence there was no problem with "make tools".
But, I downloaded, compiled and used
/*
*
* Intel ACPI Component Architecture
* ASL Optimizing Compiler version 20090730 [Aug 29 2009]
* Copyright (C) 2000 - 2009 Intel Corporation
* Supports ACPI Specification Revision 4.0
*
* Compilation of "ssdt_pm.asl" - Sat Aug 29 18:55:40 2009
*
* C source code output
*
*/
So the *new* ssdt_pm.h contains:
/*
*
* Intel ACPI Component Architecture
* ASL Optimizing Compiler version 20090730 [Aug 29 2009]
* Copyright (C) 2000 - 2009 Intel Corporation
* Supports ACPI Specification Revision 4.0
*
* Compilation of "ssdt_pm.asl" - Sat Aug 29 18:55:40 2009
*
* C source code output
*
*/
unsigned char AmlCode[] {
0x53,0x53,0x44,0x54,0xD6,0x05,0x00,0x00, /* 00000000
"SSDT...." */
0x02,0xB9,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008
"..Xen..." */
0x48,0x56,0x4D,0x00,0x00,0x00,0x00,0x00, /* 00000010
"HVM....." */
0x00,0x00,0x00,0x00,0x49,0x4E,0x54,0x4C, /* 00000018
"....INTL" */
0x30,0x07,0x09,0x20,0x10,0x41,0x5B,0x5C, /* 00000020 "0..
.A[\" */
0x5F,0x53,0x42,0x5F,0x5B,0x80,0x44,0x42, /* 00000028
"_SB_[.DB" */
0x47,0x41,0x01,0x0B,0x40,0xB0,0x01,0x5B, /* 00000030
"GA..@..["<mailto:GA..@..%5B> */
0x81,0x0B,0x44,0x42,0x47,0x41,0x01,0x44, /* 00000038
"..DBGA.D" */
0x42,0x47,0x31,0x08,0x5B,0x80,0x44,0x42, /* 00000040
"BG1.[.DB" */
0x47,0x42,0x01,0x0B,0x44,0xB0,0x01,0x5B, /* 00000048
"GB..D..[" */
0x81,0x0B,0x44,0x42,0x47,0x42,0x01,0x44, /* 00000050
"..DBGB.D" */
0x42,0x47,0x32,0x08,0x5B,0x80,0x44,0x42, /* 00000058
"BG2.[.DB" */
0x47,0x43,0x01,0x0B,0x46,0xB0,0x01,0x5B, /* 00000060
"GC..F..[" */
0x81,0x0B,0x44,0x42,0x47,0x43,0x01,0x44, /* 00000068
"..DBGC.D" */
0x42,0x47,0x33,0x08,0x5B,0x80,0x44,0x42, /* 00000070
"BG3.[.DB" */
0x47,0x44,0x01,0x0B,0x48,0xB0,0x01,0x5B, /* 00000078
"GD..H..[" */
0x81,0x0B,0x44,0x42,0x47,0x44,0x01,0x44, /* 00000080
"..DBGD.D" */
0x42,0x47,0x34,0x08,0x5B,0x80,0x50,0x52, /* 00000088
"BG4.[.PR" */
0x54,0x31,0x01,0x0A,0xB2,0x0A,0x02,0x5B, /* 00000090
"T1.....[" */
0x81,0x10,0x50,0x52,0x54,0x31,0x01,0x50, /* 00000098
"..PRT1.P" */
0x42,0x32,0x5F,0x08,0x50,0x42,0x32,0x41, /* 000000A0
"B2_.PB2A" */
0x08,0x5B,0x80,0x50,0x52,0x54,0x32,0x01, /* 000000A8
".[.PRT2." */
0x0A,0x86,0x01,0x5B,0x81,0x0B,0x50,0x52, /* 000000B0
"...[..PR" */
0x54,0x32,0x01,0x50,0x38,0x36,0x5F,0x08, /* 000000B8
"T2.P86_." */
0x5B,0x80,0x50,0x52,0x54,0x33,0x01,0x0A, /* 000000C0
"[.PRT3.." */
0x88,0x01,0x5B,0x81,0x0B,0x50,0x52,0x54, /* 000000C8
"..[..PRT" */
0x33,0x01,0x50,0x38,0x38,0x5F,0x08,0x5B, /* 000000D0
"3.P88_.[" */
0x01,0x53,0x59,0x4E,0x43,0x01,0x08,0x42, /* 000000D8
".SYNC..B" */
0x55,0x46,0x30,0x11,0x04,0x0B,0x00,0x01, /* 000000E0
"UF0....." */
0x08,0x42,0x55,0x46,0x31,0x11,0x03,0x0A, /* 000000E8
".BUF1..." */
0x08,0x8B,0x42,0x55,0x46,0x31,0x00,0x42, /* 000000F0
"..BUF1.B" */
0x55,0x46,0x41,0x8B,0x42,0x55,0x46,0x31, /* 000000F8
"UFA.BUF1" */
0x0A,0x04,0x42,0x55,0x46,0x42,0x14,0x14, /* 00000100
"..BUFB.." */
And the *new* ssdt_tpm.h contains:
/*
*
* Intel ACPI Component Architecture
* ASL Optimizing Compiler version 20090730 [Aug 29 2009]
* Copyright (C) 2000 - 2009 Intel Corporation
* Supports ACPI Specification Revision 4.0
*
* Compilation of "ssdt_tpm.asl" - Sat Aug 29 18:55:40 2009
*
* C source code output
*
*/
unsigned char AmlCode[] {
0x53,0x53,0x44,0x54,0x4C,0x00,0x00,0x00, /* 00000000
"SSDTL..." */
0x02,0x2A,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008
".*Xen..." */
0x48,0x56,0x4D,0x00,0x00,0x00,0x00,0x00, /* 00000010
"HVM....." */
0x00,0x00,0x00,0x00,0x49,0x4E,0x54,0x4C, /* 00000018
"....INTL" */
0x30,0x07,0x09,0x20,0x5B,0x82,0x26,0x54, /* 00000020 "0..
[.&T" */
0x50,0x4D,0x5F,0x08,0x5F,0x48,0x49,0x44, /* 00000028
"PM_._HID" */
0x0C,0x41,0xD0,0x0C,0x31,0x08,0x5F,0x43, /* 00000030
".A..1._C" */
0x52,0x53,0x11,0x11,0x0A,0x0E,0x86,0x09, /* 00000038
"RS......" */
0x00,0x01,0x00,0x00,0xD4,0xFE,0x00,0x50, /* 00000040
".......P" */
0x00,0x00,0x79,0x00,
};
which are both wrong.
In ssdt_pm.h, I have to change "unsigned char AmlCode[]" to
"unsigned char AmlCode_PM[]".
In ssdt_tpm.h, I have to change "unsigned char AmlCode[]" to
"unsigned char AmlCode_TPM[]".
Then "make tools" is able to complete successfully.
I have created a patch for anybody who may be using the *latest* version of
Intel ACPI CA compiler version 20090730 and attached it here.
Patch file filename enming-patch04.patch:
<CODE>
Patch created by Teo En Ming (Zhang Enming) on 29 August 2009 Saturday at 8:00
P.M. Singapore Time
Email #1: enming.teo@asiasoftsea.net<mailto:enming.teo@asiasoftsea.net>
Email #2:
space.time.universe@gmail.com<mailto:space.time.universe@gmail.com>
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Mobile Phone: +65-9648-9798
--- ssdt_pm.h 2009-08-29 19:54:52.653088000 +0800
+++ ssdt_pm.h 2009-08-29 19:56:51.813088550 +0800
@@ -10,7 +10,7 @@
* C source code output
*
*/
-unsigned char AmlCode[] +unsigned char AmlCode_PM[] {
0x53,0x53,0x44,0x54,0xD6,0x05,0x00,0x00, /* 00000000
"SSDT...." */
0x02,0xB9,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008
"..Xen..." */
--- ssdt_tpm.h 2009-08-29 19:55:44.578738954 +0800
+++ ssdt_tpm.h 2009-08-29 19:57:27.896638884 +0800
@@ -10,7 +10,7 @@
* C source code output
*
*/
-unsigned char AmlCode[] +unsigned char AmlCode_TPM[] {
0x53,0x53,0x44,0x54,0x4C,0x00,0x00,0x00, /* 00000000
"SSDTL..." */
0x02,0x2A,0x58,0x65,0x6E,0x00,0x00,0x00, /* 00000008
".*Xen..." */
</CODE>
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Company Website: http://www.asiasoft.sg/
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 07:03 PM, Mr. Teo En Ming (Zhang Enming) wrote:
Hi,
I cloned http://xenbits.xensource.com/xen-unstable.hg again today. I tried
applying the three Intel gfx passthrough patches to xen-unstable. When I
"make tools", I get the same error again:
make[7]: Entering directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader'
make -C acpi all
get-path: will use #!/usr/bin/python2.6 for python programs
make[8]: Entering directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'
make iasl
get-path: will use #!/usr/bin/python2.6 for python programs
make[9]: Entering directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'
make[9]: `/usr/local/bin/iasl' is up to date.
make[9]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'
iasl -tc ssdt_tpm.asl
Intel ACPI Component Architecture
ASL Optimizing Compiler version 20090730 [Aug 29 2009]
Copyright (C) 2000 - 2009 Intel Corporation
Supports ACPI Specification Revision 4.0
ASL Input: ssdt_tpm.asl - 31 lines, 1111 bytes, 3 keywords
AML Output: SSDT_TPM.aml - 76 bytes, 3 named objects, 0 executable opcodes
Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 0 Optimizations
mv ssdt_tpm.hex ssdt_tpm.h
rm -f *.aml
make iasl
get-path: will use #!/usr/bin/python2.6 for python programs
make[9]: Entering directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'
make[9]: `/usr/local/bin/iasl' is up to date.
make[9]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'
iasl -tc ssdt_pm.asl
Intel ACPI Component Architecture
ASL Optimizing Compiler version 20090730 [Aug 29 2009]
Copyright (C) 2000 - 2009 Intel Corporation
Supports ACPI Specification Revision 4.0
ASL Input: ssdt_pm.asl - 425 lines, 12754 bytes, 192 keywords
AML Output: SSDT_PM.aml - 1494 bytes, 64 named objects, 128 executable opcodes
Compilation complete. 0 Errors, 0 Warnings, 0 Remarks, 31 Optimizations
mv ssdt_pm.hex ssdt_pm.h
rm -f *.aml
gcc -O1 -fno-omit-frame-pointer -fno-optimize-sibling-calls -m32 -march=i686
-g -fno-strict-aliasing -std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value
-Wdeclaration-after-statement -D__XEN_TOOLS__ -MMD -MF .build.o.d
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -mno-tls-direct-seg-refs -Werror
-fno-stack-protector -fno-builtin -msoft-float -I. -I..
-I../../../../tools/include -c -o build.o build.c
In file included from build.c:21:
ssdt_pm.h:13: error: redefinition of ‘AmlCode’
ssdt_tpm.h:13: note: previous definition of ‘AmlCode’ was here
build.c: In function ‘construct_secondary_tables’:
build.c:184: error: ‘AmlCode_PM’ undeclared (first use in this function)
build.c:184: error: (Each undeclared identifier is reported only once
build.c:184: error: for each function it appears in.)
build.c:194: error: ‘AmlCode_TPM’ undeclared (first use in this function)
make[8]: *** [build.o] Error 1
make[8]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader/acpi'
make[7]: *** [subdir-all-acpi] Error 2
make[7]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader'
make[6]: *** [subdirs-all] Error 2
make[6]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware/hvmloader'
make[5]: *** [subdir-all-hvmloader] Error 2
make[5]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware'
make[4]: *** [subdirs-all] Error 2
make[4]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware'
make[3]: *** [all] Error 2
make[3]: Leaving directory
`/usr/src/xen-unstable-new.hg-vgapt/tools/firmware'
make[2]: *** [subdir-install-firmware] Error 2
make[2]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/usr/src/xen-unstable-new.hg-vgapt/tools'
make: *** [install-tools] Error 2
Any ideas about this Advanced Configuration and Power Interface code?
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Company Website: http://www.asiasoft.sg/
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 02:58 PM, Mr. Teo En Ming (Zhang Enming) wrote:
Hi
Anybody available today? I know it's Saturday. :-)
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Company Website: http://www.asiasoft.sg/
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 11:48 AM, Mr. Teo En Ming (Zhang Enming) wrote:
Dear All,
After applying Intel VGA passthrough patches 1, 2 and 3, I have no problems with
"make xen", and "make install-xen". However, I have errors
with "make tools".
Here is the error output:
msoft-float -I. -I.. -I../../../../tools/include -c -o build.o build.c
build.c: In function ‘construct_secondary_tables’:
build.c:194: error: ‘AmlCode_TPM’ undeclared (first use in this function)
build.c:194: error: (Each undeclared identifier is reported only once
build.c:194: error: for each function it appears in.)
make[8]: *** [build.o] Error 1
make[8]: Leaving directory
`/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader/acpi'
make[7]: *** [subdir-all-acpi] Error 2
make[7]: Leaving directory
`/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader'
make[6]: *** [subdirs-all] Error 2
make[6]: Leaving directory
`/usr/src/xen-unstable.hg-vgapt/tools/firmware/hvmloader'
make[5]: *** [subdir-all-hvmloader] Error 2
make[5]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'
make[4]: *** [subdirs-all] Error 2
make[4]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools/firmware'
make[2]: *** [subdir-install-firmware] Error 2
make[2]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools'
make[1]: *** [subdirs-install] Error 2
make[1]: Leaving directory `/usr/src/xen-unstable.hg-vgapt/tools'
make: *** [install-tools] Error 2
There is an undeclared identifier in tools/firmware/hvmloader/acpi/build.c
source code. Could you guys help me resolve this issue?
I had no problems compiling xen 3.5-unstable before applying the Intel vga
passthrough patches and before installing the Intel ACPI Component Architecture
compiler.
I have also attached Intel graphics passthrough patches 1, 2 and 3 for your
convenience here.
Thank you very much.
Hope I can get this working during the weekends.
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Company Website: http://www.asiasoft.sg/
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 10:17 AM, Mr. Teo En Ming (Zhang Enming) wrote:
Hi Tim,
I thought it should be gfx_passthru=2 in domU config?
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 06:42 AM, Tim Moore wrote:
Teo,
I have also performed the same exercise as yourself and I now have successfully
compiled all 3x patches into Xen, Qemu and the BIOS File Loading in the
hvmloader, this all compiles find on my system. Suggest you do a "make
clean" on the tools and start again !
After booting with the patched xen-unstable and adding the gfx-passthru=1
parameter to my HVM DomU, as I suspected - it still doesn't work.
I have both a 9500GT and GTX260(primary) in my Intel DX58SO machine, tried
passing through either device and my primary display locks up ! (included hiding
with pci-stub)
I verified that the DomU was functional beforehand, as It also booted
successfully without the gfx-passthru parameter (and a vncviewer/cirrus display)
Unfortunately, I can't debug further as my Primary display corrupts as soon
as the DomU starts. I did notice that in "xm debug" the "Loading
Gfx BIOS File.." message was displayed and the DomU did continue to
initialise the BIOS tables and such before finally locking. I then (blindly)
typed on a corrupt Dom0 console and managed to start kdm and login, so the Dom0
was not completely trashed. But then after a few minutes, the machine totally
froze and had to hit the reset switch.
I`m no specialist but this looks like the VGA BIOS Re-initialisation is playing
havoc with the DomU and possibly the Dom0 graphics. I notice that both are also
using IRQ11 which could play a major part. Furthermore, there was a lot of debug
output in the qemu and xend.log indicating Base Address Register invalid access
and therefore it seems there may be a second obstacle.
Hope you have a better success than me !
For now, I would try re-compiling a fresh xen-unstable with carefully applied
patches .. oh! and don't forget to enable the pci-stub driver for Dom0
(it's not selected by default)
Tim
From:
xen-devel-bounces@lists.xensource.com<mailto:xen-devel-bounces@lists.xensource.com>
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Mr. Teo En Ming
(Zhang Enming)
Sent: 28 August 2009 21:14
To: enming.teo@asiasoftsea.net<mailto:enming.teo@asiasoftsea.net>
Cc: xen-devel@lists.xensource.com<mailto:xen-devel@lists.xensource.com>;
'Lin, Ben Y'; 'Kay, Allen M'; 'Jean Guyader';
Keir.Fraser@eu.citrix.com<mailto:Keir.Fraser@eu.citrix.com>;
weidong.han@intel.com<mailto:weidong.han@intel.com>;
bengheng@eecs.umich.edu<mailto:bengheng@eecs.umich.edu>
Subject: Re: [Xen-devel] [PATCH 2/2] graphics passthrough with VT-d
After applying the 1st and 2nd patch to xen-unstable successfully, I examined
the source codes Makefile and hvmloader.c in tools/firmware/hvmloader, compared
them to Weidong's 3rd patch and I generated my own 3rd patch. Then I used my
own generated 3rd patch to apply patching for loading vga bios from firmware
file.
Here is my own generated 3rd patch instead of using Weidong's 3rd patch:
--- Makefile 2009-08-29 03:24:52.413083774 +0800
+++ Makefile 2009-08-29 03:29:12.763299633 +0800
@@ -50,6 +50,7 @@
roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \
../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h
sh ./mkhex rombios ../rombios/BIOS-bochs-latest > roms.h
+ sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin >> roms.h
sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin >>
roms.h
sh ./mkhex vgabios_cirrusvga \
../vgabios/VGABIOS-lgpl-latest.cirrus.bin >> roms.h
--- hvmloader.c 2009-08-29 03:26:06.911085797 +0800
+++ hvmloader.c 2009-08-29 03:31:43.172084995 +0800
@@ -688,9 +688,9 @@
vgabios_sz = round_option_rom(sizeof(vgabios_stdvga));
break;
case VGA_pt:
- printf("Loading VGABIOS of passthroughed gfx ...\n");
- vgabios_sz
- round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512);
+ printf("Loading Gfx Video BIOS from file ...\n");
+ memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt,
sizeof(vgabios_pt));
+ vgabios_sz = round_option_rom(sizeof(vgabios_pt));
break;
default:
printf("No emulated VGA adaptor ...\n");
I can "make xen" successfully but when I proceeded to "make
tools", errors were encountered.
Please see attached error output. How can I solve this problem?
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/29/2009 12:59 AM, Mr. Teo En Ming (Zhang Enming) wrote:
OK I believe the 3rd patch is not incomplete but there's a white space issue
when I copied the code from the mailing list into my vi.
See http://www.htdig.org/mail/2000/11/0167.html
When I used the -l flag to patch using the 3rd patch, the number of errors was
reduced.
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -l -p1 <
intel-gfx-passthru-patch-3.patch
patching file tools/firmware/hvmloader/Makefile
patching file tools/firmware/hvmloader/hvmloader.c
Hunk #1 FAILED at 688.
1 out of 1 hunk FAILED -- saving rejects to file
tools/firmware/hvmloader/hvmloader.c.rej
Now patching tools/firmware/hvmloader/Makefile is successful but patching
tools/firmware/hvmloader/hvmloader.c still failed.
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
On 08/28/2009 11:55 PM, Mr. Teo En Ming (Zhang Enming) wrote:
Dear Weidong,
A big big thanks for the vga passthrough patches for xen 3.5-unstable!!! These
are eagerly anticipated patches. As I did not study computer science and
computer architecture, I won't be able to write those patches you guys at
Intel wrote.
I applied the following patches
xen-gfx-passthrough.patch<http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin>
and
qemu-gfx-passthrough.patch<http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin>
to xen 3.5-unstable without issues.
Then I tried to apply the 3rd patch you provided at
http://lists.xensource.com/archives/html/xen-devel/2009-08/msg01047.html
I saved the following code
<CODE>
diff -r 494be76c1ad9 tools/firmware/hvmloader/Makefile
--- a/tools/firmware/hvmloader/Makefile Thu Aug 27 16:54:33 2009 +0800
+++ b/tools/firmware/hvmloader/Makefile Thu Aug 27 17:22:01 2009 +0800
@@ -50,6 +50,7 @@ roms.h: ../rombios/BIOS-bochs-latest ../
roms.h: ../rombios/BIOS-bochs-latest ../vgabios/VGABIOS-lgpl-latest.bin \
../vgabios/VGABIOS-lgpl-latest.cirrus.bin ../etherboot/eb-roms.h
sh ./mkhex rombios ../rombios/BIOS-bochs-latest > roms.h
+ sh ./mkhex vgabios_pt ../vgabios/vgabios-pt.bin >> roms.h
sh ./mkhex vgabios_stdvga ../vgabios/VGABIOS-lgpl-latest.bin >> roms.h
sh ./mkhex vgabios_cirrusvga \
../vgabios/VGABIOS-lgpl-latest.cirrus.bin >> roms.h
diff -r 494be76c1ad9 tools/firmware/hvmloader/hvmloader.c
--- a/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 16:54:33 2009 +0800
+++ b/tools/firmware/hvmloader/hvmloader.c Thu Aug 27 17:23:00 2009 +0800
@@ -688,9 +688,9 @@ int main(void)
vgabios_sz = round_option_rom(sizeof(vgabios_stdvga));
break;
case VGA_pt:
- printf("Loading Gfx Video BIOS from 0xC0000 ...\n");
- vgabios_sz
- round_option_rom((*(uint8_t *)(VGABIOS_PHYSICAL_ADDRESS+2)) * 512);
+ printf("Loading Gfx Video BIOS from file ...\n");
+ memcpy((void *)VGABIOS_PHYSICAL_ADDRESS, vgabios_pt,
sizeof(vgabios_pt));
+ vgabios_sz = round_option_rom(sizeof(vgabios_pt));
break;
default:
printf("No emulated VGA adaptor ...\n");
</CODE>
as intel-gfx-passthru-patch-3.patch and then I tried to apply the patch to xen
3.5-unstable. I got errors. I think it's because the 3rd patch you provided
is incomplete.
Here's my patching process:
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name vgabios
./tools/firmware/vgabios
./.hg/store/data/tools/firmware/vgabios
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cp ~enming/vgabios-pt.bin
tools/firmware/vgabios/
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ls tools/firmware/vgabios/
biossums.c clext.c Makefile TODO vbe.h
vgabios.h vgatables.h
BUGS COPYING Notes vbe.c vbetables-gen.c
vgabios-pt.bin
ChangeLog dataseghack README vbe_display_api.txt vgabios.c
vgafonts.h
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# pwd
/usr/src/xen-unstable.hg-vgapt
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wget
http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin
--2009-08-28 23:18:21--
http://lists.xensource.com/archives/html/xen-devel/2009-08/bincPiiAf0QWg.bin
Resolving lists.xensource.com... 70.42.241.110
Connecting to lists.xensource.com|70.42.241.110|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 12565 (12K) [application/octet-stream]
Saving to: `bincPiiAf0QWg.bin'
100%[======================================================================>]
12,565 30.7K/s in 0.4s
2009-08-28 23:18:22 (30.7 KB/s) - `bincPiiAf0QWg.bin' saved [12565/12565]
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv bincPiiAf0QWg.bin
xen-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi xen-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch <
xen-gfx-passthrough.patch
can't find file to patch at input line 4
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff -r 5d7e7a250267 tools/firmware/hvmloader/config.h
|--- a/tools/firmware/hvmloader/config.h Wed Aug 26 18:28:44 2009 +0800
|+++ b/tools/firmware/hvmloader/config.h Thu Aug 27 16:54:24 2009 +0800
--------------------------
File to patch: ^C
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# ex xen-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1 <
xen-gfx-passthrough.patch
patching file tools/firmware/hvmloader/config.h
patching file tools/firmware/hvmloader/hvmloader.c
patching file tools/libxc/ia64/xc_ia64_hvm_build.c
patching file tools/libxc/xc_hvm_build.c
patching file tools/libxc/xc_linux.c
patching file tools/libxc/xenctrl.h
patching file tools/libxc/xenguest.h
patching file tools/python/xen/lowlevel/xc/xc.c
patching file tools/python/xen/xend/XendConfig.py
Hunk #1 succeeded at 174 (offset -1 lines).
patching file tools/python/xen/xend/image.py
Hunk #1 succeeded at 780 (offset -6 lines).
Hunk #3 succeeded at 895 (offset -6 lines).
patching file tools/python/xen/xm/create.py
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# wget
http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin
--2009-08-28 23:21:35--
http://lists.xensource.com/archives/html/xen-devel/2009-08/binglLqkeq4Rj.bin
Resolving lists.xensource.com... 70.42.241.110
Connecting to lists.xensource.com|70.42.241.110|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9841 (9.6K) [application/octet-stream]
Saving to: `binglLqkeq4Rj.bin'
100%[======================================================================>]
9,841 24.3K/s in 0.4s
2009-08-28 23:21:36 (24.3 KB/s) - `binglLqkeq4Rj.bin' saved [9841/9841]
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv binglLqkeq4Rj.bin
qemu-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi qemu-gfx-passthrough.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# find . -name hw
./tools/ioemu-remote/hw
./.hg/store/data/tools/ioemu/hw
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# mv qemu-gfx-passthrough.patch
tools/ioemu-remote/
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# cd tools/ioemu-remote/
[root@fedora11-x86-64-host ioemu-remote]# patch -p1 < qemu-
qemu-aio.h qemu-img.c qemu-sockets.c
qemu-binfmt-conf.sh qemu-img.texi qemu-tech.texi
qemu-char.c qemu-lock.h qemu-timer.h
qemu-char.h qemu-log.h qemu-tool.c
qemu-common.h qemu-malloc.c qemu-xen.h
qemu-doc.texi qemu-nbd.c
qemu-gfx-passthrough.patch qemu-nbd.texi
[root@fedora11-x86-64-host ioemu-remote]# patch -p1 <
qemu-gfx-passthrough.patch
patching file hw/pass-through.c
patching file hw/pass-through.h
patching file hw/pc.c
patching file vl.c
[root@fedora11-x86-64-host ioemu-remote]# cd ..
[root@fedora11-x86-64-host tools]# cd ..
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi
intel-gfx-passthru-patch-3.patch
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# patch -p1 <
intel-gfx-passthru-patch-3.patch
patching file tools/firmware/hvmloader/Makefile
Hunk #1 FAILED at 50.
1 out of 1 hunk FAILED -- saving rejects to file
tools/firmware/hvmloader/Makefile.rej
patching file tools/firmware/hvmloader/hvmloader.c
patch: **** malformed patch at line 24: sizeof(vgabios_pt));
[root@fedora11-x86-64-host xen-unstable.hg-vgapt]# vi
intel-gfx-passthru-patch-3.patch
For everybody's convenience, I have attached
intel-gfx-passthru-patch-3.patch and the firmware for my nVidia GeForce 8400 GS
PCI Express x16 graphics card in this email.
Please help me complete intel-gfx-passthru-patch-3.patch as I really need it.
Thank you very much!!!
--
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com<mailto:teoenming@hotmail.com>
Alma Maters: Singapore Polytechnic, National University of Singapore
This patch supports basic gfx passthrough on QEMU:
- disable emulated VGA adpater if there is passthroughed gfx
- register/unregister legacy VGA I/O ports and MMIOs for passthroughed gfx
Signed-off-by: Ben Lin
<ben.y.lin@intel.com><mailto:ben.y.lin@intel.com>
Signed-off-by: Weidong Han
<weidong.han@intel.com><mailto:weidong.han@intel.com>
No virus found in this incoming message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 8.5.409 / Virus Database: 270.13.69/2328 - Release Date: 08/27/09
18:02:00
No virus found in this outgoing message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 8.5.409 / Virus Database: 270.13.71/2330 - Release Date: 08/27/09
18:02:00
________________________________
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com<mailto:Xen-devel@lists.xensource.com>
http://lists.xensource.com/xen-devel
________________________________
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com<mailto:Xen-devel@lists.xensource.com>
http://lists.xensource.com/xen-devel
________________________________
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com<mailto: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
Christian Tramnitz wrote:> Actually yes, that helped a lot. And finally some progress on VGA > passthrough: > > I have a X58 board with two ATI PCIe cards (RV770 and RV370). > Currently the RV770 is the primary card that is used during bootup > and also with Xorg in dom0 (radeonhd-only no fglrx). > With the latest patches in this thread and a recent Xenclient kernel > (haven''t tested 2.6.18 in a while) I was able to passthrough the RV370 > to a HVM domu, seeing the BIOS boot and the OS loading in text mode > and then going into graphics mode. > Windows (both pre-installed images I had and new installation attempts > from CD) isn''t working yet, telling me I don''t have a fully ACPI > compliant BIOS and quiting with a BSOD and STOP 0x5A, but I guess > thats a minor thing because I''ve got a stock Knoppix to boot and load > in gfx mode on the passthrough graphics card. > > I really haven''t expected that much progress since I haven''t heard > about any ATI tests at all for a while. Now I''m looking to get the > STOP 0x5A resolved and then passthrough additional devices (USB, > Sound, Network, Storage controller) and I''ll also try to swap the > RV370 and RV770 to get some 3D performance into the HVM domU. > > Observations so far: > - when creating the domU while I''m in text mode the dom0 stalls. It > doesn''t lock up completely but the terminal and keyboard are frozen. > When I create the domU while dom0 is running X everything is fine.When you passthrough secondary gfx to guest, it needs to claim the VGA cycle for assigned gfx to display guest booting progress. Then primary gfx doesn''t own the VGA cycle to display text mode. In your case, pls use X in dom0 or use VNC to access dom0.> - none of the HVM domU''s have picked up the USB bus I tried to > passthrough (with keyboard and mouse attached). Not sure if I just > passed through the wrong bus or something else is brokenFirstly, make sure you assign the correct USB controllers attached keyboard and mouse to guest. BTW, I found USB controller assignment doesn''t work well with pv-ops dom0> - after a domU is stopped it will still show the last image on the > passthrough gfx card (Knoppix desktop or Windows BSOD in my case)It seems that the gfx card is not reset (FLR).> - after a couple of restarts (xm destroy/ the hard way due to lack of > mouse/keyboard in domU) the secondary ATI gliteched and only showed a > gren screen, had to reboot to get it working again.I think it''s still related to gfx reset (FLR). Regards, Weidong> - I''ve tried Windows domUs with and without Viridian enabled, didn''t > make a difference in regards to the STOP > > > I''ll continue to work on that and keep you posted. Any hints regarding > the STOP 0x5A and Keyboard/Mouse passthrough would be much > appreciated. (I actually have two keyboards connected, one on legacy > PS/2 meant for dom0 and a USB keyboard and USB mouse that I''d like to > passthrough) > > > > Best regards, > Christian > > > Keir Fraser wrote: >> This is probably due to c/s 20137 and now fixed by c/s 20141. >> >> Thanks, >> Keir >> > > > _______________________________________________ > 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
Han, Weidong wrote:>> - when creating the domU while I''m in text mode the dom0 stalls. It >> doesn''t lock up completely but the terminal and keyboard are frozen. >> When I create the domU while dom0 is running X everything is fine. > > When you passthrough secondary gfx to guest, it needs to claim the VGA cycle for assigned gfx to display guest booting progress. Then primary gfx doesn''t own the VGA cycle to display text mode. In your case, pls use X in dom0 or use VNC to access dom0.Actually I can see the text-mode boot process in domU on the passthrough secondary gfx card, it''s just that the console stalls when running "xm create". This doesnt happen using an xterm, but I''m still able to see the text mode boot process (incl BOCHS Bios) on the secondary gfx card.> >> - none of the HVM domU''s have picked up the USB bus I tried to >> passthrough (with keyboard and mouse attached). Not sure if I just >> passed through the wrong bus or something else is broken > > Firstly, make sure you assign the correct USB controllers attached keyboard and mouse to guest. BTW, I found USB controller assignment doesn''t work well with pv-ops dom0I''m using a xenclient kernel, but will simply passthrough *all* USB busses today.> >> - after a domU is stopped it will still show the last image on the >> passthrough gfx card (Knoppix desktop or Windows BSOD in my case) > > It seems that the gfx card is not reset (FLR).I thought the xenclient kernel has XCI already implemented but then again this might be limited to certain devices (Intel IGD). It''s no big deal anyway, just wanted to report it. I''ll continue to work on this patch-set instead of the just posted v2 to be able to passthrough the secondary gfx card and use pBAR-vBAR 1:1 mapping. Thanks and best regards, Christian _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Christian Tramnitz wrote:> Han, Weidong wrote: >>> - when creating the domU while I''m in text mode the dom0 stalls. It >>> doesn''t lock up completely but the terminal and keyboard are frozen. >>> When I create the domU while dom0 is running X everything is fine. >> >> When you passthrough secondary gfx to guest, it needs to claim the >> VGA cycle for assigned gfx to display guest booting progress. Then >> primary gfx doesn''t own the VGA cycle to display text mode. In your >> case, pls use X in dom0 or use VNC to access dom0. > Actually I can see the text-mode boot process in domU on the > passthrough secondary gfx card, it''s just that the console stalls > when running "xm create". This doesnt happen using an xterm, but I''m > still able to see > the text mode boot process (incl BOCHS Bios) on the secondary gfx > card.Yes, I mean you can see text mode boot process on the secondary gfx card, because it will claim VGA cycle. But at the same time, the primary gfx cannot display in text mode.> >> >>> - none of the HVM domU''s have picked up the USB bus I tried to >>> passthrough (with keyboard and mouse attached). Not sure if I just >>> passed through the wrong bus or something else is broken >> >> Firstly, make sure you assign the correct USB controllers attached >> keyboard and mouse to guest. BTW, I found USB controller assignment >> doesn''t work well with pv-ops dom0 > > I''m using a xenclient kernel, but will simply passthrough *all* USB > busses today.Yes, this is an easy way. Regards, Weidong> >> >>> - after a domU is stopped it will still show the last image on the >>> passthrough gfx card (Knoppix desktop or Windows BSOD in my case) >> >> It seems that the gfx card is not reset (FLR). > > I thought the xenclient kernel has XCI already implemented but then > again this might be limited to certain devices (Intel IGD). > It''s no big deal anyway, just wanted to report it. > > I''ll continue to work on this patch-set instead of the just posted v2 > to > be able to passthrough the secondary gfx card and use pBAR-vBAR 1:1 > mapping. > > > Thanks and best regards, > Christian > > > _______________________________________________ > 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
FYI, apparently I passed through the wrong usb bus, now with all USB
controllers passed through I have keyboard and mouse in HVM domU.
Knoppix still boots on secondary gfx cards (and even uses Compiz Fusion
on 3D accelerated desktop), but I still can''t get Windows to boot.
The STOP code is actually A5 (and not 5A as reported earlier) and
indicates an ACPI error of the available PCI resources, MS KB says:
"STOP 0x000000A5"
(0x00000002, Parameter2, Parameter3, Parameter4):
This error is defined as ACPI root PCI resource failure. To discover
what current resources are being used by PCI devices, it must be able to
query the CRS descriptor in the ACPI namespace. This error occurs
because the BIOS lacks a pointer to the list, the list is empty, or
contains errors/conflicts.
I haven''t seen this before, so its most probably related to the
passthrough and not so trivial as I initially assumed.
If I had keyboard access early in the bootup process I could press F7 to
get the Standard-PC HAL (non-ACPI), but it seems the Bochs BIOS lacks
USB HID support, so I only have the keyboard available when the OS is
loading the drivers which is to late for Windows HAL selection...
Any ideas?
Thanks,
Christian
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Teo En Ming (Zhang Enming)
2009-Sep-02 08:48 UTC
RE: [Xen-devel] Re: graphics passthrough with VT-d
I also cannot get Window HVM Dom U to boot.
Regards,
Mr. Teo En Ming (Zhang Enming) Dip(Mechatronics Engineering)
BEng(Hons)(Mechanical Engineering)
Technical Support Engineer
Information Technology Department
Asiasoft Online Pte Ltd
Tampines Central 1 #04-01 Tampines Plaza
Singapore 529541
Republic of Singapore
Mobile: +65-9648-9798
MSN: teoenming@hotmail.com
-----Original Message-----
From: xen-devel-bounces@lists.xensource.com
[mailto:xen-devel-bounces@lists.xensource.com] On Behalf Of Christian
Tramnitz
Sent: Wednesday, September 02, 2009 4:39 PM
To: xen-devel@lists.xensource.com
Subject: [Xen-devel] Re: graphics passthrough with VT-d
FYI, apparently I passed through the wrong usb bus, now with all USB
controllers passed through I have keyboard and mouse in HVM domU.
Knoppix still boots on secondary gfx cards (and even uses Compiz Fusion
on 3D accelerated desktop), but I still can''t get Windows to boot.
The STOP code is actually A5 (and not 5A as reported earlier) and
indicates an ACPI error of the available PCI resources, MS KB says:
"STOP 0x000000A5"
(0x00000002, Parameter2, Parameter3, Parameter4):
This error is defined as ACPI root PCI resource failure. To discover
what current resources are being used by PCI devices, it must be able to
query the CRS descriptor in the ACPI namespace. This error occurs
because the BIOS lacks a pointer to the list, the list is empty, or
contains errors/conflicts.
I haven''t seen this before, so its most probably related to the
passthrough and not so trivial as I initially assumed.
If I had keyboard access early in the bootup process I could press F7 to
get the Standard-PC HAL (non-ACPI), but it seems the Bochs BIOS lacks
USB HID support, so I only have the keyboard available when the OS is
loading the drivers which is to late for Windows HAL selection...
Any ideas?
Thanks,
Christian
_______________________________________________
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 - www.avg.com
Version: 8.5.409 / Virus Database: 270.13.75/2340 - Release Date: 09/01/09
20:03:00
No virus found in this outgoing message.
Checked by AVG - www.avg.com
Version: 8.5.409 / Virus Database: 270.13.75/2340 - Release Date: 09/01/09
20:03:00
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
I didn''t meet this issue. I can passthrough gfx to WinXP guest. Did you try the same Windows guest without gfx passthrough patches? Regards, Weidong Christian Tramnitz wrote:> FYI, apparently I passed through the wrong usb bus, now with all USB > controllers passed through I have keyboard and mouse in HVM domU. > Knoppix still boots on secondary gfx cards (and even uses Compiz > Fusion on 3D accelerated desktop), but I still can''t get Windows to > boot. > > The STOP code is actually A5 (and not 5A as reported earlier) and > indicates an ACPI error of the available PCI resources, MS KB says: > > "STOP 0x000000A5" > (0x00000002, Parameter2, Parameter3, Parameter4): > This error is defined as ACPI root PCI resource failure. To discover > what current resources are being used by PCI devices, it must be able > to query the CRS descriptor in the ACPI namespace. This error occurs > because the BIOS lacks a pointer to the list, the list is empty, or > contains errors/conflicts. > > I haven''t seen this before, so its most probably related to the > passthrough and not so trivial as I initially assumed. > > If I had keyboard access early in the bootup process I could press F7 > to get the Standard-PC HAL (non-ACPI), but it seems the Bochs BIOS > lacks USB HID support, so I only have the keyboard available when the > OS is loading the drivers which is to late for Windows HAL > selection... > > > > Any ideas? > > > Thanks, > Christian > > > _______________________________________________ > 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
Yes without gfx_passthrough it was working (even the same domU with just
USB devices passed through).
I think it might be related to the modifications to the memory addresses
you mentioned in another post.
I''ll verify that, recompile and retest.
Best regards,
Christian
Han, Weidong wrote:> I didn''t meet this issue. I can passthrough gfx to WinXP guest.
>
> Did you try the same Windows guest without gfx passthrough patches?
>
> Regards,
> Weidong
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
It seems this was unrelated to the gfx_passthrough, I started with
"fresh" domU configs and also reinstalled them and now its working
WITH
gfx_passthrough and USB (the whole controller as pci device) passthrough.
I do have (all as pass-through):
- accelerated video (even survives hardware detection during Win7
installation)
- audio (onboard HDA, using digital output)
- USB (UHCI only, EHCI crashed Windows during HW detection)
running Windows 7 x64 (b7600).
I''ll now try to swap the primary and secondary gfx (both ATI) to get
some real 3D horse-power.
Best regards,
Christian
Christian Tramnitz wrote:> Yes without gfx_passthrough it was working (even the same domU with just
> USB devices passed through).
> I think it might be related to the modifications to the memory addresses
> you mentioned in another post.
> I''ll verify that, recompile and retest.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Reasonably Related Threads
- Unable to Configure Xen Dom 0 in Jeremy''s PVOPS Kernel
- Public Apology to Minister Mentor Lee Kuan Yew and Prime Minister Lee Hsien Loong, Singapore
- Xen patches merged to upstream Linux 2.6.36, plans for 2.6.37?
- Using Xen Virtualization Environment for Development and Testing of Supercomputing and High Performance Computing (HPC) Cluster MPICH2 MPI-2 Applications
- Using Xen Virtualization Environment for Development and Testing of Supercomputing and High Performance Computing (HPC) Cluster MPICH2 MPI-2 Applications