[qubes-users] Re: Qubes installing issue

2020-01-16 Thread Ana Z
Hi,

Similar issue here, although long ago: 
https://groups.google.com/forum/m/#!topic/qubes-users/jBiBtUXgwzs

You should try both UEFI and Legacy mode.

-- 
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/256885d1-834a-4cfa-b070-b34176055b88%40googlegroups.com.


Re: [qubes-users] PCI passthrough issues

2020-01-15 Thread Ana Z
Hi awokd,

I tried both combinations beforehand, neither of them helped.

I'm not really sure whether I've added xen-pciback.hide to the right place, 
but I added it to the */etc/default/grub under *GRUB_CMDLINE_XEN_DEFAULT 
and commit the change. If that's the thing I should've done, sadly, it 
still doesn't work.

Dana srijeda, 15. siječnja 2020. u 19:36:28 UTC, korisnik awokd napisao je:
>
> Ana Z: 
> > Hi, 
> > 
> > I tried to passthrough my old PCI USB controller (chipset NEC 
> 0720100AGM) 
> > to Windows 7 HVM but I ran into some problems. 
>
> > dom0:01_05.0  USB controller: NEC Corporation OHCI USB 
> > Controller 
> > win7-z (permissive=true, no-strict-reset=true) 
> > dom0:01_05.1  USB controller: NEC Corporation OHCI USB 
> > Controller 
> > win7-z (permissive=true, no-strict-reset=true) 
> > dom0:01_05.2  USB controller: NEC Corporation uPD72010x USB 2.0 
> > Controller win7-z 
> > (permissive=true, no-strict-reset=true) 
>
> If you haven't, try attaching these with one or both options set to 
> false. If it still doesn't help, see if 
> xen-pciback.hide=(01:05.0)(01:05.1)(01:05.2) in xen.cfg helps. 
>
> -- 
> - don't top post 
> Mailing list etiquette: 
> - trim quoted reply to only relevant portions 
> - when possible, copy and paste text instead of screenshots 
>

-- 
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/291f5e41-0b03-4a6a-bfec-92a461796991%40googlegroups.com.


[qubes-users] PCI passthrough issues

2020-01-15 Thread Ana Z
Hi,

I tried to passthrough my old PCI USB controller (chipset NEC 0720100AGM) 
to Windows 7 HVM but I ran into some problems. 

I first found the controller in dom0 with *qvm-pci*:

dom0:01_05.0  USB controller: NEC Corporation OHCI USB 
Controller 
dom0:01_05.1  USB controller: NEC Corporation OHCI USB 
Controller 
dom0:01_05.2  USB controller: NEC Corporation uPD72010x USB 2.0 Controller

I then attached those three with *qvm-pci attach --persistent --option 
permissive=true --option no-strict-reset=true   *and 
I got:

dom0:01_05.0  USB controller: NEC Corporation OHCI USB 
Controller 
win7-z (permissive=true, no-strict-reset=true)
dom0:01_05.1  USB controller: NEC Corporation OHCI USB 
Controller 
win7-z (permissive=true, no-strict-reset=true)
dom0:01_05.2  USB controller: NEC Corporation uPD72010x USB 2.0 
Controller win7-z 
(permissive=true, no-strict-reset=true)

I tried running the Windows 7 HVM and the PCI USB controller was 
recognized, alongside USB Root Hubs, but whenever I physically attach an 
USB device (3 different sticks and 1 WLAN stick) I always get "USB Device 
Not Recognized" and "Unknown USB Device" in one of the used ports.

Before I attached the controller to Windows HVM, dom0 recognized any device 
attached to the controller, and I tried booting up my spare disk with the 
same Windows 7 installation I used for HVM and the PCI controller works 
there, with recognized USB devices when attached.

My question is, what is the next step I should make in troubleshooting the 
problem?

-- 
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/7587670e-d33a-4d30-a7cb-0709091de4c1%40googlegroups.com.


[qubes-users] Re: Help regarding IOMMU and HVM

2019-12-09 Thread Ana Z
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

2019-12-05 Thread Ana Z
!!!

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

2019-12-04 Thread Ana Z
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

2019-12-03 Thread Ana Z
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

2019-12-03 Thread Ana Z
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] Help regarding IOMMU and HVM

2019-12-03 Thread Ana Z
Hi. 

