Skip running check for untrusted_qdb access

[ben-grande]

One access doesn't takes few nanoseconds, but when looping through domains multiple times, this blocking operation can impact the responsiveness of qubesd.

For: QubesOS/qubes-issues#9902
For: QubesOS/qubes-issues#10569
For: QubesOS/qubes-issues#10648

[ben-grande]

The reason I had to move to qubes.app is because firing the event "domain-load" reaches extensions before it reaches qubes.vm.qubesvm...

[marmarek]

This PR likely completely breaks qubesdb access for freshly started VMs (as in - started when qubesd is already running).
Why exactly you do that? Generally, qdb property shouldn't be accessed if VM isn't running, so the case of this hitting not vm.is_running() (so, not opening the conneciton) should be rather rare.
And the just-pushed force-push is even worse - checking for untrusted_qdb property as a proxy for checking if VM is running is a very obscure solution.

Is it all to avoid calling vm.is_running()? Why? Did you found it slow? If so, the proper (the only acceptable) solution would be to optimize it, not avoid it. Maybe cache that info in the VM object, and update it based on libvirt events?

[ben-grande]

This PR likely completely breaks qubesdb access for freshly started VMs (as in - started when qubesd is already running). Why exactly you do that? Generally, qdb property shouldn't be accessed if VM isn't running, so the case of this hitting not vm.is_running() (so, not opening the conneciton) should be rather rare. And the just-pushed force-push is even worse - checking for untrusted_qdb property as a proxy for checking if VM is running is a very obscure solution.

Is it all to avoid calling vm.is_running()? Why? Did you found it slow?

Yes. It is slow. One call is fine, but many blocking calls takes a considerable time considering it can be called thousand of times (3k-5k just from the two recorded API calls) to check that a halted domain, that has no untrusted_qdb, is not running.

I find it horrible to call libvirt_domain.isActive() multiple times for domains that is not running, and that we would need to write to their qubesdb, which is only available when the domain is running anyway.

If so, the proper (the only acceptable) solution would be to optimize it, not avoid it. Maybe cache that info in the VM object, and update it based on libvirt events?

I guess that is possible... I though it would be dangerous to cache such state, but I can try and see how it goes.

[ben-grande]

Superseded by #819