linux-kernel - Re: [PATCH 2/2] KVM: VMX: Add Force Emulation Prefix for "emulate the next instruction"

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]

Date:   Tue, 27 Mar 2018 10:19:42 +0200
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Liran Alon <liran.alon@...cle.com>, kernellwp@...il.com
Cc:     rkrcmar@...hat.com, linux-kernel@...r.kernel.org,
        andrew.cooper3@...rix.com, kvm@...r.kernel.org
Subject: Re: [PATCH 2/2] KVM: VMX: Add Force Emulation Prefix for "emulate the
 next instruction"

On 27/03/2018 09:52, Liran Alon wrote:
>> +static bool __read_mostly fep = 0;
>> +module_param(fep, bool, S_IRUGO);
> I think this module parameter should have a better name...
> Why not "emulation_prefix" or "enable_emulation_prefix"?
> This short names just confuse the average user.
> It makes him think it is some kind of Intel VT-x technology
> that he isn't aware of :P

Agreed.

> In addition, I think this module parameter should be in kvm module
> (not kvm_intel) and you should add similar logic to kvm_amd module (SVM)

If you can move handle_ud to x86.c, then it makes sense to have the
module parameter in the kvm module.  I haven't checked.

Otherwise you would have to EXPORT_SYMBOL_GPL the variable; in the end
it's just a debugging tool, so it'd be simpler to just add it separately
to kvm_intel and kvm_amd.

Paolo