linux-kernel - Re: ...\n

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 for Android: free password hash cracker in your pocket

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

Message-ID: <2bdfde74-da27-667d-d1c4-3b17147cecce@redhat.com>
Date:   Wed, 1 Jun 2022 10:57:21 +0200
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     "Durrant, Paul" <pdurrant@...zon.co.uk>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>
Cc:     "Allister, Jack" <jalliste@...zon.com>,
        "bp@...en8.de" <bp@...en8.de>,
        "diapop@...zon.co.uk" <diapop@...zon.co.uk>,
        "hpa@...or.com" <hpa@...or.com>,
        "jmattson@...gle.com" <jmattson@...gle.com>,
        "joro@...tes.org" <joro@...tes.org>,
        "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "metikaya@...zon.co.uk" <metikaya@...zon.co.uk>,
        "mingo@...hat.com" <mingo@...hat.com>,
        "rkrcmar@...hat.com" <rkrcmar@...hat.com>,
        "sean.j.christopherson@...el.com" <sean.j.christopherson@...el.com>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "wanpengli@...cent.com" <wanpengli@...cent.com>,
        "x86@...nel.org" <x86@...nel.org>
Subject: Re: ...\n

On 6/1/22 10:54, Durrant, Paul wrote:
> That is exactly the case. This is not 'some hare-brained money
> scheme'; there is genuine concern that moving a VM from old h/w to
> new h/w may cause it to run 'too fast', breaking any such calibration
> done by the guest OS/application. I also don't have any real-world
> examples, but bugs may well be reported and having a lever to address
> them is IMO a good idea. However, I also agree with Paolo that KVM
> doesn't really need to be doing this when the VMM could do the job
> using cpufreq, so we'll pursue that option instead. (FWIW the reason
> for involving KVM was to do the freq adjustment right before entering
> the guest and then remove the cap right after VMEXIT).

But if so, you still would submit the full feature, wouldn't you?

Paul, thanks for chiming in, and sorry for leaving you out of the list 
of people that can help Jack with his upstreaming efforts.  :)

Paolo