Qubes 4rc3 :: 50% reduced battery runtime compared to Qubes 3.2 on Lenovo X230

[[799]]

Hello,

I'm am running version 4rc3 on my X230 and I am suffering from a very reduced battery runtime.

Under Qubes 3.2 I was able to get 10 to 11hrs of battery runtime with "tlp" enabled and powertop optimizations.

Runtime is now reduced to ~4-5 hrs under Qubes 4rc3. I have installed tlp and powertop in dom0 but am still far far away from my excellent batter runtime under Qubes 3.2

Any ideas what is 'wrong' with 4rc3 or what I am missing?
Are there any power optimizations missing in the kernel? workload and AppVM configuration has not be changed.

Any ideas would be great as I need to work lots of time at the customer location and battery runtime is as important as security.

Running out of battery after half a day adds a lot to security but unfortunately affects productivity ;-)

Kind regards

[799]

[Chris Laprise]

Increased CPU usage is a known issue. You can see it in the 'xentop'
listing.

This may be one of the core tradeoffs when moving to R4.0.

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[[799]]

Hello Chris,

-------- Original-Nachricht --------
An 13. Dez. 2017, 19:15, Chris Laprise schrieb

> Increased CPU usage is a known issue.
> You can see it in the 'xentop' listing.
> This may be one of the core tradeoffs
> when moving to R4.0

Thanks for the hint.
Honestly I can't believe that Qubes 4 comes with such a big trade-off. Keep in mind that the X230 has a very big battery and reduced performance that's why I can squeeze out ~10hrs battery runtime on Windows and Qubes 3.2.

A "normal" laptop would run out after ~2 hrs of time.

To test this I'll run my x230 connected to a power meter with batteries out and take a look at how much power is needed.

I'll run the test on Q4rc3 and Q3.2 which will hopefully help investigating this problem.

On which level is the increased CPU generated? If this is happening on the AppVM level. This would mean that I should get a better runtime when running only dom0, correct?
Of course this is only meant for investigating this issue.

[799]

[Chris Laprise]

I believe the increase is mostly in the stub domains (stubdoms). You can
see them with xentop. There may also be some lack of power tuning in
places like xenpm, sys-net and sys-usb.

[donoban]

On 12/13/2017 07:30 PM, '[799]' via qubes-users wrote:
> Hello Chris,
>
> -------- Original-Nachricht --------
> An 13. Dez. 2017, 19:15, Chris Laprise schrieb
>
> > Increased CPU usage is a known issue.
> > You can see it in the 'xentop' listing.
> > This may be one of the core tradeoffs
> > when moving to R4.0
>

> I'll run the test on Q4rc3 and Q3.2 which will hopefully help
> investigating this problem.
>
> On which level is the increased CPU generated? If this is happening on
> the AppVM level. This would mean that I should get a better runtime when
> running only dom0, correct?
> Of course this is only meant for investigating this issue.

Try playing with xenpm

Using: 'xenpm set-scaling-governor powersave' I win between 20min and 1h
depending on the CPU load (with an average runtime of 3-4h)

[MirrorWay]

Another partial workaround, you can change virt_mode from hvm back to pv for trustworthy VMs, like vault, etc...

The bug: https://github.com/QubesOS/qubes-issues/issues/2849

For me it amounts to an overhead of 10% x cpu core per hvm, according to xentop.

[[799]]

Hello,

I was able to improve battery runtime following the tips from this thread:

I've switched all my AppVMs to virt_mode = pv, using:

dom0: qvm-prefs --set <AppVM> virt_mode pv

In order to monitor my battery runtime and battery discharge rate, I've setup a small monitor in my xfce4-panel:

1) Create a new file in dom0: ~/bin/batmon.sh

2) Add the following content:

#!/bin/bash

# Show Battery Drain and Battery Runtime

echo BAT: `upower -d | grep "time to empty" | head -1 | awk '{ print $4 }'`"h @" `upower -d | grep "energy-rate"   | head -1 | awk '{ print $2 }' | head -c -3`"W/h"

