You are not logged in.
ilya80 wrote:aw wrote:Did you also modify the VBIOS for the new device ID? If the VBIOS doesn't match the card seabios won't run it.
With VBIOS you mean the bios on the video card? No I haven't updated that. I`d rather keep the original bios b/c as far as I understand it manages clocks/fans in a way I want it to - as a GTX 680. Is there a way to force seabios to run GPU BIOS even though there is a mismatch?
You won't have VGA on bare metal without a modified VBIOS either, so our emulation is accurate The only way to force seabios to use the VBIOS would be to modify the code.
ila80 wrote:aw wrote:However, with a K2 you can avoid all the craziness of VGA and pass the card to the guest as a secondary display. Pre-boot and early guest boot will happen on the emulated VGA. When the Nvidia driver is loaded the emulated VGA is disabled and the assigned device will take over. Use one of the standard emulated VGA devices and drop x-vga=on from the assigned device in your guest config.
Thanks for advice! Ill try that.
Update: for some reason WIndows is not able to boot - BSOD with PAGE_FAULT_IN_NONPAGED_AREA code 0x00000050. Sometimes BSOD has different code 0x0000007E ( SYSTEM_THREAD_EXCEPTION_NOT_HANDLED )
I might look into seabios at see if it can be forced to load BIOS even though there is a mismatch.
IIRC the PAGE_FAULT_IN_NONPAGED_AREA is the manifestation of the -cpu host problem on Nvidia. Try -cpu qemu64 or one of the CPU specific types. Note that you can dump the VBIOS, modify it, then load it with romfile= to avoid flashing it back to hardware.
AW, thanks for your input, it is really appreciated!
I do boot Win7 on bare metal with my mainboard BIOS and I installed Quadro/Tesla/GRID drivers on it. Plays modern games as it did before However my next steps are download bios from the card, patch the device ID and the checksum, and then feed that to seabios. Re: -cpu options I`ve had problems with it before, played with it and ended up booting fine with -cpu host. I`ll give it a some tries for sure though.
Offline
hmm, i have problems passing through my Etron EJ168 USB 3 Controller.
i bind it to vfio-pci and pass it to the Windows 7 VM. There its recognised and i can install the (latest) driver by Etron. The driver seems to be intalled ok but there is no power on the ports.
I read someone (aw?) got a machine up and running with eJ168?
kernel 3.12 and still only qemu-kvm 1.60 (debian unstable).
Offline
hmm, i have problems passing through my Etron EJ168 USB 3 Controller.
i bind it to vfio-pci and pass it to the Windows 7 VM. There its recognised and i can install the (latest) driver by Etron. The driver seems to be intalled ok but there is no power on the ports.
I read someone (aw?) got a machine up and running with eJ168?
kernel 3.12 and still only qemu-kvm 1.60 (debian unstable).
$ lspci|grep Etron
03:00.0 USB controller: Etron Technology, Inc. EJ168 USB 3.0 Host Controller (rev 01)
04:00.0 USB controller: Etron Technology, Inc. EJ168 USB 3.0 Host Controller (rev 01)
Hi, the person with those controllers seems to be me although there might be more than one person with them
I managed to pass them to a Windows (7?) VM quite a while ago and they "worked" but etrons drivers and probably hardware were/are total garbage. The VM constantly threw BSODs at me, my mouse or kvm switch was lagging/randomly resetting when connected to one of the controllers and so on. This doesn't seem to be a problem with vfio though, since people without it are having problems too.
So yeah, this was probably not what you are looking for but my solution was to not use usb3 in the vm but usb2 controllers.
i'm sorry for my poor english wirting skills…
Offline
blitzschlag wrote:hmm, i have problems passing through my Etron EJ168 USB 3 Controller.
i bind it to vfio-pci and pass it to the Windows 7 VM. There its recognised and i can install the (latest) driver by Etron. The driver seems to be intalled ok but there is no power on the ports.
I read someone (aw?) got a machine up and running with eJ168?
kernel 3.12 and still only qemu-kvm 1.60 (debian unstable).
$ lspci|grep Etron 03:00.0 USB controller: Etron Technology, Inc. EJ168 USB 3.0 Host Controller (rev 01) 04:00.0 USB controller: Etron Technology, Inc. EJ168 USB 3.0 Host Controller (rev 01)
Hi, the person with those controllers seems to be me although there might be more than one person with them
I managed to pass them to a Windows (7?) VM quite a while ago and they "worked" but etrons drivers and probably hardware were/are total garbage. The VM constantly threw BSODs at me, my mouse or kvm switch was lagging/randomly resetting when connected to one of the controllers and so on. This doesn't seem to be a problem with vfio though, since people without it are having problems too.
So yeah, this was probably not what you are looking for but my solution was to not use usb3 in the vm but usb2 controllers.
ah, ok, thx for the Information.
My main Problem or concern is that just passing through the usb-hdd and emulating usb has really poor performance (7-9MB/s write). At least passing through one of the usb2 Controllers will give me better performance.
I was kinda hoping to be able to use the usb3 Controller for my usual video-editing (non-professional) stuff. As it is (with emulated usb) i have constant bufferings which freaks me out ^^
oh, btw, i use Synergy for sharing my Keyboard and Mouse. Works pretty solid even with gaming.
Offline
andy123 wrote:blitzschlag wrote:hmm, i have problems passing through my Etron EJ168 USB 3 Controller.
i bind it to vfio-pci and pass it to the Windows 7 VM. There its recognised and i can install the (latest) driver by Etron. The driver seems to be intalled ok but there is no power on the ports.
I read someone (aw?) got a machine up and running with eJ168?
kernel 3.12 and still only qemu-kvm 1.60 (debian unstable).
$ lspci|grep Etron 03:00.0 USB controller: Etron Technology, Inc. EJ168 USB 3.0 Host Controller (rev 01) 04:00.0 USB controller: Etron Technology, Inc. EJ168 USB 3.0 Host Controller (rev 01)
Hi, the person with those controllers seems to be me although there might be more than one person with them
I managed to pass them to a Windows (7?) VM quite a while ago and they "worked" but etrons drivers and probably hardware were/are total garbage. The VM constantly threw BSODs at me, my mouse or kvm switch was lagging/randomly resetting when connected to one of the controllers and so on. This doesn't seem to be a problem with vfio though, since people without it are having problems too.
So yeah, this was probably not what you are looking for but my solution was to not use usb3 in the vm but usb2 controllers.
ah, ok, thx for the Information.
My main Problem or concern is that just passing through the usb-hdd and emulating usb has really poor performance (7-9MB/s write). At least passing through one of the usb2 Controllers will give me better performance.
I was kinda hoping to be able to use the usb3 Controller for my usual video-editing (non-professional) stuff. As it is (with emulated usb) i have constant bufferings which freaks me out ^^oh, btw, i use Synergy for sharing my Keyboard and Mouse. Works pretty solid even with gaming.
Looks like qemu supports xhci emulation
xhci controller support
-----------------------There is also xhci host controller support available. It got a lot
less testing than ehci and there are a bunch of known limitations, so
ehci may work better for you. On the other hand the xhci hardware
design is much more virtualization-friendly, thus xhci emulation uses
less resources (especially cpu). If you want to give xhci a try
use this to add the host controller ...qemu -device nec-usb-xhci,id=xhci
... then use "bus=xhci.0" when assigning usb devices.
You might want to take a look at that
Offline
Looks like qemu supports xhci emulation
xhci controller support
-----------------------There is also xhci host controller support available. It got a lot
less testing than ehci and there are a bunch of known limitations, so
ehci may work better for you. On the other hand the xhci hardware
design is much more virtualization-friendly, thus xhci emulation uses
less resources (especially cpu). If you want to give xhci a try
use this to add the host controller ...qemu -device nec-usb-xhci,id=xhci
... then use "bus=xhci.0" when assigning usb devices.
You might want to take a look at that
hmm,
i tried
-device nec-usb-xhci,id=xhci \
-drive file=/dev/sde1,id=usbhdd,format=raw \
-device usb-storage,bus=xhci.0,drive=usbhdd \
to no avail. there is no new storage device present in my VM.
am i missing something?
Offline
hmm,
i tried
-device nec-usb-xhci,id=xhci \ -drive file=/dev/sde1,id=usbhdd,format=raw \ -device usb-storage,bus=xhci.0,drive=usbhdd \
to no avail. there is no new storage device present in my VM.
am i missing something?
Why dont you pass it as a virtio device?
-drive file=/dev/sde1,if=virtio,id=disk
You can get the virtio drivers here: http://alt.fedoraproject.org/pub/alt/vi … st/images/
Last edited by nbhs (2013-11-29 16:07:57)
Offline
thy for the Input
if i pass it with
-device nec-usb-xhci,id=xhci \
-drive file=/dev/sde1,if=virtio,id=usbhdd \
-device usb-storage,bus=xhci.0,drive=usbhdd \
i get the error:
Property 'virtio-blk-pci.drive' can't take value 'usbhdd', it's in use
googeling around says that i defined the interface two times.
i'm probably just thick but i can't see where the problem is.
Offline
thy for the Input
if i pass it with
-device nec-usb-xhci,id=xhci \ -drive file=/dev/sde1,if=virtio,id=usbhdd \ -device usb-storage,bus=xhci.0,drive=usbhdd \
i get the error:
Property 'virtio-blk-pci.drive' can't take value 'usbhdd', it's in use
googeling around says that i defined the interface two times.
i'm probably just thick but i can't see where the problem is.
Forget about the xhci controller, what i ment was something like this:
qemu-system-x86_64 -drive file=/dev/sde1,if=virtio,id
Offline
Hey guys, great work here so far. I am excited to get my setup to work. I have run into a problem getting my second PCIe vga card (AMD 7870) passed through to the vm. Any attempt in passing it through results in the whole system hanging which mean I need to power down/up the system. There appear to be no logs produced when the attempt is made. The system just hangs. Any insights on what could be happening?
Here are my specs.
Supermicro X7DWA-N
16DDR2 ECC Ram
2x AMD 7870 running open source radeon drivers.
Fakeraid Sil3132 eSata card
Dual Xeon 5462 (VT-x enabled)
I'm at a loss here and have been reading through the posts and other forums. I must be missing something here. Any help is appreciated. Thanks
I have an nvidia 660ti I might attempt to pass through instead just to see if its something there. But I suspect its not the issue.
Last edited by paradexes (2013-11-30 06:47:54)
Offline
This guide is awesome, my Windows installation works great. I do have one problem though, both graphics cards in my system have the same hardware id which makes me unable to run Xorg on my arch installation directly. I could run a second vm, but that seems a bit inefficient to me. Did anyone encounter this issue with 2 identical graphics cards and fix it? I don't know if it helps, but I'm using an AMD FX 8320 processor, and ASUS Sabertooth 990FX mobo and 2 AMD Radeon HD7850 graphics cards.
Offline
Hey guys, great work here so far. I am excited to get my setup to work. I have run into a problem getting my second PCIe vga card (AMD 7870) passed through to the vm. Any attempt in passing it through results in the whole system hanging which mean I need to power down/up the system. There appear to be no logs produced when the attempt is made. The system just hangs. Any insights on what could be happening?
Here are my specs.
Supermicro X7DWA-N
16DDR2 ECC Ram
2x AMD 7870 running open source radeon drivers.
Fakeraid Sil3132 eSata card
Dual Xeon 5462 (VT-x enabled)I'm at a loss here and have been reading through the posts and other forums. I must be missing something here. Any help is appreciated. Thanks
I have an nvidia 660ti I might attempt to pass through instead just to see if its something there. But I suspect its not the issue.
Your CPU's have no VT-d support.
Last edited by empie (2013-12-01 08:33:06)
Offline
This guide is awesome, my Windows installation works great. I do have one problem though, both graphics cards in my system have the same hardware id which makes me unable to run Xorg on my arch installation directly. I could run a second vm, but that seems a bit inefficient to me. Did anyone encounter this issue with 2 identical graphics cards and fix it? I don't know if it helps, but I'm using an AMD FX 8320 processor, and ASUS Sabertooth 990FX mobo and 2 AMD Radeon HD7850 graphics cards.
On recent kernels im able to unload my secondary card from the radeon module (before starting X) and then binding it to vfio without crashing the host (i do get some ugly kernel warns though) and without having to use pci-stub, you could try it.
Last edited by nbhs (2013-12-01 11:00:00)
Offline
sharkwouter wrote:This guide is awesome, my Windows installation works great. I do have one problem though, both graphics cards in my system have the same hardware id which makes me unable to run Xorg on my arch installation directly. I could run a second vm, but that seems a bit inefficient to me. Did anyone encounter this issue with 2 identical graphics cards and fix it? I don't know if it helps, but I'm using an AMD FX 8320 processor, and ASUS Sabertooth 990FX mobo and 2 AMD Radeon HD7850 graphics cards.
On recent kernels im able to unload my secondary card from the radeon module (before starting X) and then binding it to vfio without crashing the host (i do get some ugly kernel warns though) and without having to use pci-stub, you could try it.
I'll give it a try. Did anyone manage to pass-through his primary graphics adapter? I'd like to try running 2 vms, but I don't know if that could work.
Offline
paradexes wrote:Hey guys, great work here so far. I am excited to get my setup to work. I have run into a problem getting my second PCIe vga card (AMD 7870) passed through to the vm. Any attempt in passing it through results in the whole system hanging which mean I need to power down/up the system. There appear to be no logs produced when the attempt is made. The system just hangs. Any insights on what could be happening?
Here are my specs.
Supermicro X7DWA-N
16DDR2 ECC Ram
2x AMD 7870 running open source radeon drivers.
Fakeraid Sil3132 eSata card
Dual Xeon 5462 (VT-x enabled)I'm at a loss here and have been reading through the posts and other forums. I must be missing something here. Any help is appreciated. Thanks
I have an nvidia 660ti I might attempt to pass through instead just to see if its something there. But I suspect its not the issue.
Your CPU's have no VT-d support.
VT-d is only listed for the CPU when the CPU hosts root ports. This is an older system with a Northbridge-Southbridge architecture. The datasheet for the 5400 series chipset listed for this motherboard does say it supports VT-d. Unfortunately I don't have any idea why this is hanging, but I'd definitely try the Nvidia card.
http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses? Try https://www.redhat.com/mailman/listinfo/vfio-users
Offline
paradexes wrote:Hey guys, great work here so far. I am excited to get my setup to work. I have run into a problem getting my second PCIe vga card (AMD 7870) passed through to the vm. Any attempt in passing it through results in the whole system hanging which mean I need to power down/up the system. There appear to be no logs produced when the attempt is made. The system just hangs. Any insights on what could be happening?
Here are my specs.
Supermicro X7DWA-N
16DDR2 ECC Ram
2x AMD 7870 running open source radeon drivers.
Fakeraid Sil3132 eSata card
Dual Xeon 5462 (VT-x enabled)I'm at a loss here and have been reading through the posts and other forums. I must be missing something here. Any help is appreciated. Thanks
I have an nvidia 660ti I might attempt to pass through instead just to see if its something there. But I suspect its not the issue.
Your CPU's have no VT-d support.
Sorry man intel clearly states the CPU has the support. VT-x And I do have it otherwise I would not even be able to properly set up a 64bit VM. Thats one aspect of this tech that is required. It works, I just am having issues passing the card through to the VM. IOMMU is clearly there. Clearly I am missing something.
http://ark.intel.com/products/virtualizationtechnology Its in the list. E5462
I am giving the nvidia card a try on the host system on the guest as well. Hopefully that yields results. Thanks.
Last edited by paradexes (2013-12-02 03:32:28)
Offline
empie wrote:paradexes wrote:Hey guys, great work here so far. I am excited to get my setup to work. I have run into a problem getting my second PCIe vga card (AMD 7870) passed through to the vm. Any attempt in passing it through results in the whole system hanging which mean I need to power down/up the system. There appear to be no logs produced when the attempt is made. The system just hangs. Any insights on what could be happening?
Here are my specs.
Supermicro X7DWA-N
16DDR2 ECC Ram
2x AMD 7870 running open source radeon drivers.
Fakeraid Sil3132 eSata card
Dual Xeon 5462 (VT-x enabled)I'm at a loss here and have been reading through the posts and other forums. I must be missing something here. Any help is appreciated. Thanks
I have an nvidia 660ti I might attempt to pass through instead just to see if its something there. But I suspect its not the issue.
Your CPU's have no VT-d support.
Sorry man intel clearly states the CPU has the support. VT-x And I do have it otherwise I would not even be able to properly set up a 64bit VM. Thats one aspect of this tech that is required. It works, I just am having issues passing the card through to the VM. IOMMU is clearly there. Clearly I am missing something.
http://ark.intel.com/products/virtualizationtechnology Its in the list. E5462I am giving the nvidia card a try on the host system on the guest as well. Hopefully that yields results. Thanks.
VT-d != VT-x
http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses? Try https://www.redhat.com/mailman/listinfo/vfio-users
Offline
paradexes wrote:empie wrote:Your CPU's have no VT-d support.
Sorry man intel clearly states the CPU has the support. VT-x And I do have it otherwise I would not even be able to properly set up a 64bit VM. Thats one aspect of this tech that is required. It works, I just am having issues passing the card through to the VM. IOMMU is clearly there. Clearly I am missing something.
http://ark.intel.com/products/virtualizationtechnology Its in the list. E5462I am giving the nvidia card a try on the host system on the guest as well. Hopefully that yields results. Thanks.
VT-d != VT-x
Agreed and thanks. Just glad its not just me saying it. That said I am still kind of at odds with the host freezing. If anyone has any ideas that would be great. I have added the nvidia card and am going to give it a go with that. Altho I think it may likley happen with that one as well.
Offline
@paradexes
I think you misunderstood aw. VT-x is not the same thing as VT-d. And according to the ark your CPUs do not support VT-d. I don't think VT-d even existed when your CPU hit the market (2007).
The good news is that your mobo does support VT-d, so your setup isn't a total loss. Here's a list of '5000 Sequence' Xeons that support VT-d.
Last edited by alphaniner (2013-12-02 14:35:32)
But whether the Constitution really be one thing, or another, this much is certain - that it has either authorized such a government as we have had, or has been powerless to prevent it. In either case, it is unfit to exist.
-Lysander Spooner
Offline
Thanks for clearing it up. Yes you are correct. I did some checking myself. I guess my whole concern is whether I will be able to pass the GPU at this point or not. I am not terribly concerned about any other hardware besides maybe USB hardware.
Offline
IIRC the PAGE_FAULT_IN_NONPAGED_AREA is the manifestation of the -cpu host problem on Nvidia. Try -cpu qemu64 or one of the CPU specific types. Note that you can dump the VBIOS, modify it, then load it with romfile= to avoid flashing it back to hardware.
You were right about CPU type - I used SandyBridge and was able to install.
After installing WIn7, I installed GRID K2 drivers, but now windows report Code 12 on NVIDIA GRID K2 device: This device cannot find enough free resources that it can use. If you want to use this device, you will need to disable one of the other devices on this system.
I have tried adding -vga none to the qemu command line and booting like this after I installed the drivers, but i dont get any signal on either video outputs of the card still.
Any ideas anyone?
Thanks,
Ilya.
Offline
aw wrote:IIRC the PAGE_FAULT_IN_NONPAGED_AREA is the manifestation of the -cpu host problem on Nvidia. Try -cpu qemu64 or one of the CPU specific types. Note that you can dump the VBIOS, modify it, then load it with romfile= to avoid flashing it back to hardware.
You were right about CPU type - I used SandyBridge and was able to install.
After installing WIn7, I installed GRID K2 drivers, but now windows report Code 12 on NVIDIA GRID K2 device: This device cannot find enough free resources that it can use. If you want to use this device, you will need to disable one of the other devices on this system.
I have tried adding -vga none to the qemu command line and booting like this after I installed the drivers, but i dont get any signal on either video outputs of the card still.
Any ideas anyone?
Real GRID cards report the same Code 12 on the q35 chipset model, try 440fx instead. I can't figure out what resources it's missing, nor have I had time to experiment. Linux guests will work fine on the q35 model. Again, you're not going to get pre-boot VGA output unless the VBIOS matches the hardware. Also, Nvidia does not support GRID in a VGA mode, it's only supported as a secondary device to emulated VGA. The professional version of the drivers detect that they're running on a VM and behave differently. The quirks enabled with x-vga=on do not work correctly with those drivers.
http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses? Try https://www.redhat.com/mailman/listinfo/vfio-users
Offline
Well it appears installing the nvidia card and blacklisting it from the host sems to resolve the hanging issue. However now I am getting this error. Since the motherboard supports IOMMU would it not support vfio? at least in theory. Any thoughts?
Error starting domain: internal error: Unable to reset PCI device 0000:02:00.0: internal error: Active 0000:02:00.1 devices on bus with 0000:02:00.0, not doing bus reset
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 96, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 117, in tmpcb
callback(*args, **kwargs)
File "/usr/share/virt-manager/virtManager/domain.py", line 1162, in startup
self._backend.create()
File "/usr/lib/python2.7/dist-packages/libvirt.py", line 698, in create
if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: internal error: Unable to reset PCI device 0000:02:00.0: internal error: Active 0000:02:00.1 devices on bus with 0000:02:00.0, not doing bus reset
Offline
Well it appears installing the nvidia card and blacklisting it from the host sems to resolve the hanging issue. However now I am getting this error. Since the motherboard supports IOMMU would it not support vfio? at least in theory. Any thoughts?
Error starting domain: internal error: Unable to reset PCI device 0000:02:00.0: internal error: Active 0000:02:00.1 devices on bus with 0000:02:00.0, not doing bus reset
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 96, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 117, in tmpcb
callback(*args, **kwargs)
File "/usr/share/virt-manager/virtManager/domain.py", line 1162, in startup
self._backend.create()
File "/usr/lib/python2.7/dist-packages/libvirt.py", line 698, in create
if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: internal error: Unable to reset PCI device 0000:02:00.0: internal error: Active 0000:02:00.1 devices on bus with 0000:02:00.0, not doing bus reset
Suspect you're not using vfio because libvirt only tries to reset devices with legacy KVM device assignment.
http://vfio.blogspot.com
Looking for a more open forum to discuss vfio related uses? Try https://www.redhat.com/mailman/listinfo/vfio-users
Offline
paradexes wrote:Well it appears installing the nvidia card and blacklisting it from the host sems to resolve the hanging issue. However now I am getting this error. Since the motherboard supports IOMMU would it not support vfio? at least in theory. Any thoughts?
Error starting domain: internal error: Unable to reset PCI device 0000:02:00.0: internal error: Active 0000:02:00.1 devices on bus with 0000:02:00.0, not doing bus reset
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 96, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 117, in tmpcb
callback(*args, **kwargs)
File "/usr/share/virt-manager/virtManager/domain.py", line 1162, in startup
self._backend.create()
File "/usr/lib/python2.7/dist-packages/libvirt.py", line 698, in create
if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
libvirtError: internal error: Unable to reset PCI device 0000:02:00.0: internal error: Active 0000:02:00.1 devices on bus with 0000:02:00.0, not doing bus resetSuspect you're not using vfio because libvirt only tries to reset devices with legacy KVM device assignment.
Ok. I will keep at it and post my results. Thanks. Being that the motherboard supports IOMMU I assume its possible to make this work?
Offline