[qubes-users] Re: Help regarding IOMMU and HVM
I found a solution to my problem. The culprit was my overclock. I don't know why I didn't reset my BIOS settings in start of troubleshooting, but today I reset it and everything works... Interesting note though, naturally I tried to pinpoint what part of overclock is messing up the start of HVM VM's and it's the CPU multiplier. My CPU is AMD A8-6600K so I assumed everything above its maximum turbo frequency would cause the error (x42) but last multiplier before VM's wouldn't load is 43. Vcore didn't affect loading. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5fc5747e-a2d8-4e5f-8b01-326cd89ab93e%40googlegroups.com.
[qubes-users] Re: Help regarding IOMMU and HVM
!!! I have some, hopefully, great news. I was messing around searching some help online and I got an idea to try installing Win7 StandaloneVM following the https://www.qubes-os.org/doc/windows-tools/ guide. I kid you not, it worked on first try! HVM mode, even got the Windows Tools working. Is there some logs I could extract from this new VM that would help find the error in Linux VMs? Thank you very much for your help so far. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/83c7e76b-5b0b-4328-8cb0-c529656ca68b%40googlegroups.com.
[qubes-users] Re: Help regarding IOMMU and HVM
When I compared your logs to what I have, it came to my mind that some years ago I had similar problems - because of processor microcode which was too old. I had to update that to get hvms working. I couldn't find which microcode version you have, it is somehow not shown in the cpu log you uploaded (cat /proc/cpuinfo should show that). But, the solution is not easy, because processor microcode is usually stored in the BIOS statically (in non-UEFI bioses), and I don't know if you can change that dynamically somehow with your UEFI BIOS or while the kernel is booting. I use a special BIOS (coreboot), where I can statically change the microcode to a newer one, but it needs external flashing with the right set of tools (SOIC clip, flash programmer etc). Unfortunately coreboot is not supported on your MB. So try to find a solution on the net, how to update the microcode for your APU - this works with Intel processors even with kernel parameters (eg. ucode=scan in the Qubes cmdline is just enabling that functionality using the latest signed processor microcodes available in mainstream Linux distros) AFAIK, but success can dependend on your UEFI BIOS If I'm not mistaken, the latest microcode for A8-6600K is from March 2018 (https://github.com/platomav/CPUMicrocodes/blob/master/AMD/cpu00610F01_ver0600111F_2018-03-05_AC55EB96.bin) - but this have to be verified knowing your exact CPU infos. This microcode version already has all the needed mitigations for Spectre vulnerabilities, therefore strongly recommended... -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2f39f96a-3cf4-4427-8f78-d21ce2efadde%40googlegroups.com.
[qubes-users] Re: Help regarding IOMMU and HVM
The log file you provided as xl_log.txt is actually the Xen hypervisor log. Yes, there are some warnings - which show that there are some bugs in the BIOS, but overall, the virtualization and all the required features needed for IOMMU are there and enabled. So this is strange. Maybe - and I just now noticed - you use kernel version 5.x from kernel latest in sys-usb - that is still a development version, might not work. I'd switch that back to the stable 4.19.x version in the VM settings for sys-usb. Do you have logs for the stubdoms? (eg. dom0: /var/log/xen/console/guest-sys-usb-dm.log or similar log for sys-net). It might show what is wrong, as the stuboms provide the device model (emulated pci devices) needed for HVMs. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/c4720476-d9bd-47bb-a2d2-aa741fd763ec%40googlegroups.com.
[qubes-users] Re: Help regarding IOMMU and HVM
Hi. I tried everything you said (in both sys-usb and sys-net). I even tried to not assign any pass through devices and I still get the same output in /var/log/xen/console/guest-sys-net.log. But not assigning any device, or giving all devices strictreset as you mention gives me this output in /var/log/libvirt/libxl/libxl-driver.log: libxl_linux.c:155:libxl_loopdev_cleanup: unable to release device /dev/loop0: No such device or address I guess there are some errors in deeper level or my installation/BIOS is just bugged with IOMMU. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/11f7d05f-509f-4e2d-b4a2-6e533d22d393%40googlegroups.com.
[qubes-users] Re: Help regarding IOMMU and HVM
The libxl-driver.log shows symptoms, when indeed the USB device cannot be
reseted (FLR functionality missing).
As I wrote, you can disable strictreset for HVM passed through devices:
- go for the "Qube Settings" of one of the HVMs (sys-usb), where the USB
devices (PCI: 00:10.0, 00:10.1, 00:12.0, 00:13.0 in your case) are passed
through
- under tab "Devices", you should see in the right side box ("Selected")
all the USB device I noted above
- there is a horizontal bar in the bottom "Configure Strict Reset for PCI
Devices" --> push this, then a selection box comes up
- make sure you highlighted all visible devices by clicking on each
- then OK --> (Apply) --> OK
This should disable Strict Reset, and - if no other problems are there -
the HVM should start
One note: I also have and AMD based PC (laptop). For me, not all USB
devices should be passed through to sys-usb, because some of the devices
(eg. camera, wifi-card usb BT module and somehow the internal keyboard) are
internally connected to an USB port, and passing those through sys-usb qube
results sometimes in weird problems like not having WIFI or not being able
to type etc. So I only pass through one USB device, which I know don't
have any internal connections.
Lastly, you might need to experiment, which devices and ports would work
for you (passed through to eg. sys-usb), but make sure, that PCI devices
with multiple functions (00:10.0 and 00:10.1) are "moving" together either
way.
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/a7da7171-a225-4be4-b994-f5bfe8f56c68%40googlegroups.com.
[qubes-users] Re: Help regarding IOMMU and HVM
Dana utorak, 3. prosinca 2019. u 18:15:02 UTC, korisnik qubes123 napisao je: > > Maybe if you post the content of /var/log/libvirt/libxl/libxl-driver.log file > also, we can see what the problem is. Otherwise the logs seem OK for me. > If you installed a std R4.0.1 and let the setup configure the base qubes, > then sys-net should already be a HVM with all your Net cards passed through > to this HVM. > For USB devices, when passed to a HVM, it could require, that you set > "strict reset" in "Devices" tab for the USB devices of that qubes, > otherwise it will not boot. Because of this, I recommend to try to start a > hvm with only Net devices passed through to it, or even without any passed > devices to narrow down the problem to HVMs in general or passthrough issues. > One tip: if the HVMs problem still persists, change the Virt mode to PV > temporarily for the sys-net (make sure, that a Net card is passed to it), > and if networking is OK, then update dom0 to the latest version. > Then switch it back to HVM and try to boot. PV mode is not recommended > (larger attack surface) on long term, but R4.0.1 is and old version... > > Hi. I sure can! I uploaded the libxl-driver.log as well. As of your second part of the message, I didn't mention that after doing all the steps suggested in linked "Bug in libxenlight" topic I encountered that all assigned HVMs (bullet 8) wouldn't load (such as sys-usb and sys-net) and dom0 was updated before that change (bullet 7), and yes, now that I think of it, it gave me a different error and suggestion that I read the /var/log/libvirt/libxl/libxl-driver.log you asked for! So I hope you could tell me from it what's the matter. I then, changed back all the VMs to PV mode and I was setting up new templates, even got my USB WIFI dongle to work, but as you mentioned it's not as secure as HVM is so I really want to make it work -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/a3c4e8c6-c46d-4715-b231-bf091b212cdf%40googlegroups.com. 2019-12-02 12:34:30.798+: libxl: libxl.c:1853:libxl_console_get_tty: unable to read console tty path `/local/domain/1/console/tty': Resource temporarily unavailable 2019-12-02 12:36:10.284+: libxl: libxl.c:1853:libxl_console_get_tty: unable to read console tty path `/local/domain/2/console/tty': Resource temporarily unavailable 2019-12-02 12:39:29.948+: libxl: libxl.c:1853:libxl_console_get_tty: unable to read console tty path `/local/domain/4/console/tty': Resource temporarily unavailable 2019-12-02 12:47:27.881+: libxl: libxl_pci.c:1176:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device :00:13.0 2019-12-02 12:47:27.911+: libxl: libxl_pci.c:1176:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device :00:12.0 2019-12-02 12:47:27.938+: libxl: libxl_pci.c:1176:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device :00:10.0 2019-12-02 12:47:27.940+: libxl: libxl_pci.c:1176:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device :00:10.1 2019-12-02 13:09:07.331+: libxl: libxl_linux.c:155:libxl__loopdev_cleanup: unable to release device /dev/loop1: No such device or address 2019-12-02 13:10:30.867+: libxl: libxl_pci.c:1199:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device :00:13.0 2019-12-02 13:10:30.922+: libxl: libxl_pci.c:1517:do_pci_remove: xc_physdev_unmap_pirq irq=18: Invalid argument 2019-12-02 13:10:30.922+: libxl: libxl_pci.c:1199:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device :00:12.0 2019-12-02 13:10:30.934+: libxl: libxl_pci.c:1517:do_pci_remove: xc_physdev_unmap_pirq irq=17: Invalid argument 2019-12-02 13:10:30.971+: libxl: libxl_pci.c:1517:do_pci_remove: xc_physdev_unmap_pirq irq=18: Invalid argument 2019-12-02 13:10:30.971+: libxl: libxl_pci.c:1199:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device :00:10.0 2019-12-02 13:10:30.979+: libxl: libxl_pci.c:1517:do_pci_remove: xc_physdev_unmap_pirq irq=17: Invalid argument 2019-12-02 13:10:30.979+: libxl: libxl_pci.c:1199:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device :00:10.1 2019-12-02 13:10:38.678+: libxl: libxl_pci.c:1517:do_pci_remove: xc_physdev_unmap_pirq irq=83: Invalid argument 2019-12-02 13:10:38.678+: libxl: libxl_pci.c:1521:do_pci_remove: xc_domain_irq_permission irq=83: Operation not permitted 2019-12-02 13:11:24.859+: libxl: libxl_pci.c:1199:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI
[qubes-users] Re: Help regarding IOMMU and HVM
Hi. I sure can! I uploaded the libxl-driver.log as well. As of your second part of the message, I didn't mention that after doing all the steps suggested in linked "Bug in libxenlight" topic I encountered that all assigned HVMs (bullet 8) wouldn't load (such as sys-usb and sys-net) and dom0 was updated before that change (bullet 7), and yes, now that I think of it, it gave me a different error and suggestion that I read the /var/log/libvirt/libxl/libxl-driver.log you asked for! So I hope you could tell me from it what's the matter. I then, changed back all the VMs to PV mode and I was setting up new templates, even got my WIFI card to work, but as you mentioned it's not as secure as HVM is so I really want to make it work. Dana utorak, 3. prosinca 2019. u 18:15:02 UTC, korisnik qubes123 napisao je: > > Maybe if you post the content of /var/log/libvirt/libxl/libxl-driver.log file > also, we can see what the problem is. Otherwise the logs seem OK for me. > If you installed a std R4.0.1 and let the setup configure the base qubes, > then sys-net should already be a HVM with all your Net cards passed through > to this HVM. > For USB devices, when passed to a HVM, it could require, that you set > "strict reset" in "Devices" tab for the USB devices of that qubes, > otherwise it will not boot. Because of this, I recommend to try to start a > hvm with only Net devices passed through to it, or even without any passed > devices to narrow down the problem to HVMs in general or passthrough issues. > One tip: if the HVMs problem still persists, change the Virt mode to PV > temporarily for the sys-net (make sure, that a Net card is passed to it), > and if networking is OK, then update dom0 to the latest version. > Then switch it back to HVM and try to boot. PV mode is not recommended > (larger attack surface) on long term, but R4.0.1 is and old version... > > -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2b705f67-ecf0-465d-9fa2-201ebac60854%40googlegroups.com. 2019-12-02 12:34:30.798+: libxl: libxl.c:1853:libxl_console_get_tty: unable to read console tty path `/local/domain/1/console/tty': Resource temporarily unavailable 2019-12-02 12:36:10.284+: libxl: libxl.c:1853:libxl_console_get_tty: unable to read console tty path `/local/domain/2/console/tty': Resource temporarily unavailable 2019-12-02 12:39:29.948+: libxl: libxl.c:1853:libxl_console_get_tty: unable to read console tty path `/local/domain/4/console/tty': Resource temporarily unavailable 2019-12-02 12:47:27.881+: libxl: libxl_pci.c:1176:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device :00:13.0 2019-12-02 12:47:27.911+: libxl: libxl_pci.c:1176:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device :00:12.0 2019-12-02 12:47:27.938+: libxl: libxl_pci.c:1176:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device :00:10.0 2019-12-02 12:47:27.940+: libxl: libxl_pci.c:1176:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device :00:10.1 2019-12-02 13:09:07.331+: libxl: libxl_linux.c:155:libxl__loopdev_cleanup: unable to release device /dev/loop1: No such device or address 2019-12-02 13:10:30.867+: libxl: libxl_pci.c:1199:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device :00:13.0 2019-12-02 13:10:30.922+: libxl: libxl_pci.c:1517:do_pci_remove: xc_physdev_unmap_pirq irq=18: Invalid argument 2019-12-02 13:10:30.922+: libxl: libxl_pci.c:1199:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device :00:12.0 2019-12-02 13:10:30.934+: libxl: libxl_pci.c:1517:do_pci_remove: xc_physdev_unmap_pirq irq=17: Invalid argument 2019-12-02 13:10:30.971+: libxl: libxl_pci.c:1517:do_pci_remove: xc_physdev_unmap_pirq irq=18: Invalid argument 2019-12-02 13:10:30.971+: libxl: libxl_pci.c:1199:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device :00:10.0 2019-12-02 13:10:30.979+: libxl: libxl_pci.c:1517:do_pci_remove: xc_physdev_unmap_pirq irq=17: Invalid argument 2019-12-02 13:10:30.979+: libxl: libxl_pci.c:1199:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device :00:10.1 2019-12-02 13:10:38.678+: libxl: libxl_pci.c:1517:do_pci_remove: xc_physdev_unmap_pirq irq=83: Invalid argument 2019-12-02 13:10:38.678+: libxl: libxl_pci.c:1521:do_pci_remove: xc_domain_irq_permission irq=83: Operation not permitted 2019-12-02 13:11:24.859+: libxl: libxl_pci.c:1199:libxl__device_pci_reset: The kernel doesn't support reset from sysfs for PCI device
[qubes-users] Re: Help regarding IOMMU and HVM
...correction: R4.0.1 is not old (this is the current released version), but the iso build is from January... -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/9dcbdf09-0e11-4065-ae58-af26b4086da0%40googlegroups.com.
[qubes-users] Re: Help regarding IOMMU and HVM
Maybe if you post the content of /var/log/libvirt/libxl/libxl-driver.log file also, we can see what the problem is. Otherwise the logs seem OK for me. If you installed a std R4.0.1 and let the setup configure the base qubes, then sys-net should already be a HVM with all your Net cards passed through to this HVM. For USB devices, when passed to a HVM, it could require, that you set "strict reset" in "Devices" tab for the USB devices of that qubes, otherwise it will not boot. Because of this, I recommend to try to start a hvm with only Net devices passed through to it, or even without any passed devices to narrow down the problem to HVMs in general or passthrough issues. One tip: if the HVMs problem still persists, change the Virt mode to PV temporarily for the sys-net (make sure, that a Net card is passed to it), and if networking is OK, then update dom0 to the latest version. Then switch it back to HVM and try to boot. PV mode is not recommended (larger attack surface) on long term, but R4.0.1 is and old version... -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/f17635d6-dcc2-41be-be0f-218ecbe29881%40googlegroups.com.