First of all, I want to mention that I'm not really experienced with Linux 
or Xen but I tried my best for the past 3 days to make my Qubes 
installation work. I need help with enabling hardware-assisted virtual 
machines. 

I was trying to install Qubes 4.0.1 but I ran into some issues. While 
installing, I was first greeted with "Missing features: IOMMU/VT-d/AMD-Vi, 
Interrupt Remapping. Without these feature, Qubes OS will not function 
normally.". I checked my BIOS and IOMMU was enabled (motherboard is ASUS 
A88XM-A), but my BIOS version was old. I updated the BIOS to the latest 
version and the error from the installation disappeared, but then, after 
the install, on setup I got another message saying:

[“/usr/bin/qvm-start’,’sys-firewall’] failed:
stdout: ""
stderr: “Start failed: internal error: libxenlight failed to create new 
domain ‘sys-
firewall’, see /var/log/libvirt/libxl/libxl-driver.log for details
""

I searched qubes-users for help and I came across this post: Bug in 
libxenlight 


This indeed helped me finish the setup without errors, but all of my qubes 
are paravirtualized and when I try to change, for example, my sys-usb to 
HVM I get a timeout error and that I should check 
/var/log/xen/console/quest-sys-usb.log. I have searched for some 
explanation online but to no avail. I've put all the important logs (I 
hope) in attachments and I'd appreciate if someone could help me.

Ana.




-- 
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/4b63dfb3-a3d1-4f49-9c00-b2ef5200acab%40googlegroups.com.
[0.00] Linux version 4.19.86-1.pvops.qubes.x86_64 (user@build-fedora4) 
(gcc version 6.4.1 20170727 (Red Hat 6.4.1-1) (GCC)) #1 SMP Sun Dec 1 07:16:00 
UTC 2019
[0.00] Command line: placeholder root=/dev/mapper/qubes_dom0-root ro 
rd.luks.uuid=luks-5e749bff-cae3-42f8-ac78-83cabe591c1d 
rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap i915.alpha_support=1 rhgb 
quiet plymouth.ignore-serial-consoles
[0.00] random: get_random_u32 called from bsp_init_amd+0x23f/0x2f0 with 
crng_init=0
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, 
using 'standard' format.
[0.00] Released 0 page(s)
[0.00] BIOS-provided physical RAM map:
[0.00] Xen: [mem 0x-0x0009dfff] usable
[0.00] Xen: [mem 0x0009e800-0x000f] reserved
[0.00] Xen: [mem 0x0010-0xad1c] usable
[0.00] Xen: [mem 0xad1d-0xad1f] reserved
[0.00] Xen: [mem 0xad20-0xad21bfff] ACPI data
[0.00] Xen: [mem 0xad21c000-0xad755fff] ACPI NVS
[0.00] Xen: [mem 0xad756000-0xae3aefff] reserved
[0.00] Xen: [mem 0xae3af000-0xae3a] usable
[0.00] Xen: [mem 0xae3b-0xae5b5fff] ACPI NVS
[0.00] Xen: [mem 0xae5b6000-0xae9f2fff] usable
[0.00] Xen: [mem 0xae9f3000-0xaeff3fff] reserved
[0.00] Xen: [mem 0xaeff4000-0xaeff] usable
[0.00] Xen: [mem 0xf800-0xfbff] reserved
[0.00] Xen: [mem 0xfeb8-0xfec00fff] reserved
[0.00] Xen: [mem 0xfec1-0xfec10fff] reserved
[0.00] Xen: [mem 0xfed0-0xfed00fff] reserved
[0.00] Xen: [mem 0xfed8-0xfed8] reserved
[0.00] Xen: [mem 0xfee0-0xfeef] reserved
[0.00] Xen: [mem 0xff00-0x] reserved
[0.00] Xen: [mem 0x0001-0x000152a47fff] usable
[0.00] Xen: [mem 0x00fd-0x00ff] reserved
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.7 present.
[0.00] DMI: System manufacturer System Product Name/A88XM-A, BIOS 3001 
03/09/2016
[0.00] Hypervisor detected: Xen PV
[0.024260] tsc: Fast TSC calibration using PIT
[0.024262] tsc: Detected 4499.980 MHz processor
[0.024262] tsc: Detected 4500.036 MHz TSC
[0.030855] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.030857] e820: remove [mem 0x000a-0x000f] usable
[0.030864] last_pfn = 0x152a48 max_arch_pfn = 0x4
[0.030865]