date:20191230

Re: [qubes-users] Troubleshooting Qubes graphical slowness

2019-12-30 Thread Steve Coleman

On 2019-12-30 11:28, Steve Coleman wrote:

On 2019-12-29 23:32, tetrahedra via qubes-users wrote:

On Sun, Dec 29, 2019 at 01:44:28PM +, 'awokd' via qubes-users wrote:

tetrahedra via qubes-users:
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).

Investigate xl top more thoroughly. You can identify offending VMs with
it, and see if all your RAM is in use which triggers swapping to (slow)
disk.

My disk is a pretty fast SSD, and I did use xentop (`xl top` is just an
alias for xentop) and it didn't show anything unusual as far as I can
recall. Perusing the xentop man page doesn't show any potentially
relevant options except for `--full-name` and that option doesn't seem
to do anything. Pressing "B" (for "vBds") seems to list a number of
devices for each VM but none of them have any 2-digit unique identifying
number (as `iotop` seems to display).

I have had graphics slowdown issues in the past on two occasions that
acted like this, so here are some things to try:

1) Add the 'nopat' argument to the 'kernel opts:' boot command line.

> qvm-prefs -s kernelopts nopat

2) The second, I can not seem to locate that email exchange at the
moment, but it was a option on the graphics subsystem that needed to be
turned off. Something like backing store, but I'm sure that is not the
correct name for it. I'll keep looking for that one until I hear back if
#1 above fixed your problem or not.

Ok, I still could not find that email exchange, but the second thing to
try is in the XFCE "Window Manager Tweaks" Compositor tab, and try to
disable the "Enable display compositing" entry.

Let us know if either if these works for you. Both worked for me for
their respective graphics performance issue.

Steve

--
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/83a5e759-1ba7-999d-adb9-ccdfe1453cad%40jhuapl.edu.

Re: [qubes-users] Re: HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics

2019-12-30 Thread brendan . hoar

On Monday, December 30, 2019 at 1:44:13 PM UTC-5, qubes123 wrote:
>
> Answering to your earlier question, my CPU capability information bits 
> change like this after suspend:
>
> (XEN) Entering ACPI S3 state.
> (XEN) AMD-Vi: Applying erratum 746 workaround for IOMMU at :00:00.2
> (XEN) Finishing wakeup from ACPI S3 state.
> (XEN) CPU0: cap[ 1] is 3e98320b (expected b698320b)
> (XEN) Missing previously available feature(s).
> (XEN) Enabling non-boot CPUs  ...
>
> Without the patch this result in xen panic.
>
 

> PS: my patch looks like this (it will show the CPUID capability bits 
> changing in the hypervisor log)
>
> diff -ruN a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
> --- a/xen/arch/x86/acpi/power.c 2019-12-15 18:26:11.18300 +0100
> +++ b/xen/arch/x86/acpi/power.c 2019-12-15 18:23:15.43900 +0100
> @@ -257,7 +257,7 @@
>  microcode_resume_cpu(0);
>  
>  if ( !recheck_cpu_features(0) )
> -panic("Missing previously available feature(s).");
> + printk(XENLOG_ERR "Missing previously available 
> feature(s).\n");
>  
>  /* Re-enabled default NMI/#MC use of MSR_SPEC_CTRL. */
>  ci->spec_ctrl_flags |= (default_spec_ctrl_flags & SCF_ist_wrmsr);
>


Interesting. This call to recheck_cpu_features appears to be a check/panic 
that is also in Qubes R4.0, and was backported to Xen 4.8.3 last year:

  
https://github.com/QubesOS/qubes-vmm-xen/commit/c921e46e9e18cd1cfa1347289db4c2f61b8f686a#diff-9ff8c82836adac8412cd8ac4afdf8cae
 
q123 - do you happen to know what the exact two flag bits that changed 
represent in the cpu features? I wonder if the true issue is something not 
being properly preserved during the suspend, or properly re-initialized 
during the resume.

Brendan

-- 
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/26eebc08-a5ca-4786-bc99-0758e26a2fb9%40googlegroups.com.

[qubes-users] Re: Troubleshooting Qubes graphical slowness

2019-12-30 Thread rec wins

On 12/30/19 6:28 AM, Steve Coleman wrote:
> On 2019-12-29 23:32, tetrahedra via qubes-users wrote:
>> On Sun, Dec 29, 2019 at 01:44:28PM +, 'awokd' via qubes-users wrote:
>>> tetrahedra via qubes-users:
 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).
