linux-kernel - Re: Possible regression in cpuacct.stats system time

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] [day] [month] [year] [list]

Message-ID: <49664b8e-8b14-eb5c-f25c-da604b7c077b@redhat.com>
Date:   Tue, 5 Jan 2021 08:27:13 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Nitesh Narayan Lal <nitesh@...hat.com>,
        linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        tglx@...utronix.de, alexandre.chartre@...cle.com,
        peterz@...radead.org, w90p710@...il.com,
        sean.j.christopherson@...el.com, vkuznets@...hat.com
Subject: Re: Possible regression in cpuacct.stats system time

On 04/01/21 22:24, Nitesh Narayan Lal wrote:
> Hi,
> 
> Last year I reported an issue of "suspicious RCU usage" [1] with the debug
> kernel which was fixed with the patch:
> 
>      87fa7f3e98 "x86/kvm: Move context tracking where it belongs"
> 
> Recently I have come across a possible regression because of this
> patch in the cpuacct.stats system time.
> 
> With the latest upstream kernel (5.11-rc2) when we set up a VM and start
> observing the system time value from cpuacct.stat then it is significantly
> higher than value reported with the kernel that doesn't have the
> previously mentioned patch.
> 
> FWIU the reason behind this increase is the moving of guest_exit_irqoff()
> to its proper location (near vmexit). This leads to the accounting
> of instructions that were previously accounted into the guest context as a
> part of the system time.
> 
> IMO this should be an expected behavior after the previously mentioned
> change. Is that a right conclusion or I am missing something here?

Yes it's expected and I think it's more precise, since this is host 
overhead rather than guest operation .

> Another question that I have is about the patch
> 
>      d7a08882a0 "KVM: x86: Unconditionally enable irqs in guest context"
> 
> considering we are enabling irqs early now in the code path, do we still
> need this patch?

No, we don't.  Since the code is a bit simpler without it, feel free to 
send a revert.

Thanks,

Paolo

> 
> [1] https://lore.kernel.org/lkml/ece36eb1-253a-8ec6-c183-309c10bb35d5@redhat.com/
> 
> --
> Thanks
> Nitesh
>