linux-kernel - Re: cputime takes cstate into consideration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 26 Jun 2019 21:29:02 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Peter Zijlstra <peterz@...radead.org>
cc:     "Raslan, KarimAllah" <karahmed@...zon.de>,
        "konrad.wilk@...cle.com" <konrad.wilk@...cle.com>,
        "boris.ostrovsky@...cle.com" <boris.ostrovsky@...cle.com>,
        "joao.m.martins@...cle.com" <joao.m.martins@...cle.com>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "kernellwp@...il.com" <kernellwp@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "mtosatti@...hat.com" <mtosatti@...hat.com>,
        "pbonzini@...hat.com" <pbonzini@...hat.com>,
        "ankur.a.arora@...cle.com" <ankur.a.arora@...cle.com>,
        "rkrcmar@...hat.com" <rkrcmar@...hat.com>
Subject: Re: cputime takes cstate into consideration

On Wed, 26 Jun 2019, Peter Zijlstra wrote:

> On Wed, Jun 26, 2019 at 06:55:36PM +0000, Raslan, KarimAllah wrote:
> 
> > If the host is completely in no_full_hz mode and the pCPU is dedicated to a 
> > single vCPU/task (and the guest is 100% CPU bound and never exits), you would 
> > still be ticking in the host once every second for housekeeping, right? Would 
> > not updating the mwait-time once a second be enough here?
> 
> People are trying very hard to get rid of that remnant tick. Lets not
> add dependencies to it.
> 
> IMO this is a really stupid issue, 100% time is correct if the guest
> does idle in pinned vcpu mode.

Correct. We are going to see the same issue with UMWAIT/UMONITOR. If the
timeout is set long enough by the admin, then a task can stay in user mode
UMWAIT for a very long time. And we're going to account that as user time.

That's not any different with a guest.

You might go there and establish a shared page with the guest where the
guest drops his internal accounting information. For trusted guests that
might be a good approximation. For untrusted ones not so much, but then you
just have to say, you occupy the CPU 100% in guest mode. If you idle there,
none of my problems.

Thanks,

	tglx