>>>
>>> Investigate xl top more thoroughly. You can identify offending VMs with
>>> it, and see if all your RAM is in use which triggers swapping to (slow)
>>> disk.
>>
>> My disk is a pretty fast SSD, and I did use xentop (`xl top` is just an
>> alias for xentop) and it didn't show anything unusual as far as I can
>> recall. Perusing the xentop man page doesn't show any potentially
>> relevant options except for `--full-name` and that option doesn't seem
>> to do anything. Pressing "B" (for "vBds") seems to list a number of
>> devices for each VM but none of them have any 2-digit unique identifying
>> number (as `iotop` seems to display).
>>
> 
> I have had graphics slowdown issues in the past on two occasions that
> acted like this, so here are some things to try:
> 
> 1) Add the 'nopat' argument to the 'kernel opts:' boot command line.
> 
>> qvm-prefs  -s kernelopts nopat
> 
> 2) The second, I can not seem to locate that email exchange at the
> moment, but it was a option on the graphics subsystem that needed to be
> turned off. Something like backing store, but I'm sure that is not the
> correct name for it. I'll keep looking for that one until I hear back if
> #1 above fixed your problem or not.
> 
> Steve
> 
> 

so how many VMs are open at one time, how much RAM have you?  you know
you can go into qubes settings and change the max RAM / per VM to say
1500 or so ?

I still believe  "speed step" in the UEFI was what was my slowness
problem before, I believe I still have it enabled, slowness for
everything but esp boot times  YMMV

-- 
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/23f3da7d-c26b-b0d5-165c-7b90a9e3f0c7%40riseup.net.

Re: [qubes-users] Qubes/Xen doesn't comply with IOMMU grouping rules for PCI passthru

2019-12-30 Thread qubes123

> 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.
>

I could be wrong, but aren't these PCI assignments and hierarchies coded 
within the ACPI DSDT table in BIOS?
I remember as if in UEFI the ACPI tables could be overridden somehow...
Or - since kernel 5.3.x(?) you can supply certain ACPI tables (as files, 
stored in initrd) to the kernel using commandline parameters* (some 
additional acpi manipulations are needed to extract the current dsdt to see 
what is in there and make changes in aml...)

Or - before all - you can simply try to boot the kernel with cmdline: 
acpi=nocrs (or off) and let the kernel "enroll" the PCI devices. Maybe 
worth to try - just one reboot...

*:https://www.kernel.org/doc/html/latest/admin-guide/acpi/initrd_table_override.html

-- 
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/604f5799-c810-468b-82f9-95bf5b340640%40googlegroups.com.

[qubes-users] "kfd kfd: error getting iommu info. is the iommu enabled?"

2019-12-30 Thread Claudia

I'm getting this message in my logs, about an IOMMU error, on both 4.0.2 and
the F31-based 4.1 build. I'm as certain as I can be that the IOMMU is enabled
in BIOS. I'm having issues with passthru and I'm wondering if this might be the
cause.

In dom0 kernel logs:
AMD IOMMUv2 driver by Joerg Roedel https://community.amd.com/thread/170292
This thread recommends creating /etc/udev/rules.d/kfd.rules with MODE="0666".
Qubes 4.1 has file /usr/lib/udev/rules.d/50-udev-default.rules which contains:
SUBSYSTEM=="kfd", GROUP="render", MODE="0666"
although 4.0.2 appears to have no such file. However I get the same error even
on 4.1 so I don't think that's the fix.

