linux-kernel - Re: [PATCH] KVM: VMX: check match table

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, 3 Oct 2017 19:58:26 -0700
From:   Nick Desaulniers <nick.desaulniers@...il.com>
To:     Paolo Bonzini <pbonzini@...hat.com>
Cc:     Josh Triplett <josh@...htriplett.org>, kay@...y.org,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
        Radim Krčmář <rkrcmar@...hat.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        kvm@...r.kernel.org
Subject: Re: [PATCH] KVM: VMX: check match table

- avi

I think an extra `did not` made it in to that last email...sorry!

On Tue, Oct 3, 2017 at 7:54 PM, Nick Desaulniers
<nick.desaulniers@...il.com> wrote:
> On Tue, Oct 03, 2017 at 11:42:18AM +0200, Paolo Bonzini wrote:
>> On 01/10/2017 01:22, Nick Desaulniers wrote:
>> > I don't follow (but I also don't know what any of these three letter
>> > acryonyms acronyms stand for), does svm depend on vmx or vice-versa?
>> Neither, one is Intel (VMX), the other is AMD (SVM).
>
> Oh, neat, did not realize the vendors did not have different names for
> their virtualization extensions.
>
> https://rtfmp.com/2016/03/21/what-does-vmx-svm-cpu-flags-mean/
>
>> Would this work for you?
>
> It doesn't apply cleanly on Linus' tree, or the KVM tree master branch,
> so I couldn't fully test it.  But it does look like it will do the
> trick.
>
>> And again, is this only with clang?
>
> Indeed the warning was coming from Clang, but looks like some
> additional cleanup was done, which is good.
>
> Reviewed-by: Nick Desaulniers <nick.desaulniers@...il.com>