[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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@xxxxxxxxxxx
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@xxxxxxxxxxxx"<djmagee@xxxxxxxxxxxx>  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@xxxxxxxxxxxxxxxxxxx
[mailto:xen-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Christian
Tramnitz
Sent: Monday, August 31, 2009 12:48 PM
To: xen-devel@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel




_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.