https://unix.stackexchange.com/questions/263901/kfd-error-getting-iommu-info
This thread says add kernel parameter "iommu=pt" but I don't know if that's
effective or safe in Qubes, because Xen handles the IOMMU instead of the kernel
I think. I'm not really sure what that parameter does.

https://bugzilla.redhat.com/show_bug.cgi?id=1404139
This thread says it's not a bug, it's just because the system doesn't support
IOMMUv2 and amdkfd (whatever that is) requires IOMMUv2 (whatever that is) for
HSA (whatever that is). I don't really know what any of that means.

Is it an error? Should I be worried? Could it be causing my passthru problems?
Or does it just mean that my GPU is not protected by the IOMMU (same as
iommu=no-igfx on Intel) and I don't have to worry about it?

Re: [qubes-users] Re: HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics

2019-12-30 Thread qubes123

Answering to your earlier question, my CPU capability information bits 
change like this after suspend:

(XEN) Entering ACPI S3 state.
(XEN) AMD-Vi: Applying erratum 746 workaround for IOMMU at :00:00.2
(XEN) Finishing wakeup from ACPI S3 state.
(XEN) CPU0: cap[ 1] is 3e98320b (expected b698320b)
(XEN) Missing previously available feature(s).
(XEN) Enabling non-boot CPUs  ...

Without the patch this result in xen panic.


> I decided to give this a try, but I don't really know how to use the build 
> system. I did `make vmm-xen`, modified the file 
> chroot-dom0-fc29/home/user/rpmbuild/BUILD/xen-4.12.1/xen/arch/x86/acpi/power.c,
>  
> but it appears after running `make vmm-xen` again my changes have been 
> reverted. After it finishes the line is no longer commented out. Do I have 
> to commit the change, or generate a patch file, or something like that? 
>

After you configure the qubes builder (easiest done with ./setup) and 
download all the sources (including the qubes-vmm-xen extra sources), you 
have to put the patch file in the qubes-src/vmm-xen directory.
Then, include this patch in xen.spec.in file (somewhere below the last 
patch line eg. as Patch 1202: xxx --> filename is relative to the vmm-xen 
directory).
Then, change the release (rel file) number to avoid mixing the "official" 
and your custom versions.  
Then run: make wmm-xen, and the new rpms will be available in the pkgs 
folder.
You can check the logs meanwhile xen compiles if your patch was applied 
sucessfuly or not.
Then, install all the rpms (7), that are currently installed in dom0 (eg. 
the devel and the debug files etc. are not needed.

PS: my patch looks like this (it will show the CPUID capability bits 
changing in the hypervisor log)

diff -ruN a/xen/arch/x86/acpi/power.c b/xen/arch/x86/acpi/power.c
--- a/xen/arch/x86/acpi/power.c 2019-12-15 18:26:11.18300 +0100
+++ b/xen/arch/x86/acpi/power.c 2019-12-15 18:23:15.43900 +0100
@@ -257,7 +257,7 @@
 microcode_resume_cpu(0);
 
 if ( !recheck_cpu_features(0) )
-panic("Missing previously available feature(s).");
+ printk(XENLOG_ERR "Missing previously available 
feature(s).\n");
 
 /* Re-enabled default NMI/#MC use of MSR_SPEC_CTRL. */
 ci->spec_ctrl_flags |= (default_spec_ctrl_flags & SCF_ist_wrmsr);

 

-- 
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/89d2d2a2-2bce-40f9-b6ae-add17d956e93%40googlegroups.com.

Re: [qubes-users] Troubleshooting Qubes graphical slowness

2019-12-30 Thread Steve Coleman

On 2019-12-29 23:32, tetrahedra via qubes-users wrote:

On Sun, Dec 29, 2019 at 01:44:28PM +, 'awokd' via qubes-users wrote:

happens next).

Investigate xl top more thoroughly. You can identify offending VMs with
it, and see if all your RAM is in use which triggers swapping to (slow)
disk.

I have had graphics slowdown issues in the past on two occasions that
acted like this, so here are some things to try:

1) Add the 'nopat' argument to the 'kernel opts:' boot command line.