3) make this file executable: chmod +x ~/bin/batmon.sh

4) Test it out, by launching it from the commandline: ~/bin/batmon.sh (as ~/bin is included in the PATH variable, it should run from everywhere via batmon.sh), Output should like:

BAT: 6.5h @ 9.5W/h

Add the ouput to your top menu bar as a small panel:

1) Right Click on the upper bar and choose "Panel", then "Add New Items..."

2) Choose "Generic Monitor", which will add it to the top bar

3) Right Click the new panel and choose "Properties"

4) Add the following information, where USERNAME ist your user in dom0

You can find the correct path by opening a terminal in dom 0 and run the following command: cd & pwd

Command: /home/USERNAME/bin/batmon.sh

Label: leave this disabled

Period (s): 15

If everything has been done correctly, you should Battery Discharge Rate and also Runtime in a new panel, which can be moved to your desired location withon the upper bar (Right Click, and then: Move).

This discharge rate can be uses very easy to monitor the impact of  different configurations settings in Qubes regarding the battery runtime.

Would like to hear your discharge rates.

My current System

> Lenovo X230

> SSD + 16 GB RAM

> sys-net + sys-firewall + Fedora AppVM

> Display Brightness ~25%

> Wifi on

Battery Runtime:

> Battery Drain: 9.3 W/h

> Battery Runtime: 6.6h with Battery Level at 68%

> Full Battery Runtime: 9.7h :-)

QUESTION:

What is the advantage of using PV vs HVM in Qubes? If I can double the battery runtime using PV AppVMs instead of HVMs, this is a strong argument to do so.

Kind regards

[799]

[[799]]

-------- Original-Nachricht --------
An 22. Dez. 2017, 06:49, MirrorWay schrieb:

>> Since watts is already energy/time,
>> this should just say 9.5W

Ok, thanks :-)


>> As I understand it, Xen PV code has bad
>> track record of vulnerabilities, hence the
>> change to HVM in Qubes 4.0.
>> Also why I set only set trustworthy
>> VMs to PV.

This I also what I assumed as there must be a good reason why Qubes Team has switched to HVM instead of using PV VMs.
Still I'd like to learn more about the vulnerabilities, so I can make a decision risk vs. runtime. And as we can easy switch the Virtualization Mode via qvm-prefs, I could use a script to do so:
- shutdown VMs
- change virt_mode
- restart VMs

If I switch to disposable VMs, I assume the risk would be reduced.
Can this be done for the sys-vms?

[799]

[Vít Šesták]

As far as I remember, there was an idea to kill stubdoms after boot, which would both reduce risk (as stubdoms run in PV) and CPU+memory overhead. I cannot try it right now, because I haven't installed Q4.

> If I switch to disposable VMs, I assume the risk would be reduced.

You can sort reduce some risk of having your AppVMs permanently pwned. As a result, this could prevent some kinds of gradual pwnage of dom0.

OTOH, if attacker pwns some your VM and has a reliable way to escape from the VM to dom0, it does not matter if it is DispVM or not.

> Can this be done for the sys-vms?

Not sure about 4, but I have done something similar for sys-usb in Q3.2. Strictly speaking, it is not a DVM, but it behaves similarly. The hack is simple in Q3.2: 1. Truncate VM's private.img to zero bytes. 2. Ensure that the VM template has created /home/user in root.img. (You can do something like this: sudo mkdir /tmp/root && sudo mount --bind / /tmp/root && sudo mkdir /tmp/root/home/user && sudo chown user:user /tmp/root/home/user && sudo chmod 700 /tmp/root/home/user)

In Q4, you will probably be able to do something similar, but you probably can't truncate LVM volume to zero bytes, so this will require some elaboration.

The VM sys-firewall could utilize the same hack unless you have some scripts there. VM sys-net probably cannot utilize this (at least not that straightforwardly) because of network config you have there.

