linux-kernel - Re: [PATCH v2] KVM: nVMX: Fix some comment typos and coding style

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

Message-ID: <87zhdupdo1.fsf@vitty.brq.redhat.com>
Date:   Fri, 07 Feb 2020 17:25:50 +0100
From:   Vitaly Kuznetsov <vkuznets@...hat.com>
To:     linmiaohe <linmiaohe@...wei.com>
Cc:     kvm@...r.kernel.org, linux-kernel@...r.kernel.org, x86@...nel.org,
        pbonzini@...hat.com, rkrcmar@...hat.com,
        sean.j.christopherson@...el.com, wanpengli@...cent.com,
        jmattson@...gle.com, joro@...tes.org, tglx@...utronix.de,
        mingo@...hat.com, bp@...en8.de, hpa@...or.com
Subject: Re: [PATCH v2] KVM: nVMX: Fix some comment typos and coding style

linmiaohe <linmiaohe@...wei.com> writes:

> From: Miaohe Lin <linmiaohe@...wei.com>
>
> Fix some typos in the comments. Also fix coding style.
> [Sean Christopherson rewrites the comment of write_fault_to_shadow_pgtable
> field in struct kvm_vcpu_arch.]
>
> Signed-off-by: Miaohe Lin <linmiaohe@...wei.com>
> ---
> v1->v2:
> Use Sean Christopherson' comment for write_fault_to_shadow_pgtable
> ---
>  arch/x86/include/asm/kvm_host.h | 16 +++++++++++++---
>  arch/x86/kvm/vmx/nested.c       |  5 +++--
>  2 files changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
> index 4dffbc10d3f8..40a0c0fd95ca 100644
> --- a/arch/x86/include/asm/kvm_host.h
> +++ b/arch/x86/include/asm/kvm_host.h
> @@ -781,9 +781,19 @@ struct kvm_vcpu_arch {
>  	u64 msr_kvm_poll_control;
>  
>  	/*
> -	 * Indicate whether the access faults on its page table in guest
> -	 * which is set when fix page fault and used to detect unhandeable
> -	 * instruction.
> +	 * Indicates the guest is trying to write a gfn that contains one or
> +	 * more of the PTEs used to translate the write itself, i.e. the access
> +	 * is changing its own translation in the guest page tables.  KVM exits
> +	 * to userspace if emulation of the faulting instruction fails and this
> +	 * flag is set, as KVM cannot make forward progress.
> +	 *
> +	 * If emulation fails for a write to guest page tables, KVM unprotects
> +	 * (zaps) the shadow page for the target gfn and resumes the guest to
> +	 * retry the non-emulatable instruction (on hardware).  Unprotecting the
> +	 * gfn doesn't allow forward progress for a self-changing access because
> +	 * doing so also zaps the translation for the gfn, i.e. retrying the
> +	 * instruction will hit a !PRESENT fault, which results in a new shadow
> +	 * page and sends KVM back to square one.
>  	 */
>  	bool write_fault_to_shadow_pgtable;
>  
> diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
> index 657c2eda357c..e7faebccd733 100644
> --- a/arch/x86/kvm/vmx/nested.c
> +++ b/arch/x86/kvm/vmx/nested.c
> @@ -544,7 +544,8 @@ static void nested_vmx_disable_intercept_for_msr(unsigned long *msr_bitmap_l1,
>  	}
>  }
>  
> -static inline void enable_x2apic_msr_intercepts(unsigned long *msr_bitmap) {
> +static inline void enable_x2apic_msr_intercepts(unsigned long *msr_bitmap)
> +{
>  	int msr;
>  
>  	for (msr = 0x800; msr <= 0x8ff; msr += BITS_PER_LONG) {
> @@ -1981,7 +1982,7 @@ static int nested_vmx_handle_enlightened_vmptrld(struct kvm_vcpu *vcpu,
>  	}
>  
>  	/*
> -	 * Clean fields data can't de used on VMLAUNCH and when we switch
> +	 * Clean fields data can't be used on VMLAUNCH and when we switch
>  	 * between different L2 guests as KVM keeps a single VMCS12 per L1.
>  	 */
>  	if (from_launch || evmcs_gpa_changed)

With Sean's comment added the subject of the patch is a bit unexpected
:-) But the change itself looks good (and thanks Sean for the great
explanation!).

Reviewed-by: Vitaly Kuznetsov <vkuznets@...hat.com>

-- 
Vitaly