> qvm-prefs -s kernelopts nopat

Steve

Re: [qubes-users] Qubes Structure

2019-12-30 Thread brendan . hoar

On Monday, December 30, 2019 at 6:25:03 AM UTC-5, xao wrote:
>
> Don't know how I missed this link before, but after reading it, things got
> much clear. Thank you!
>

One important tenet of Qubes is that the security focus is primarily
protecting you from cross-domain (cross-VM) disclosure or exposure.
However, anything within a particular VM/domain is about as vulnerable as a
typical linux system.

Hence, why Qubes requires a certain amount of self-discipline even for
basic use cases.

In addition some folks extend that a bit and utilize Qubes further to
separate "personae" from eachother, sometimes routing each through
different VPNs.

Banking VM only for banking; job1 VM only for day job; ...and superhero
domain only for your alternate crime-fighting identity, etc.

In addition, as soon as one starts customizing templates, fingerprinting
during a breach becomes easier, to the point where a breach in two VMs can
end up cross-correlating personae in two VMs even if they connect to the
internet differently.

That's why question #0 is: what are your specific threat concerns? Question
1 is: how will you mitigate them? Mitigations *begin* with behavior, not
technology. Technologies just assist with/automate the behavior.

Lastly, one assumption that comes up a lot is that disposable VMs are
amnesiac. They are not (currently anyway*). The data written to the
disposable VM is unlinked when the disposable VM volumes are removed but
they are not explicitly erased from storage (though may be overwritten over
time). Why? The primary intent of disposable VMs was to prevent propagation
of malware from dodgy files or dodgy websites or targeted attacks. The
intent was NOT to prevent forensic recovery of data from shut-down
disposable VMs.*

* though, that would be a nice feature. there are some baby steps happening
now (e.g. blkdiscard is now run across the volumes before unlinking them,
which may end up being opportunistically anti-forensic on *some* hardware
if trim is enabled all the way down through the storage stack).

Re: [qubes-users] Qubes Structure

2019-12-30 Thread xao

Don't know how I missed this link before, but after reading it, things got much 
clear. Thank you!

-- 
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/16f568d4387.f47414ce49360.2713160746648324395%40privacy.com.co.

Re: [qubes-users] Qubes Structure

2019-12-30 Thread Franz

Look at this link
https://www.qubes-os.org/doc/security-guidelines/

On Mon, Dec 30, 2019 at 1:40 AM xao  wrote:

>
> >If you understand very little, then the most paranoid of setups will get
> you very little in terms of security, because you will end up making
> choices that compromise that security -- or you will just end up wasting a
> great deal of time on things that don't matter.
>
> I do have some experience in computers and cybersecurity, and I want to
> know more. I came here to find more information about qubes architeturing;
> get the most out of it.
>
> If you can provide some links or advice that help me to make better qubes
> setup, I would be thankful to you.
>
> --
> 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/16f551a47ee.d18df96243681.4660457132775699060%40privacy.com.co
> 
> .
>

-- 
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/CAPzH-qBhszp8PmDOvGxOWfVDT9Q5r%3DUVgtXZ9AFF3Yx6MguMfg%40mail.gmail.com.

Re: [qubes-users] Troubleshooting Qubes graphical slowness

Re: [qubes-users] Re: HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics

[qubes-users] Re: Troubleshooting Qubes graphical slowness

Re: [qubes-users] Qubes/Xen doesn't comply with IOMMU grouping rules for PCI passthru

[qubes-users] "kfd kfd: error getting iommu info. is the iommu enabled?"

Re: [qubes-users] Re: HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics

Re: [qubes-users] Troubleshooting Qubes graphical slowness

Re: [qubes-users] Qubes Structure

Re: [qubes-users] Qubes Structure

Re: [qubes-users] Qubes Structure

10 matches

Site Navigation

Mail list logo

Footer information