From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [PATCH] x86:kvm: fix two typos in comment Date: Mon, 22 Sep 2014 12:49:35 +0200 Message-ID: <541FFEBF.7020607@redhat.com> References: <1411353098-28340-1-git-send-email-tiejun.chen@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: Tiejun Chen Return-path: Received: from mail-wg0-f50.google.com ([74.125.82.50]:46202 "EHLO mail-wg0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752723AbaIVKtg (ORCPT ); Mon, 22 Sep 2014 06:49:36 -0400 Received: by mail-wg0-f50.google.com with SMTP id l18so1572338wgh.9 for ; Mon, 22 Sep 2014 03:49:35 -0700 (PDT) In-Reply-To: <1411353098-28340-1-git-send-email-tiejun.chen@intel.com> Sender: kvm-owner@vger.kernel.org List-ID: Il 22/09/2014 04:31, Tiejun Chen ha scritto: > s/drity/dirty and s/vmsc01/vmcs01 > > Signed-off-by: Tiejun Chen > --- > arch/x86/kvm/mmu.c | 2 +- > arch/x86/kvm/vmx.c | 2 +- > 2 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c > index 76398fe..f76bc19 100644 > --- a/arch/x86/kvm/mmu.c > +++ b/arch/x86/kvm/mmu.c > @@ -1174,7 +1174,7 @@ static void drop_large_spte(struct kvm_vcpu *vcpu, u64 *sptep) > * Write-protect on the specified @sptep, @pt_protect indicates whether > * spte write-protection is caused by protecting shadow page table. > * > - * Note: write protection is difference between drity logging and spte > + * Note: write protection is difference between dirty logging and spte > * protection: > * - for dirty logging, the spte can be set to writable at anytime if > * its dirty bitmap is properly set. > diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c > index 6ffd643..305e667 100644 > --- a/arch/x86/kvm/vmx.c > +++ b/arch/x86/kvm/vmx.c > @@ -8008,7 +8008,7 @@ static void vmx_start_preemption_timer(struct kvm_vcpu *vcpu) > /* > * prepare_vmcs02 is called when the L1 guest hypervisor runs its nested > * L2 guest. L1 has a vmcs for L2 (vmcs12), and this function "merges" it > - * with L0's requirements for its guest (a.k.a. vmsc01), so we can run the L2 > + * with L0's requirements for its guest (a.k.a. vmcs01), so we can run the L2 > * guest in a way that will both be appropriate to L1's requests, and our > * needs. In addition to modifying the active vmcs (which is vmcs02), this > * function also has additional necessary side-effects, like setting various > Thanks, applying. Paolo