Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <9885be00-f12b-2019-2fa4-cfc5c8816e80@gmail.com>
Date:   Tue, 18 Oct 2022 11:31:59 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.2
Subject: Re: [PATCH 0/3] kvm support for ksm
Content-Language: en-US
To:     seanjc@google.com
Cc:     linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
        linux-mm@kvack.org, avi@redhat.com, aarcange@redhat.com,
        chrisw@redhat.com, riel@redhat.com, jeremy@goop.org,
        mtosatti@redhat.com, hugh@veritas.com, corbet@lwn.net,
        yaniv@redhat.com, dmonakhov@openvz.org
References: <1238457604-7637-1-git-send-email-ieidus@redhat.com>
From:   ewandevelop <ewandevelop@gmail.com>
In-Reply-To: <1238457604-7637-1-git-send-email-ieidus@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 2009/3/31 08:00, Izik Eidus wrote:

> apply it against Avi git tree.
>
> Izik Eidus (3):
>    kvm: dont hold pagecount reference for mapped sptes pages.
>    kvm: add SPTE_HOST_WRITEABLE flag to the shadow ptes.
>    kvm: add support for change_pte mmu notifiers
>
>   arch/x86/include/asm/kvm_host.h |    1 +
>   arch/x86/kvm/mmu.c              |   89 ++++++++++++++++++++++++++++++++-------
>   arch/x86/kvm/paging_tmpl.h      |   16 ++++++-
>   virt/kvm/kvm_main.c             |   14 ++++++
>   4 files changed, 101 insertions(+), 19 deletions(-)
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
>
>
Hi, I'm learning kvm-mmu codes, when I was reading codes from this patch,

I can't understand why we need to do special process for "writable pte".

 > +static int kvm_set_pte_rmapp(struct kvm *kvm, unsigned long *rmapp,
 > +                 unsigned long data)
 > +{
 > +    int need_flush = 0;
 > +    u64 *spte, new_spte;
 > +    pte_t *ptep = (pte_t *)data;
 > +    pfn_t new_pfn;
 > +
 > +    new_pfn = pte_pfn(ptep_val(ptep));
 > +    spte = rmap_next(kvm, rmapp, NULL);
 > +    while (spte) {
 > +        BUG_ON(!is_shadow_present_pte(*spte));
 > +        rmap_printk("kvm_set_pte_rmapp: spte %p %llx\n", spte, *spte);
 > +        need_flush = 1;
 > +        if (pte_write(ptep_val(ptep))) {
 > +            rmap_remove(kvm, spte);
 > +            set_shadow_pte(spte, shadow_trap_nonpresent_pte);
 > +            spte = rmap_next(kvm, rmapp, NULL);
 > +        } else {
 > +            new_spte = *spte &~ (PT64_BASE_ADDR_MASK);
 > +            new_spte |= new_pfn << PAGE_SHIFT;
 > +
 > +            if (!pte_write(ptep_val(ptep))) {
 > +                new_spte &= ~PT_WRITABLE_MASK;
 > +                new_spte &= ~SPTE_HOST_WRITEABLE;
 > +                if (is_writeble_pte(*spte))
 > +                    kvm_set_pfn_dirty(spte_to_pfn(*spte));
 > +            }
 > +            set_shadow_pte(spte, new_spte);
 > +            spte = rmap_next(kvm, rmapp, spte);
 > +        }
 > +    }
 > +    if (need_flush)
 > +        kvm_flush_remote_tlbs(kvm);
 > +
 > +    return 0;
 > +}
 > +

In my opinion, we can just regard writable pte same as readable/executable,

all the corresponding sptes will be set as write-protect, and when guest

access them, an EPT-violation occurs and we do this #PF in kvm.

Shall anyone has some hint ?