Regards,
Vít Šesták 'v6ak'

[awokd]

On Fri, December 22, 2017 8:55 am, '[799]' via qubes-users wrote:
>
> This I also what I assumed as there must be a good reason why Qubes Team
> has switched to HVM instead of using PV VMs. Still I'd like to learn more
> about the vulnerabilities, so I can make a decision risk vs. runtime. And
> as we can easy switch the Virtualization Mode via qvm-prefs, I could use
> a script to do so: - shutdown VMs
> - change virt_mode
> - restart VMs

See https://www.qubes-os.org/news/2017/07/31/qubes-40-rc1/

> If I switch to disposable VMs, I assume the risk would be reduced.
> Can this be done for the sys-vms?

I remember some discussion of allowing that but not the conclusion!

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Fri, Dec 22, 2017 at 05:30:49AM -0800, Vít Šesták wrote:
> As far as I remember, there was an idea to kill stubdoms after boot, which would both reduce risk (as stubdoms run in PV) and CPU+memory overhead. I cannot try it right now, because I haven't installed Q4.

Unfortunately this doesn't work.
But with PVHv2 stubdomain is also not needed. We're almost there - the
only remaining thing is to solve issues in this pull request:
https://github.com/QubesOS/qubes-linux-kernel/pull/13

> > If I switch to disposable VMs, I assume the risk would be reduced.
>
> You can sort reduce some risk of having your AppVMs permanently pwned. As a result, this could prevent some kinds of gradual pwnage of dom0.
>
> OTOH, if attacker pwns some your VM and has a reliable way to escape from the VM to dom0, it does not matter if it is DispVM or not.
>
> > Can this be done for the sys-vms?
>
> Not sure about 4, but I have done something similar for sys-usb in Q3.2. Strictly speaking, it is not a DVM, but it behaves similarly. The hack is simple in Q3.2: 1. Truncate VM's private.img to zero bytes. 2. Ensure that the VM template has created /home/user in root.img. (You can do something like this: sudo mkdir /tmp/root && sudo mount --bind / /tmp/root && sudo mkdir /tmp/root/home/user && sudo chown user:user /tmp/root/home/user && sudo chmod 700 /tmp/root/home/user)
>
> In Q4, you will probably be able to do something similar, but you probably can't truncate LVM volume to zero bytes, so this will require some elaboration.

In Q4 you can create static DispVM for various tasks, including sys-usb.
I haven't tried it, but something like this should work:

qvm-create -C DispVM -l red sys-usb2
qvm-pci attach --persistent sys-usb2 dom0:00_1a.0
qvm-prefs sys-usb2 autostart true
# optional, if you want
qvm-prefs sys-usb2 provides_network true

Then, disable (or remove) default sys-usb. Of course you need to adjust
device for your hardware.

This way, every time the VM is started, it gets new private volume,
which gets discarded at VM shutdown. But VM configuration is persistent,
so you don't have to configure it each time.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlo/AesACgkQ24/THMrX
1yxYpAf/cs7JQIWng5JoHFnPwa7T39ca+Qgwl7nEnmsh47giMUKN/wFBjEc2M4AB
hN6nL8fBaqFTCLwXJ7JEei2+ynkDHf6e7fD1f46iukDUAcsirXu71D732R5p2oIn
r3/YkPLxJuu6uhbHNxDLI5fNDmZV19WpN3XlZG0yBapVcgxY0Wtp/IsXlukCibXx
s4nwES4PzJ5J4gsM1Hms/Rj+R1GAwZpqaOMB1JV3PopPln5elkU4Xy6WHY4Huf/O
WBMtqExBNejs2t88PRnoTaqvOAQPtXvdeeRfYz4KUhzszt5LesWR6ha0v9F/bIcx
FArUa0FebieskJpcOxfeX4j+Sa4+mw==
=o+xQ
-----END PGP SIGNATURE-----