You are not logged in.
@Apex8: Oh wow, I thought this might be a DNS issue so I've just installed a VPN and I get through first time. Stupid ISP. Sorry for the off topic posts.
Last edited by cdrjameson (2014-05-30 15:55:37)
Offline
rabcor wrote:PATCH COMMAND: patch -p0 -g0 -E --no-backup-if-mismatch < '/etc/portage/patches/sys-kernel/gentoo-sources/ACS_Override.patch'
I have no idea what to do here, I'm a total noob when it comes to "patch" and "diff". I know it fails at line 9 and 30 (i.e. the "@@" lines in the patch) but how to fix it I have no clue. The Nvidia Proprietary driver patch applied just fine though.
Try it with -p1
I highly doubt doing that would change anything (then again I am noob) but my understanding is that doing -p1 would make
a/drivers/pci/quirks.c
into
/drivers/pci/quirks.c
(but maybe -p2 might make a difference)
Either way, I decided to try and copy the file to my home folder and manually patch it.
I created 'a/drivers/pci/quirks.c' and then:
$ patch -p0 -g0 -E < 'ACS_Override.patch'
patching file a/drivers/pci/quirks.c
patch unexpectedly ends in middle of line
Hunk #1 FAILED at 3292.
1 out of 1 hunk FAILED -- saving rejects to file a/drivers/pci/quirks.c.rej
What do I do? I suspect this means that the patch is incompatible with my pci quirks.c file (made for a different version of it) does this mean that I have to somehow make a new patch file?
Edit: That was indeed it, posted my file below.
Last edited by rabcor (2014-05-30 16:28:32)
Offline
@shawly regarding synergy: It should be the normal case, that your VM works flawlessly. Whenever there is a serious problem, e.g. an bsod, you can go to the qemu console and enter system_reset; the vm will reboot. If this doesn't solve the problem you could prepare a second qemu script, which runs the vm in a window where you are able to use your keyboad and mouse.
This strategy works good enough for me, because like I said: the normal case is that the VM runs without any problems.
Thanks for the answer, but this doesn't really answer my question, I just asked for options BESIDES synergy, because maybe there are better ways.
Anyone got an answer for my problem with efi or the Nvidia drivers under Windows?
Offline
Well you could get an 2:1 KVM-Switch and pass through one of your usb-controllers to the vm. Then you can switch between host-/vm access wich your keyboard and mouse.
Offline
This is my Gentoo 3.14.4 (Not 100% sure if this is a Gentoo exclusive issue though, for all I know kernel 3.14.4 might have come with a different version of quirks.c than previous releases) compatible ACS Override patch (note: I did not bother adding in the documentation changes with it like in the original patch)
(command used: diff -Naur a/drivers/pci/quirks.c b/drivers/pci/quirks.c > ACS.patch)
--- a/drivers/pci/quirks.c 2014-05-30 16:08:19.561232936 +0000
+++ b/drivers/pci/quirks.c 2014-05-30 16:18:44.745241038 +0000
@@ -3423,6 +3423,107 @@
#endif
}
+static bool acs_on_downstream;
+static bool acs_on_multifunction;
+
+#define NUM_ACS_IDS 16
+struct acs_on_id {
+ unsigned short vendor;
+ unsigned short device;
+};
+static struct acs_on_id acs_on_ids[NUM_ACS_IDS];
+static u8 max_acs_id;
+
+static __init int pcie_acs_override_setup(char *p)
+{
+ if (!p)
+ return -EINVAL;
+
+ while (*p) {
+ if (!strncmp(p, "downstream", 10))
+ acs_on_downstream = true;
+ if (!strncmp(p, "multifunction", 13))
+ acs_on_multifunction = true;
+ if (!strncmp(p, "id:", 3)) {
+ char opt[5];
+ int ret;
+ long val;
+
+ if (max_acs_id >= NUM_ACS_IDS - 1) {
+ pr_warn("Out of PCIe ACS override slots (%d)\n",
+ NUM_ACS_IDS);
+ goto next;
+ }
+
+ p += 3;
+ snprintf(opt, 5, "%s", p);
+ ret = kstrtol(opt, 16, &val);
+ if (ret) {
+ pr_warn("PCIe ACS ID parse error %d\n", ret);
+ goto next;
+ }
+ acs_on_ids[max_acs_id].vendor = val;
+
+ p += strcspn(p, ":");
+ if (*p != ':') {
+ pr_warn("PCIe ACS invalid ID\n");
+ goto next;
+ }
+
+ p++;
+ snprintf(opt, 5, "%s", p);
+ ret = kstrtol(opt, 16, &val);
+ if (ret) {
+ pr_warn("PCIe ACS ID parse error %d\n", ret);
+ goto next;
+ }
+ acs_on_ids[max_acs_id].device = val;
+ max_acs_id++;
+ }
+next:
+ p += strcspn(p, ",");
+ if (*p == ',')
+ p++;
+ }
+
+ if (acs_on_downstream || acs_on_multifunction || max_acs_id)
+ pr_warn("Warning: PCIe ACS overrides enabled; This may allow non-IOMMU protected peer-to-peer DMA\n");
+
+ return 0;
+}
+early_param("pcie_acs_override", pcie_acs_override_setup);
+
+static int pcie_acs_overrides(struct pci_dev *dev, u16 acs_flags)
+{
+ int i;
+
+ /* Never override ACS for legacy devices or devices with ACS caps */
+ if (!pci_is_pcie(dev) ||
+ pci_find_ext_capability(dev, PCI_EXT_CAP_ID_ACS))
+ return -ENOTTY;
+
+ for (i = 0; i < max_acs_id; i++)
+ if (acs_on_ids[i].vendor == dev->vendor &&
+ acs_on_ids[i].device == dev->device)
+ return 1;
+
+ switch (pci_pcie_type(dev)) {
+ case PCI_EXP_TYPE_DOWNSTREAM:
+ case PCI_EXP_TYPE_ROOT_PORT:
+ if (acs_on_downstream)
+ return 1;
+ break;
+ case PCI_EXP_TYPE_ENDPOINT:
+ case PCI_EXP_TYPE_UPSTREAM:
+ case PCI_EXP_TYPE_LEG_END:
+ case PCI_EXP_TYPE_RC_END:
+ if (acs_on_multifunction && dev->multifunction)
+ return 1;
+ }
+
+ return -ENOTTY;
+}
+
static const struct pci_dev_acs_enabled {
u16 vendor;
u16 device;
@@ -3434,6 +3535,7 @@
{ PCI_VENDOR_ID_ATI, 0x439d, pci_quirk_amd_sb_acs },
{ PCI_VENDOR_ID_ATI, 0x4384, pci_quirk_amd_sb_acs },
{ PCI_VENDOR_ID_ATI, 0x4399, pci_quirk_amd_sb_acs },
+ { PCI_ANY_ID, PCI_ANY_ID, pcie_acs_overrides },
{ 0 }
};
Compatible with gentoo kernel 3.14.4, not sure if it was gentoo only or if it was just a recent kernel update that changed the file, either way if anyone fails to run the original ACS patch try this instead.
Last edited by rabcor (2014-05-30 16:41:50)
Offline
Well you could get an 2:1 KVM-Switch and pass through one of your usb-controllers to the vm. Then you can switch between host-/vm access wich your keyboard and mouse.
Would be an option yeah, but I guess I'll pass the mouse and keyboard through and use Synergy to access my Gnome desktop, then I shouldn't get any delay while playing, since I can't imagine that it's possible to play games as Synergy-Client without any delay or other problems.
Anyway, I looked through this thread and it seems, that nobody has tried to get OVMF working since february.. Guess it isn't working at all
And I'll try to use an older version of the Nvidia driver, maybe this will work.
Last edited by shawly (2014-05-30 18:15:13)
Offline
@shawly: If it helps, I can tell you that I was able to run bioshock infinite without any input delay. I just configured a hotkey for locking the mouse/keyboard in the VM and activated relative mouse moves.
Offline
@shawly: If it helps, I can tell you that I was able to run bioshock infinite without any input delay. I just configured a hotkey for locking the mouse/keyboard in the VM and activated relative mouse moves.
Sounds promising! So you didn't pass the mouse and keyboard to the guest? How did you do that?
Offline
I'm using my host as synergy server and the vm is just a client. Synergy can be configured via script or via its GUI. The latter is pretty intuitive; maybe have a look at YouTube for this. Furthermore a passed through the usb3 controller and where an gamepad is plugged in. So the gamepad is only seen by the vm and works entirely without delay. But the delay isn't the problem, as I said.
Offline
[…]Anyway, I looked through this thread and it seems, that nobody has tried to get OVMF working since february.. Guess it isn't working at all […]
I don't know about your setup, but OVMF works for me (see here for my HW). I just tested a VM with arch as guest and host and the open-source radeon drivers in the guest. This is the command I used
/usr/bin/qemu-system-x86_64 -enable-kvm -vga none -nographic -cpu host -smp 4,sockets=1,cores=4,threads=1 -m 4096 -mem-path /dev/hugepages -device vfio-pci,host=06:00.0,addr=10.0,multifunction=on,x-vga=on -device vfio-pci,host=06:00.1,addr=10.1 -device vfio-pci,host=0000:00:13.0 -device vfio-pci,host=0000:00:13.2 -usb -device usb-host,vendorid=0x03f0,productid=0x0024 -netdev bridge,br=br0,id=hostnet0 -net nic,model=virtio,netdev=hostnet0 -drive file=arch_uefi.img,id=drive0,if=virtio,media=disk,aio=native -monitor stdio -boot menu=on -pflash /usr/share/ovmf/ovmf_x64.bin
My software versions are extra/ovmf 15280-1, local/qemu-git 2.1.r32448.gfdaad47-1 and linux 3.15.0-rc6-mainline+
i'm sorry for my poor english wirting skills…
Offline
I don't know about your setup, but OVMF works for me (see here for my HW). I just tested a VM with arch as guest and host and the open-source radeon drivers in the guest.
My software versions are extra/ovmf 15280-1, local/qemu-git 2.1.r32448.gfdaad47-1 and linux 3.15.0-rc6-mainline+
I'm using the same version of ovmf, qemu-git 2.1 but the linux 3.14.4 kernel. Do you think it'll make any difference if I switch to 3.15? Just tried it again, blackscreen..
My setup is at the bottom of this document, sombody added it already and I added some things.
Edit: Uhm, well, the problem solved itself... I don't know how, and I don't know why but suddenly it just boots when I use the -L parameter...
AND! I'm an idiot, I downloaded the 32bit Nvidia drivers, since it's freaking hard to navigate through a website without a mouse in the VM it must have chosen 32 bit instead of 64 and I didn't saw that.. damn I feel really stupid xD
Edit2: Ok it didn't work with ovmf, it just booted from SeaBios with the -L parameter.. god knows why
Just tried with the -pflash parameter again, but had no luck.. I have no idea what causes this. When I use SeaBIOS my monitor turns on and it boots, but with ovmf it doesn't turn on and if I use qemu to test if it's working it's just black.
Edit3: I gave up on ovmf, now I installed the driver for the nvidia card but sadly, I get the error code 43 in the device manager...
I used the package in the first post, therefore I got all the patches that come with this package.. Was this a mistake?
Last edited by shawly (2014-05-30 22:01:37)
Offline
Edit3: I gave up on ovmf, now I installed the driver for the nvidia card but sadly, I get the error code 43 in the device manager...
I used the package in the first post, therefore I got all the patches that come with this package.. Was this a mistake?
Nvidia drivers newer than 335.23 are broken
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
Nvidia drivers newer than 335.23 are broken
Good to know, that means 335.23 should work, will try that.
Offline
Hey guys, I got it (mostly) working with this command:
/home/esmth/bin/vfio-bind 0000:01:00.1 0000:01:00.0
/home/esmth/src/qemu/x86_64-softmmu/qemu-system-x86_64 \
-M q35 -drive file=/home/esmth/image.img,id=disk,format=raw -device ide-hd,bus=ide.0,drive=disk \
-enable-kvm -m 4096 -cpu host \
-bios /home/esmth/src/seabios/out/bios.bin -vga none \
-smp 2,sockets=1,cores=2,threads=1 \
-device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 \
-device vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on \
-device vfio-pci,host=01:00.1,bus=root.1,addr=00.1 \
-usb -usbdevice host:046d:c52b -usbdevice host:0d62:001d -usbdevice host:0781:5530 \
-nographic -boot menu=on
I'm running kernel 3.15-rc6.
the only problem I'm having right now is that I get tons of this:
May 30 23:13:20 plebeian kernel: [ 2525.114596] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0002 address=0x0000000020fdb080 flags=0x0010]
May 30 23:13:20 plebeian kernel: [ 2525.114831] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0002 address=0x0000000020fdb2c0 flags=0x0010]
May 30 23:13:20 plebeian kernel: [ 2525.115066] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0002 address=0x0000000020fdb100 flags=0x0010]
May 30 23:13:20 plebeian kernel: [ 2525.115306] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0002 address=0x0000000020fdb5c0 flags=0x0010]
May 30 23:13:20 plebeian kernel: [ 2525.115543] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0002 address=0x0000000020fdb1c0 flags=0x0010]
May 30 23:13:20 plebeian kernel: [ 2525.115778] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0002 address=0x0000000020fdb540 flags=0x0010]
May 30 23:13:20 plebeian kernel: [ 2525.116012] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0002 address=0x0000000020fdb280 flags=0x0010]
May 30 23:13:20 plebeian kernel: [ 2525.116248] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0002 address=0x0000000020fdb180 flags=0x0010]
May 30 23:13:20 plebeian kernel: [ 2525.116485] AMD-Vi: Event logged [IO_PAGE_FAULT device=01:00.0 domain=0x0002 address=0x0000000020fdb340 flags=0x0010]
when trying to install the gpu drivers in the guest. The guest restarts and the drivers can't be Installed in windows. If its any use, I have an r9-290x as the dGPU and i'm using my 7850k's intergrated graphics for the host.
Edit: I installed the gpu drivers using the -vga std option, but now the guest crashes after the windows bootup logo. I removed it in safe mode and i'm back where i started at the beginning of this post.
Last edited by esmth (2014-05-31 03:45:28)
Offline
I think I'm pretty close to getting this working now. I have the ACS Override patch in my kernel for my intel i7 2600 CPU and I have the VGA_ARB patch for my nvidia proprietary drivers set up as well
(Host: GTX 550-Ti
Guest: GTX 670)
When I try to test my machine with (should be the same as in the OP but with 02 instead of 07 as device host)
I get the following errors (running as root, if I run as user I get the same last two lines, but the first two will be "vfio: error opening /dev/vfio/6: Permission denied" and "vfio: failed to get group 6")
#qemu-system-x86_64 -enable-kvm -M q35 -m 1024 -cpu host -smp 6,sockets=1,cores=8,threads=1 -bios /usr/share/qemu/bios.bin -vga none -device ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1 -device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on -device vfio-pci,host=02:00.1,bus=root.1,addr=00.1
qemu-system-x86_64: -device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio: error, group 6 is not viable, please ensure all devices within the iommu_group are bound to their vfio bus driver.
qemu-system-x86_64: -device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio: failed to get group 6
qemu-system-x86_64: -device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: Device initialization failed.
qemu-system-x86_64: -device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: Device 'vfio-pci' could not be initialized
More info:
#lspci
01:00.0 VGA compatible controller: NVIDIA Corporation GF116 [GeForce GTX 550 Ti] (rev a1)
01:00.1 Audio device: NVIDIA Corporation GF116 High Definition Audio Controller (rev a1)
02:00.0 VGA compatible controller: NVIDIA Corporation GK104 [GeForce GTX 670] (rev a1)
02:00.1 Audio device: NVIDIA Corporation GK104 HDMI Audio Controller (rev a1)
#lspci -n
01:00.0 0300: 10de:1244 (rev a1)
01:00.1 0403: 10de:0bee (rev a1)
02:00.0 0300: 10de:1189 (rev a1)
02:00.1 0403: 10de:0e0a (rev a1)
#dmesg | grep pci-stub
[ 0.000000] Command line: BOOT_IMAGE=/boot/kernel-3.14.4-Gentoo root=/dev/sda1 ro quiet pci-stub.ids=10de:1189,10de:0e0a
[ 0.000000] Kernel command line: BOOT_IMAGE=/boot/kernel-3.14.4-Gentoo root=/dev/sda1 ro quiet pci-stub.ids=10de:1189,10de:0e0a
[ 0.273833] pci-stub: add 10DE:1189 sub=FFFFFFFF:FFFFFFFF cls=00000000/00000000
[ 0.273839] pci-stub 0000:02:00.0: claimed by stub
[ 0.273841] pci-stub: add 10DE:0E0A sub=FFFFFFFF:FFFFFFFF cls=00000000/00000000
[ 0.273846] pci-stub 0000:02:00.1: claimed by stub
[ 1.446046] pci-stub 0000:02:00.0: enabling device (0000 -> 0003)
# cat /etc/modprobe.d/kvm.conf
options vfio_iommu_type1 allow_unsafe_interrupts=1
options kvm ignore_msrs=1
#zgrep VFIO /proc/config.gz
CONFIG_VFIO_IOMMU_TYPE1=y
CONFIG_VFIO=y
CONFIG_VFIO_PCI=y
CONFIG_VFIO_PCI_VGA=y
CONFIG_KVM_VFIO=y
I think with this everything should be working, I do not run vfio-bind on bootup though (haven't figured out how to do it with OpenRC which is what gentoo uses) but I run it as root before I try to launch the VM.
#vfio-bind 0000:02:00.0 0000:02:00.1
(It shows no output, I assume this is normal)
How do I fix this problem?
Edit: Solved!
Solution was to add
pcie_acs_override=downstream
To the command line (basically activate the ACS override patch, silly me...)
Oh man that feels so good, it finally works
Now I am wondering if this can be applied to Xen HVMs? Has anyone tried? Also I still get this when I run as user, how do I fix that?
qemu-system-x86_64: -device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio: error opening /dev/vfio/13: Permission denied
qemu-system-x86_64: -device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio: failed to get group 13
Last edited by rabcor (2014-05-31 08:25:10)
Offline
when trying to install the gpu drivers in the guest. The guest restarts and the drivers can't be Installed in windows. If its any use, I have an r9-290x as the dGPU and i'm using my 7850k's intergrated graphics for the host.
Edit: I installed the gpu drivers using the -vga std option, but now the guest crashes after the windows bootup logo. I removed it in safe mode and i'm back where i started at the beginning of this post.
It looks like you suffer from the "no proper reset method is known for R9 290X series" like others including me. What I did to get it working is the following:
#1 Install Windows 7 using -vga std AND -no-reboot
#2 Install Synergy on host and inside VM and configure it
#3 Assign VGA device via vfio and use -vga none AND keep -no-reboot. After that I get already VGA post bios screen and Windows 7 boots with VGA resolution
#4 Login to Windows 7 and install Catalyst driver (latest stable)
#5 If it wants to reboot let it do and QEMU will stop and shutdown due to '-no-reboot' switch
#6 Reboot the host (or do the suspend/resume cycle as workaround)
#7 Start VM
With R9 290X series you will not get VM reboot working (for now) and that's why I keep the '-no-reboot' option always and if VM is rebooted I have to make short suspend/resume cycle.
Offline
It looks like you suffer from the "no proper reset method is known for R9 290X series" like others including me. What I did to get it working is the following:
#1 Install Windows 7 using -vga std AND -no-reboot
#2 Install Synergy on host and inside VM and configure it
#3 Assign VGA device via vfio and use -vga none AND keep -no-reboot. After that I get already VGA post bios screen and Windows 7 boots with VGA resolution
#4 Login to Windows 7 and install Catalyst driver (latest stable)
#5 If it wants to reboot let it do and QEMU will stop and shutdown due to '-no-reboot' switch
#6 Reboot the host (or do the suspend/resume cycle as workaround)
#7 Start VM
Thanks, I'll try this tomorrow morning. I also have a 550ti and a HD6870 that i can test with. Do those older GPUs not have these issues?
edit: is Windows 7 required? I've been trying to use windows 8.
Last edited by esmth (2014-06-01 03:47:11)
Offline
I wonder this as well, is windows 7 the only supported version? or is it possible to use windows 8 instead? I'm thinking this since despite hating Windows 8 so much that I fled to Linux land when I saw it coming, it is hard to deny that it consumes less resources than the 7 which makes it more ideal for VMs (I mean the more left over resources for the host, the better right?)
Anyhow I have a slight problem. When I run qemu as a user I get this message
qemu-system-x86_64: -device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio: error opening /dev/vfio/13: Permission denied
qemu-system-x86_64: -device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: vfio: failed to get group 13
qemu-system-x86_64: -device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: Device initialization failed.
qemu-system-x86_64: -device vfio-pci,host=02:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on: Device 'vfio-pci' could not be initialized
And I absolutely do not want to be running qemu as root even if I "can"
How do I give my user the permissions to do this? I'm running Gentoo right now but it can't be that much different from Arch (Biggest difference I noticed as an end user is OpenRC rather than Systemd, something I chose to live with rather than fight.)
PS: I have a physical 3TB GPT partition that i want to mount on the host and share with the VM, what is the safest way for me to share it?
Offline
Thanks, I'll try this tomorrow morning. I also have a 550ti and a HD6870 that i can test with. Do those older GPUs not have these issues?
edit: is Windows 7 required? I've been trying to use windows 8.
I've also tried Windows 8.1 but installed Catalyst driver manual because that one from Windows update freezes my VM always during installation. So I downloaded it in advance and installed it after assigning the R9 290X. AFAIR the 550 TI should work fine without having reboot issues of VM. I would expect the same for the HD6870 as my 7870 GHz edition also works fine without reset issues.
Offline
I think I found ultimate fix for code 43 on windows and RmInitAdapter failed on linux with nvidia devices with newer driver.
What I did was masking hypervisor cpuid signature and voala!!!
diff --git a/target-i386/kvm.c b/target-i386/kvm.c
index 4389959..e6ee444 100644
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -527,17 +527,17 @@ int kvm_arch_init_vcpu(CPUState *cs)
has_msr_hv_hypercall = true;
}
- memcpy(signature, "KVMKVMKVM\0\0\0", 12);
- c = &cpuid_data.entries[cpuid_i++];
- c->function = KVM_CPUID_SIGNATURE | kvm_base;
- c->eax = 0;
- c->ebx = signature[0];
- c->ecx = signature[1];
- c->edx = signature[2];
-
- c = &cpuid_data.entries[cpuid_i++];
- c->function = KVM_CPUID_FEATURES | kvm_base;
- c->eax = env->features[FEAT_KVM];
+ // memcpy(signature, "KVMKVMKVM\0\0\0", 12);
+ // c = &cpuid_data.entries[cpuid_i++];
+ // c->function = KVM_CPUID_SIGNATURE | kvm_base;
+ // c->eax = 0;
+ // c->ebx = signature[0];
+ // c->ecx = signature[1];
+ // c->edx = signature[2];
+
+ // c = &cpuid_data.entries[cpuid_i++];
+ // c->function = KVM_CPUID_FEATURES | kvm_base;
+ // c->eax = env->features[FEAT_KVM];
has_msr_async_pf_en = c->eax & (1 << KVM_FEATURE_ASYNC_PF);
Apparently the driver checking for hypervisor cpuid signature and bail if detecting presence of those signature unless the gpu is nvidia GRID.
After 2 frustrating weeks at last.
F*ck you nvidia!!!
Last edited by syndtr (2014-06-01 12:16:27)
Offline
Fucking Nvidia trying to force GRID upon people... That'll teach em should be added to the OP for nvidia workarounds. But you could have mentioned that it's supposed to be applied to qemu.
Anyways, apart from my error 3 posts up, I have another error when trying to mount a physical partition to qemu. Using:
-drive file=/dev/sdc,id=disk,format=raw -device ide-hd,bus=ahci.0,drive=disk1
I get:
qemu-system-x86_64: -device ide-hd,bus=ahci.0,drive=disk: Bus 'ahci.0' not found
Last edited by rabcor (2014-06-01 13:19:26)
Offline
I think I found ultimate fix for code 43 on windows and RmInitAdapter failed on linux with nvidia devices with newer driver.
What I did was masking hypervisor cpuid signature and voala!!!diff --git a/target-i386/kvm.c b/target-i386/kvm.c index 4389959..e6ee444 100644 --- a/target-i386/kvm.c +++ b/target-i386/kvm.c @@ -527,17 +527,17 @@ int kvm_arch_init_vcpu(CPUState *cs) has_msr_hv_hypercall = true; } - memcpy(signature, "KVMKVMKVM\0\0\0", 12); - c = &cpuid_data.entries[cpuid_i++]; - c->function = KVM_CPUID_SIGNATURE | kvm_base; - c->eax = 0; - c->ebx = signature[0]; - c->ecx = signature[1]; - c->edx = signature[2]; - - c = &cpuid_data.entries[cpuid_i++]; - c->function = KVM_CPUID_FEATURES | kvm_base; - c->eax = env->features[FEAT_KVM]; + // memcpy(signature, "KVMKVMKVM\0\0\0", 12); + // c = &cpuid_data.entries[cpuid_i++]; + // c->function = KVM_CPUID_SIGNATURE | kvm_base; + // c->eax = 0; + // c->ebx = signature[0]; + // c->ecx = signature[1]; + // c->edx = signature[2]; + + // c = &cpuid_data.entries[cpuid_i++]; + // c->function = KVM_CPUID_FEATURES | kvm_base; + // c->eax = env->features[FEAT_KVM]; has_msr_async_pf_en = c->eax & (1 << KVM_FEATURE_ASYNC_PF);
Apparently the driver checking for hypervisor cpuid signature and bail if detecting presence of those signature unless the gpu is nvidia GRID.
After 2 frustrating weeks at last.
F*ck you nvidia!!!
Wow, I was suspicious, but didn't actually think nvidia would sink this low to try it. I suppose there's still a chance that it was an oversight and not an attempt to be malicious. Maybe we can make a runtime option for qemu to hide the hypervisor.
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
syndtr wrote:I think I found ultimate fix for code 43 on windows and RmInitAdapter failed on linux with nvidia devices with newer driver.
What I did was masking hypervisor cpuid signature and voala!!!Apparently the driver checking for hypervisor cpuid signature and bail if detecting presence of those signature unless the gpu is nvidia GRID.
After 2 frustrating weeks at last.
F*ck you nvidia!!!Wow, I was suspicious, but didn't actually think nvidia would sink this low to try it. I suppose there's still a chance that it was an oversight and not an attempt to be malicious. Maybe we can make a runtime option for qemu to hide the hypervisor.
It's also sufficient to just change the signature, for instance:
--- a/target-i386/kvm.c
+++ b/target-i386/kvm.c
@@ -528,7 +528,7 @@ int kvm_arch_init_vcpu(CPUState *cs)
has_msr_hv_hypercall = true;
}
- memcpy(signature, "KVMKVMKVM\0\0\0", 12);
+ memcpy(signature, "kvmkvmkvm\0\0\0", 12);
c = &cpuid_data.entries[cpuid_i++];
c->function = KVM_CPUID_SIGNATURE | kvm_base;
c->eax = 0;
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
But you could have mentioned that it's supposed to be applied to qemu.
Ahh, sorry.. I forgot that.
Wow, I was suspicious, but didn't actually think nvidia would sink this low to try it.
I can't believe it either.
I suppose there's still a chance that it was an oversight and not an attempt to be malicious.
I hope that's true.
Maybe we can make a runtime option for qemu to hide the hypervisor.
Great idea.
Anyway, on linux guest patching nvidia kmod by making os_is_vgx_hyper to return true also did the trick.
diff --git a/os-interface.c b/os-interface.c
index 13cd3b6..79629df 100644
--- a/os-interface.c
+++ b/os-interface.c
@@ -1247,11 +1247,7 @@ NvBool NV_API_CALL os_is_xen_dom0(void)
NvBool NV_API_CALL os_is_vgx_hyper(void)
{
-#if defined(NV_VGX_HYPER)
return TRUE;
-#else
- return FALSE;
-#endif
}
void NV_API_CALL os_bug_check(NvU32 bugCode, const char *bugCodeStr)
Offline
aw wrote:syndtr wrote:I think I found ultimate fix for code 43 on windows and RmInitAdapter failed on linux with nvidia devices with newer driver.
What I did was masking hypervisor cpuid signature and voala!!!Apparently the driver checking for hypervisor cpuid signature and bail if detecting presence of those signature unless the gpu is nvidia GRID.
After 2 frustrating weeks at last.
F*ck you nvidia!!!Wow, I was suspicious, but didn't actually think nvidia would sink this low to try it. I suppose there's still a chance that it was an oversight and not an attempt to be malicious. Maybe we can make a runtime option for qemu to hide the hypervisor.
It's also sufficient to just change the signature, for instance:
--- a/target-i386/kvm.c +++ b/target-i386/kvm.c @@ -528,7 +528,7 @@ int kvm_arch_init_vcpu(CPUState *cs) has_msr_hv_hypercall = true; } - memcpy(signature, "KVMKVMKVM\0\0\0", 12); + memcpy(signature, "kvmkvmkvm\0\0\0", 12); c = &cpuid_data.entries[cpuid_i++]; c->function = KVM_CPUID_SIGNATURE | kvm_base; c->eax = 0;
You're right, it's work just by changing the signature.
Offline