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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