Re: [qubes-users] Hyperthreading is turned off by Qubes
'Ilpo Järvinen' via qubes-users wrote: > > Is it possible to get Xen in Qubes to enable hyperthreading? ... > > Are there any obvs pitfalls or technical issues to explain why Xen turns > > it off? > > Yes, HT is turned off intentionally for security purposes. Some of the > Intel CPU vulnerabilities demonstrated within the recent years depend on > the side channels within the resources shared by the threads of the same > physical core. Thus it's advisable to not enable it. Does that mean Intel's i7-9700 series of CPUs would be a near-ideal choice for a high-end Qubes desktop? Here's one of several available: https://ark.intel.com/content/www/us/en/ark/products/191792/intel-core-i7-9700-processor-12m-cache-up-to-4-70-ghz.html They're all 8 cores, no hyperthreading so 8 threads (enough?). This one runs at 3.0 Ghz, turbo 4.7, uses 65W. I've seen reports they can be overclocked to 5 GHz with air cooling. If I build one I'll use water cooling & see what I can get away with. -- 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/CACXcFm%3DOL5mE2o-cSPoGrgQS7f2N1%3DNA%2B4dVsbqQ6-CnD9NcAg%40mail.gmail.com.
Re: [qubes-users] sys-net interfaces
On Fri, Dec 27, 2019 at 08:46:35AM +, 'awokd' via qubes-users wrote: What responsibilties does sys-net have in terms of forwarding DNS? The documentation specifies how things work for AppVMs, and it says there is no DNS server in the "network driver domain" (sys-net), but it does not say what sys-net actually has to do. It looks like the documentation is assuming sys-net has many more virtual NICs than it actually does? Did you check the Qubes source code responsible for setting these up? The qubes-devel mailing list might also be appropriate here... The documentation mentions the vif-route-qubes utility, but I can't tell if dom0 runs this on sys-net (to set up routing to serve AppVMs) or runs it on AppVMs / etc ... the documentation does not mention any other source code (which would be used to e.g set up DNS forwarding). I will ask on qubes-devel. -- 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/20191228025332.GA1654%40danwin1210.me.
Re: [qubes-users] Hyperthreading is turned off by Qubes
On Fri, 27 Dec 2019, trueriver wrote: > Running a new install of Qubes r4.0.1 on an ultrabook based on the > m5-6Y54 processor / SOC. Xentop shows it as having only 2 cores. > > When the same machine boots into Debian on bare metal, with no BIOS > changes, top shows it as having four. > > The Intel spec is 2 cores running 4 threads, so the difference is > clearly about hyperthreading. > > Is it possible to get Xen in Qubes to enable hyperthreading? > > And if so how? There's smt xen command-line parameter. > Are there any obvs pitfalls or technical issues to explain why Xen turns > it off? Yes, HT is turned off intentionally for security purposes. Some of the Intel CPU vulnerabilities demonstrated within the recent years depend on the side channels within the resources shared by the threads of the same physical core. Thus it's advisable to not enable it. -- i. -- 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/alpine.DEB.2.20.1912272328150.22137%40whs-18.cs.helsinki.fi.
[qubes-users] Hyperthreading is turned off by Qubes
Running a new install of Qubes r4.0.1 on an ultrabook based on the m5-6Y54 processor / SOC. Xentop shows it as having only 2 cores. When the same machine boots into Debian on bare metal, with no BIOS changes, top shows it as having four. The Intel spec is 2 cores running 4 threads, so the difference is clearly about hyperthreading. Is it possible to get Xen in Qubes to enable hyperthreading? And if so how? Are there any obvs pitfalls or technical issues to explain why Xen turns it off? -- 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/9154098c-956b-45e2-b6ff-31ff2d956081%40googlegroups.com.
Re: [qubes-users] Syncing clock with ntp
On Fri, Dec 27, 2019 at 11:51:25AM -0800, John Maher wrote: > understanding is that the ClockVM, which is usually sys-net, runs ntp and > and communicates the time to dom0, which communicates the time to all of > the other VMs. actualy in qubes4 dom0+appvms "fetch" the time from clockvm, though appvms go through dom0 for that (qrpc acl plus an extra check that clockvm is running). (in qubes3 it used to be dom0 pulling from clockvm, then pushing to all appvms, which had the side-effect that a naughty appvm could block/stall the clocksync mechanism for all appvms) > I don't know how sys-net will get network time without ntp running. man systemd-timesyncd > Any suggestions on how to get my clock synced with network time? if your clock is off, check clockvm (sys-net) first, and make sure to get systemd-timesyncd.service working there. once clockvm has a reasonable time, it should filter down to "all" other VMs on its own over the next 6 hours or so. you can speed up the transfer from clockvm to all other vms by running "sudo qvm-sync-clock" in each vm you want to fetch time. note the current resolution for the sync mechanism is just "seconds", which even means it can cause the time to run "backwards" when triggered at the wrong moment. (i have a patchset somewhere to improve this to "low ms" precision, if anyone cares...) -- 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/20191227204633.GE17393%40priv-mua.
[qubes-users] Syncing clock with ntp
I have always had a problem with my system clock losing time. My understanding is that the ClockVM, which is usually sys-net, runs ntp and and communicates the time to dom0, which communicates the time to all of the other VMs. I don't know exactly what makes sys-net the ClockVM, but I noticed that it was not running the service clocksync (I noticed this service in sys-net of a different machine), so I added clocksync as a service to sys-net of the problem machine. I assumed ntp would be running on sys-net, but it was not. And when I checked the other system (which already had clocksync as a service), I see that it too does not have ntp running. I don't know how sys-net will get network time without ntp running. Any suggestions on how to get my clock synced with network time? Thanks. John -- 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/1432b667-3372-4d71-831c-f2b7cf376656%40googlegroups.com.
[qubes-users] Backup issues with external USB and ESATA devices
In late September I backed up qubes using a new WD Elements external drive. At the time I don't think I had sys-usb installed. Yesterday when I tried to do the backups I was unable to mount the WD Elements drive, another USB connected Toshiba hard drive, or the Toshiba drive connected with ESATA. I can mount USB flash drives, but with a vfat filesystem it will not support the large multi GB backup file. Booting Debian with the ESATA connected Toshiba drive I can mount the WD Elements drive without any problems. However I haven't figured out how to mount the SSD with Qubes OS lvm to copy the backup files. Does anyone have any suggestions? Thanks, Chuck -- 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/CAMet1z4TpcPB8CMgBd%2B0iDyavRFheDPk3x6mKg_AxYx_qz3SYQ%40mail.gmail.com.
Re: [qubes-users] Installer crash: IO-APIC + timer doesn't work (Dell XPS 7390)
On Friday, December 27, 2019 at 12:41:35 AM UTC-8, awokd wrote: > > See if you can turn off the HPET timer in your UEFI config, and include > that "apic_verbosity=debug" option. That might make more combinations > available to Xen and provide more detail. > I wasn't sure where to put the hpet=disable line, but my UEFI options line now looks like this: ``` options=console=vga loglvl=all efi=no-rs hpet=disable apic_verbosity=debug ``` And the boot output looks like this: ``` (XEN) [...] (XEN) CPU0: No irq handler for vector 40 (IRC -2147483648, LAPIC) (XEN) PCI: MCFG configuration 0: base e000 segment buses 00 - ff (XEN) PCI: Not using MCFG for segment bus 00-ff (XEN) Intel VT-d iommu 0 supported page sizes: 4kB, 2MB, 1GB. (XEN) Intel VT-d iommu 1 supported page sizes: 4kB, 2MB, 1GB. (XEN) Intel VT-d Snoop Control not enabled. (XEN) Intel VT-d Dom0 DMA Passthrough not enabled. (XEN) Intel VT-d Queued Invalidation enabled. (XEN) Intel VT-d Posted Interrupt not enabled. (XEN) Intel VT-d Shared EPT tables enabled. (XEN) I/O virtualization enabled. (XEN) - Dom0 mode: Relaxed (XEN) Interrupt remapping enabled (XEN) nr_sockets: 2 (XEN) Getting VERSION: 1060015 (XEN) Getting VERSION: 1060015 (XEN) Enabled directed EOI with ioapic_ack_old on! (XEN) Getting ID: 0 (XEN) Getting LVT0: 700 (XEN) Getting LVT1: 400 (XEN) Suppress EOI broadcast on CPU#0 (XEN) enabled ExtINT on CPU#0 (XEN) ENABLING IO_APIC IRQs (XEN) -> Using old ACK method (XEN) init IO_APIC IRQs (XEN) IO-APIC (apicid-pin) 2-0, 2-16, 2-17, 2-18, 2-19, 2-20, 2-21, 2-22, 2-23, 2-24, 2-25, [...], 2-115, 2-116, 2-117, 2-118, 2-119 not connected. (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1 (XEN) ..MP-BIOS bug: 8254 timer not connected to IO-APIC (XEN) ...trying to set up timer (IRQ0) through 8259A ,,, (XEN) ...trying to set up timer as Virtual Wire IRQ... failed. (XEN) ...trying to set up timer as ExtINT IRQ...spurious 8259A interrupt: IRQ7. (XEN) CPU0: no irq handler for vector e7 (IRQ -8) (XEN) IRQ7 a=0001[0001,] v=60[] t=IO-APIC-edge s=0002 (XEN) failed :(. (XEN) (XEN) *** (XEN) Panic on CPU 0: (XEN) IO-APIC + timer doesn't work! Boot with apic_verbosity=debug and send a report. Then try booting with the 'noapic' option (XEN) *** (XEN) (XEN) Reboot in five seconds... ``` Thanks! -- 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/3f7c1837-23aa-4549-8f76-d43e900111bf%40googlegroups.com.
Re: [qubes-users] Qubes/Xen doesn't comply with IOMMU grouping rules for PCI passthru
December 26, 2019 12:59 PM, "awokd' via qubes-users" wrote: > Claudia: > > TLDR; check bottom of https://community.amd.com/thread/241650, looks > like there was a recently released related updated. Not sure if > applicable to your situation. Thanks for the link! I'm not sure if it affects me or not. I did install a Dell BIOS update dated March 2019, so it sounds like that could have contained this Agesa update. So downgrading might fix the grouping issue, but this update also contained an "urgent" security update which I'd have to look into before downgrading. >> This caused a very sneaky problem on my machine. My USB controllers are in >> the same group as my >> GPU, sound card, and SATA controller. So when sys-usb (or >> rd.qubes.hide_all_usb) takes over those >> two USB controllers, everything stops working. [4] It was quite difficult to >> trace. It would have >> been much easier to diagnose if grouping was enforced somewhere. I would >> much rather have an error >> in my logs about being unable to assign USB controllers, than have my whole >> screen freeze up with >> no indication why. (I got lucky that it just crashed; if something >> interferes with your SATA >> controller's address space it can cause disk corruption. [5]) >> >> I don't really know who's at fault here. Qubes? Xen? AMD? Dell? > > The improper grouping is probably somewhere in AGESA, which is provided > to the manufacturers by AMD. It could be because of hardware related > limitations, which again are supplied by AMD. Sometimes vendors take > liberties (cost cutting measures) with both and break functionality, as > their primary/sole concern is that Windows boots. This can especially be > the case with consumer class machines such as Ryzen. Agree it would be > nice if Xen handled this failure mode more gracefully. Not sure there is > much Qubes can do here, though. On the other hand, my older AMD > (pre-Ryzen) consumer laptop running Coreboot has correct groupings. Yeah, my impression is the firmware can influence IOMMU grouping to an extent, within the bounds of the physical hardware. If this problem was indeed caused by an update then I assume it's (at least partly) firmware-related. According to that thread, a fix has been released for some boards/CPUs, "ComboPI", but the only feedback I can find on it is for Ryzen 3000-series which doesn't help me. Also I don't even know if or when my machine will receive a BIOS update with this Agesa fix. I sort of blame Xen for not enforcing IOMMU grouping, especially considering that it hides that info from the OS. KVM does enforce IOMMU grouping rules, so I don't see why Xen wouldn't. Xen leaves it up to the user software to be careful what it passes where, but that's kind of hard when you don't have /sys/kernel/iommu_groups for a hint. >> Intel systems >> seem to just to have better grouping usually (or, are less likely to crash >> when grouping rules are >> violated). [6] > > I think that is overbroad. There are plenty of Intel systems with broken > passthrough. iommu=no-igfx itself is a workaround for broken passthrough > of Intel graphics. There are also plenty of AMD systems with properly > implemented passthrough. Very possible. I don't have experience with a lot of other hardware, so I'm just going by what I've heard. It definitely seems to be a Ryzen problem at least, maybe not AMD in general. I just seemed to come across a lot more complaints about AMD than Intel, though. It would be nice if the HCL contained more detailed information about the IOMMU such as grouping, so we could get a better idea. At any rate, that's the least of my worries. TBH I don't really understand what no-igfx does, so I don't know if an AMD-equivalent option would help in this case or not. It's just worth noting that it's an Intel-specific fix which could improve Intel compatibility compared to AMD generally. >> Thoughts? Is there anything Qubes can do to do avoid splitting up IOMMU >> groups? Is there anything >> Qubes *should* do? Should Qubes attempt to guess the IOMMU groups before >> taking over devices? >> Should the USB Qube option be disabled on AMD systems (you can still >> manually set up sys-usb of >> course)? Should we just blame Xen for not enforcing IOMMU groups in the >> first place? > > Ultimately, it's a hardware/firmware issue. Threadripper and Epyc based > AMD systems ought to be more thoroughly vetted to support passthrough. > My suggestions are to disable automatic IOMMU grouping in your UEFI > configuration, if possible. Otherwise, try a newer firmware version with > updated AGESA code and see if it helps, or possibly add a card with > additional USB controllers as that should appear in its own group. There is no way to enable or disable automatic IOMMU grouping in my bios. The only options are IOMMU enabled or disabled, as far as I can tell. There is no newer firmware for this machine at this time. Not sure about microcode, though. This i
Re: [qubes-users] Ghost in the machine?
Thank you very much Awokd, below the answers in bold Sent with ProtonMail Secure Email.‐‐‐ Original Message ‐‐‐ On Friday, December 27, 2019 8:30 AM, 'awokd' via qubes-users qubes-users@googlegroups.com wrote: > 'Chökie Gyaltsen' via qubes-users: > > > Thank you very much for your answers, my replies in bold below. > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > > On Thursday, December 26, 2019 2:03 PM, 'awokd' via qubes-users > > qubes-users@googlegroups.com wrote: > > > > > 'Chökie Gyaltsen' via qubes-users: > > > I included the -b option on journalctl and the same message with 'uinput' > > module not being loaded and zenstored not found and being rebuiild showed > > up on today's boot. > > The 'uinput' one is the only odd message, since I'm not seeing it on > mine. I'll try a fresh install of 4.0.2rc3 sometime and see. Maybe it > gets loaded later in the boot sequence than in 4.0.1, since you've > determined it shows up anyways. Ignore xenstored, that always happens. OK perfect, thank you for your help. > > > > All the errors are still happening since install. I am sorry to insist, > > > > but the 'uinput' error is the one that worries me more, pardon my > > > > ignorance and thus the question: > > > > How can i check the signature of the module loaded? Is it possible? > > You should be able to find SHA256 sums somewhere of that module (make > sure the version exactly matches yours). This is fine for a quick check. Great! > 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/74a2cb28-57f0-8a2f-1e0f-5a74e8879e87%40danwin1210.me. -- 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/zZunP1rN9JEzgJjPGnxoX0bgteLwN1kfABMUCy4REEhJ7VopW6waAJXnet0LAZY2YUZCEuKwuVu5ic4H9uFeZ4c3MezhgYTtfGZZXPKgOYk%3D%40pm.me. publickey - bodhisattvayana@pm.me - 0xEC5E8A90.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
[qubes-users] No HDMI on lenovo laptop
Hallo Dane Would you be so kind and explain how did you manage to boot with your laptop. I have exactly the same model. Nvidia 1650 6gb. I tried to install qubes many time but same problem over and over. Black screen after install. Whats about GPU pass? Can you play any Steam game? Wrong section to ask, but I do not know how to send PM. Can you make some totorial? Few command lines, or so. Thank you. tnx -- 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/6d12d021-7be3-4219-b3ee-14eb25db5a68%40googlegroups.com.
Re: [qubes-users] HOWTO: Enable screen poweroff (instead of blanking)
December 27, 2019 11:32 AM, dhorf-hfref.4a288...@hashmail.org wrote: > On Sun, Dec 22, 2019 at 02:45:34PM +, Claudia wrote: > >> overrides the XFCE Power Manager settings. Xscreensaver is only >> configured to blank the screen; I'm not sure if it even supports >> powering it off. To return control to XFCE, go to Menu > System Tools > > it does, and it works (for me). > > check "grep dpms .xscreensaver" and edit. > or use "xscreensaver-demo" to adjust in a clicky way. Thanks for adding that. Personally I don't want or need the lockscreen so for me it made more sense just to disable Xscreensaver altogether. Good to know you can have lockscreen and blanking at the same time though :) -- 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/3e176ea5f45d5c34d747b5c4990d0c9d%40disroot.org.
Re: [qubes-users] Re: Qubes/Xen doesn't comply with IOMMU grouping rules for PCI passthru
December 27, 2019 11:37 AM, "John Mitchell" wrote: > "This can especially be the case with consumer class machines such as Ryzen." > I had to lol about this since I have had many Intel systems with one problem > or another and this is > certainly not isolated to Ryzen. I am also running a Ryzen system running > three VMs with > PCI-passthrough on one of the VMs with no problems. I do not know if my > motherboard is consumer > grade (ASrock) however it does rock. ;) > It's not passthru in general, it's passthru of specific devices, in this case USB controllers. My network devices passthru just fine because they're in their own groups. Since you said "PCI-passthrough on one of the VMs" I'm assuming you're talking about sys-net, and that you're not using a USB Qube (which would make it two VMs). And just because passthru doesn't work on one (Intel) system or another doesn't necessarily mean it's because of IOMMU grouping. There are plenty of different reasons it could break. In any case, yeah, I'm sure Intel systems have their problems too. I just happened to come across a lot of complaints about IOMMU grouping on AMD, especially Ryzen. But my main point was about Xen and Qubes with regards to IOMMU grouping. The AMD-vs-Intel matter is the least of my concerns. -- 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/3b7081f22268b304d5f056efa2a82d68%40disroot.org.
[qubes-users] Re: Qubes/Xen doesn't comply with IOMMU grouping rules for PCI passthru
"This can especially be the case with consumer class machines such as Ryzen." I had to lol about this since I have had many Intel systems with one problem or another and this is certainly not isolated to Ryzen. I am also running a Ryzen system running three VMs with PCI-passthrough on one of the VMs with no problems. I do not know if my motherboard is consumer grade (ASrock) however it does rock. ;) On Sunday, December 22, 2019 at 8:32:23 PM UTC+1, Claudia wrote: > > I'm very new to all this iommu stuff, but as I understand it, devices in > the same iommu group are > supposed to be treated as a single unit, meaning if any of them are > assigned to a VM then they all > must be assigned to the same VM. This is because those devices cannot be > isolated from each other > -- they can communicate directly without going through the IOMMU at all, > for example. > > This not only creates obvious security holes, but can also cause > compatibility problems. For > example, devices in different VMs will have different perspectives of > system memory. [3] Or > something like that. Like I said, I'm still trying to wrap my head around > it. > > Point is, the entire group is supposed to be treated as a single unit. > Linux/KVM enforces this, Xen > does not, I'm not sure about any other platforms. [1] > > This caused a very sneaky problem on my machine. My USB controllers are in > the same group as my > GPU, sound card, and SATA controller. So when sys-usb (or > rd.qubes.hide_all_usb) takes over those > two USB controllers, everything stops working. [4] It was quite difficult > to trace. It would have > been much easier to diagnose if grouping was enforced somewhere. I would > much rather have an error > in my logs about being unable to assign USB controllers, than have my > whole screen freeze up with > no indication why. (I got lucky that it just crashed; if something > interferes with your SATA > controller's address space it can cause disk corruption. [5]) > > I don't really know who's at fault here. Qubes? Xen? AMD? Dell? > > Unfortunately, Qubes has no way of knowing anything about iommu grouping > because Xen takes over the > IOMMU (and therefore grouping is not visible in dom0). [2] So probably the > only way Qubes could > enforce grouping is by some kind of heuristic. For example, assume all > functions of a device are > grouped. Or, assume all devices on a hub are grouped. Or just disable the > USB Qube option on AMD > systems entirely, or warn the user that it may cause serious problems that > are hard to diagnose. > > As for fixing the actual problem, that is, grouping them in a more > sensible way so that the GPU and > USB controllers can be isolated for example, can only be done in a > firmware (or microcode?) update > by the vendor, if at all. There are some hacks for KVM to spoof the > grouping restrictions (which > Xen doesn't enforce in the first place), but they don't solve the > underlying problem. VFIO seems > like it could work (by emulating some IOMMU functionality in software), > but I don't know if it's > supported by Xen. > > I'm guessing part of the reason this problem doesn't usually come up on > Intel systems is because of > the Xen option iommu=no-igfx. This means that the integrated GPU is always > exempt from IOMMU > control altogether, but this option is Intel-specific and has no AMD > equivalent. However, that > doesn't do anything about other devices such as sound cards or SATA > controllers. Intel systems > seem to just to have better grouping usually (or, are less likely to crash > when grouping rules are > violated). [6] > > At least that's my understanding so far. > > Thoughts? Is there anything Qubes can do to do avoid splitting up IOMMU > groups? Is there anything > Qubes *should* do? Should Qubes attempt to guess the IOMMU groups before > taking over devices? > Should the USB Qube option be disabled on AMD systems (you can still > manually set up sys-usb of > course)? Should we just blame Xen for not enforcing IOMMU groups in the > first place? > > [1] https://lists.gt.net/xen/devel/345279#345279 > [2] > http://xen.1045712.n5.nabble.com/IOMMU-group-dissapear-in-XEN-td5737357.html > [3] https://vfio.blogspot.com/2014/08/iommu-groups-inside-and-out.html > [4] > https://www.mail-archive.com/qubes-users@googlegroups.com/msg31494.html > [5] > http://xen.1045712.n5.nabble.com/VGA-passthrough-with-USB-passthrough-td5738340.html > [6] > https://hardforum.com/threads/ryzen-and-iommu-groups-is-this-ever-going-to-get-fixed.1944064 > > --- > > Dell Inspiron 5575, AMD Ryzen 5 2500U, Qubes R4.1 booted without Xen: > > # lspci > 00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Root > Complex > 00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 IOMMU > 00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models > 00h-1fh) PCIe Dummy Host > Bridge > 00:01.6 PCI bridge: Advanced Micro Devices, Inc
Re: [qubes-users] HOWTO: Enable screen poweroff (instead of blanking)
On Sun, Dec 22, 2019 at 02:45:34PM +, Claudia wrote: > overrides the XFCE Power Manager settings. Xscreensaver is only > configured to blank the screen; I'm not sure if it even supports > powering it off. To return control to XFCE, go to Menu > System Tools it does, and it works (for me). check "grep dpms .xscreensaver" and edit. or use "xscreensaver-demo" to adjust in a clicky 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/20191227113224.GD17393%40priv-mua.
Re: [qubes-users] how to install or use pm-suspend similar command on Qubes
December 27, 2019 8:35 AM, "awokd' via qubes-users" wrote: > Guerlan: > >> I'm following https://wiki.ubuntu.com/DebuggingKernelSuspend to debug >> kernel suspend problems. However, on dom0 there's no pm-suspend command. >> >> How can I install SECURELY this command or how to substitute for another >> one? >> >> This is the command: >> >> sudo sh -c "sync && echo 1 > /sys/power/pm_trace && pm-suspend" >> >> Which command does xfce use when I click the suspend button? > > Try systemctl suspend. If that doesn't work, there's also `echo mem > /sys/power/state` https://www.kernel.org/doc/Documentation/power/s2ram.txt -- 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/170955a3fb8a673f96436a7fb7d33252%40disroot.org.
Re: [qubes-users] Troubleshooting Qubes graphical slowness
On Fri, Dec 27, 2019 at 09:57:16AM +0100, tetrahedra via qubes-users wrote: Unfortunately I need to get work done so have to reboot to "just make it go away" but I am still interested in troubleshooting ideas (for when it happens next). One thing I noticed on reboot -- the initial round of stop jobs (when shutting down the system, things like unmounting LUKS volumes) all timed out. Not sure if related. -- 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/20191227091041.GA1085%40danwin1210.me.
Re: [qubes-users] Troubleshooting Qubes graphical slowness
On Fri, Dec 27, 2019 at 08:49:02AM +, 'awokd' via qubes-users wrote: Further inspection shows there's a LOT of disk I/O going on. after installing iotop in dom0, this appears to be coming from command [NN.xvda-0], presumably one of the VMs. How do I map the NN (number) to a given running VM? Check xl top. I think you can find the offending VM with that. You might be running out of system RAM too, which would be shown at the top. xl top / xentop doesn't show any two-digit number identifying a VM. However by trial and error it looks like the extreme levels of disk I/O are a symptom rather than a cause. After shutting down all slowed-down VMs the disk I/O ended. Then when I re-started a DispVM with Firefox, the high levels of disk I/O (constant read > 50MB/sec) came back and Firefox was slow (as before). Unfortunately I need to get work done so have to reboot to "just make it go away" but I am still interested in troubleshooting ideas (for when it happens next). -- 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/20191227085716.GA2170%40danwin1210.me.
Re: [qubes-users] Troubleshooting Qubes graphical slowness
tetrahedra via qubes-users: > On Fri, Dec 27, 2019 at 09:05:52AM +0100, tetrahedra via qubes-users wrote: >> On Fri, Dec 27, 2019 at 08:33:10AM +0100, tetrahedra via qubes-users >> wrote: >>> Periodically all graphics-heavy apps (Firefox, ...) in all VMs seem to >>> slow down simultaneously. Rebooting fixes the situation. Running `sudo >>> journalctl -f` in dom0 doesn't show anything unusual. What would you >>> suggest as a next step towards locating the problem? >> >> vim also appears to be affected by the slowdown. > > Further inspection shows there's a LOT of disk I/O going on. > > after installing iotop in dom0, this appears to be coming from command > [NN.xvda-0], presumably one of the VMs. How do I map the NN (number) to > a given running VM? > Check xl top. I think you can find the offending VM with that. You might be running out of system RAM too, which would be shown at the top. -- - 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/57f3a71e-09f4-4998-6eb3-87f8e4407faa%40danwin1210.me.
Re: [qubes-users] sys-net interfaces
tetrahedra via qubes-users: > On Thu, Dec 26, 2019 at 11:47:37AM +, 'awokd' via qubes-users wrote: >> There's a brief discussion at https://www.qubes-os.org/doc/networking/, >> but there may be more detailed notes in the source code for Qubes' VM >> networking components. Qubes uses Xen's networking, so that might be the >> best place to begin research. > > What responsibilties does sys-net have in terms of forwarding DNS? The > documentation specifies how things work for AppVMs, and it says there is > no DNS server in the "network driver domain" (sys-net), but it does not > say what sys-net actually has to do. > > Also, the docs don't appear to be entirely accurate. The documentation > specifies a fairly complex set of routing tabels for the "network driver > domain" (sys-net, I assume), but the actual routing table on my sys-net > is fairly simple > > The table from the documentation: > Destination Gateway Genmask Flags Metric Ref > Use Iface > 10.137.0.16 0.0.0.0 255.255.255.255 UH 0 0 0 > vif4.0 > 10.137.0.7 0.0.0.0 255.255.255.255 UH 0 0 0 > vif10.0 > 10.137.0.9 0.0.0.0 255.255.255.255 UH 0 > [... many lines removed ...] > 192.168.0.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0 > 0.0.0.0 192.168.0.1 0.0.0.0 UG 0 0 0 eth0 > > The table from my sys-net: > [user@sys-net ~]$ sudo ip route > [user@sys-net ~]$ sudo route > Kernel IP routing table > Destination Gateway Genmask Flags Metric Ref Use > Iface > default _gateway 0.0.0.0 UG 600 0 0 > wls7 > 10.137.0.5 0.0.0.0 255.255.255.255 UH 32747 0 0 > vif5.0 > 192.168.0.0 0.0.0.0 255.255.255.0 U 600 0 0 > wls7 > > > It looks like the documentation is assuming sys-net has many more > virtual NICs than it actually does? > Did you check the Qubes source code responsible for setting these up? The qubes-devel mailing list might also be appropriate here... -- - 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/04a3284a-b538-4e60-c059-3c5a9336d410%40danwin1210.me.
Re: [qubes-users] Installer crash: IO-APIC + timer doesn't work (Dell XPS 7390)
Aaron Janse: > On Thursday, December 26, 2019 at 5:31:50 AM UTC-8, awokd wrote: > >> What happens if you use an options line like the following? >> >> options=console=vga loglvl=all efi=no-rs >> > > ``` > (XEN) Platform timer is 23.999MHz HPET > (XEN) [...] > (XEN) CPU0: No irq handler for vector 40 (IRC -2147483648, LAPIC) > (XEN) PCI: MCFG configuration 0: base e000 segment buses 00 - ff > (XEN) PCI: Not using MCFG for segment bus 00-ff > (XEN) [...] > (XEN) Interrupt remapping enabled > (XEN) nr_sockets: 2 > (XEN) Enabled directed EOI with ioapic_ack_old on! > (XEN) ENABLING IO_APIC IRQs > (XEN) -> Using old ACK method > (XEN) ..TIMER: vector=0xF0 apic1=0 pin1=2 apic2=-1 pin2=-1 > (XEN) ..MP-BIOS bug: 8254 timer not connected to IO-APIC > (XEN) ...trying to set up timer (IRQ0) through 8259A ,,, > (XEN) ...trying to set up timer as Virtual Wire IRQ... failed. > (XEN) ...trying to set up timer as ExtINT IRQ...spurious 8259A interrupt: > IRQ7. > (XEN) CPU0: no irq handler for vector e7 (IRQ -8) > (XEN) IRQ7 a=0001[0001,] v=60[] t=IO-APIC-edge s=0002 > (XEN) failed :(. > (XEN) > (XEN) *** > (XEN) Panic on CPU 0: > (XEN) IO-APIC + timer doesn't work! Boot with apic_verbosity=debug and send > a report. Then try booting with the 'noapic' option > (XEN) *** > (XEN) > (XEN) Reboot in five seconds... > ``` > > I've been transcribing these logs by hand, otherwise I'd include more. > > I also suspect that maybe these issues could be solved by using a newer > kernel for the installer? > > My understanding is that R4.1 will soon feature a 5.4.x kernel [1]. Are > there more things to try in the meantime? > > Thanks! > > [1] > https://github.com/QubesOS/qubes-issues/issues/5539#issuecomment-568863280 > See if you can turn off the HPET timer in your UEFI config, and include that "apic_verbosity=debug" option. That might make more combinations available to Xen and provide more detail. The messages are coming from Xen before it even loads the Linux kernel, but yes- a newer version of Xen such as in R4.1 might also help. If you have a serial port available, you can set Xen to log to it, but that is often a hassle with newer machines. -- - 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/30633bde-8a77-2d85-7585-349a014cb22c%40danwin1210.me.
Re: [qubes-users] how to install or use pm-suspend similar command on Qubes
Guerlan: > I'm following https://wiki.ubuntu.com/DebuggingKernelSuspend to debug > kernel suspend problems. However, on dom0 there's no pm-suspend command. > > How can I install SECURELY this command or how to substitute for another > one? > > This is the command: > > sudo sh -c "sync && echo 1 > /sys/power/pm_trace && pm-suspend" > > Which command does xfce use when I click the suspend button? > Try systemctl suspend. -- - 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/4198eb84-1bdd-5afd-c270-8de43c9bcd33%40danwin1210.me.
Re: [qubes-users] Troubleshooting Qubes graphical slowness
On Fri, Dec 27, 2019 at 09:05:52AM +0100, tetrahedra via qubes-users wrote: On Fri, Dec 27, 2019 at 08:33:10AM +0100, tetrahedra via qubes-users wrote: Periodically all graphics-heavy apps (Firefox, ...) in all VMs seem to slow down simultaneously. Rebooting fixes the situation. Running `sudo journalctl -f` in dom0 doesn't show anything unusual. What would you suggest as a next step towards locating the problem? vim also appears to be affected by the slowdown. Further inspection shows there's a LOT of disk I/O going on. after installing iotop in dom0, this appears to be coming from command [NN.xvda-0], presumably one of the VMs. How do I map the NN (number) to a given running VM? -- 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/20191227083340.GA1952%40danwin1210.me.
Re: [qubes-users] Ghost in the machine?
'Chökie Gyaltsen' via qubes-users: > Thank you very much for your answers, my replies in bold below. > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Thursday, December 26, 2019 2:03 PM, 'awokd' via qubes-users > qubes-users@googlegroups.com wrote: > >> 'Chökie Gyaltsen' via qubes-users: > > I included the -b option on journalctl and the same message with 'uinput' > module not being loaded and zenstored not found and being rebuiild showed up > on today's boot. The 'uinput' one is the only odd message, since I'm not seeing it on mine. I'll try a fresh install of 4.0.2rc3 sometime and see. Maybe it gets loaded later in the boot sequence than in 4.0.1, since you've determined it shows up anyways. Ignore xenstored, that always happens. >>> All the errors are still happening since install. I am sorry to insist, but >>> the 'uinput' error is the one that worries me more, pardon my ignorance and >>> thus the question: >>> How can i check the signature of the module loaded? Is it possible? You should be able to find SHA256 sums somewhere of that module (make sure the version exactly matches yours). This is fine for a quick check. -- 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/74a2cb28-57f0-8a2f-1e0f-5a74e8879e87%40danwin1210.me.
Re: [qubes-users] Troubleshooting Qubes graphical slowness
On Fri, Dec 27, 2019 at 08:33:10AM +0100, tetrahedra via qubes-users wrote: Periodically all graphics-heavy apps (Firefox, ...) in all VMs seem to slow down simultaneously. Rebooting fixes the situation. Running `sudo journalctl -f` in dom0 doesn't show anything unusual. What would you suggest as a next step towards locating the problem? vim also appears to be affected by the slowdown. -- 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/20191227080552.GA1906%40danwin1210.me.
