Re: KVM: MMU: update sp->gfns on pte update path

[Avi Kivity <avi@redhat.com>]

On 01/25/2011 07:12 PM, Marcelo Tosatti wrote:
> >
> >  Should be done by a call to kvm_mmu_page_set_gfn().  But I don't
> >  understand how it could become inconsistent in the first place.
> >
> >      if (is_rmap_spte(*sptep)) {
> >          /*
> >           * If we overwrite a PTE page pointer with a 2MB PMD, unlink
> >           * the parent of the now unreachable PTE.
> >           */
> >          if (level>  PT_PAGE_TABLE_LEVEL&&
> >              !is_large_pte(*sptep)) {
> >              struct kvm_mmu_page *child;
> >              u64 pte = *sptep;
> >
> >              child = page_header(pte&  PT64_BASE_ADDR_MASK);
> >              mmu_page_remove_parent_pte(child, sptep);
> >              __set_spte(sptep, shadow_trap_nonpresent_pte);
> >              kvm_flush_remote_tlbs(vcpu->kvm);
> >          } else if (pfn != spte_to_pfn(*sptep)) {
> >              pgprintk("hfn old %llx new %llx\n",
> >                   spte_to_pfn(*sptep), pfn);
> >              drop_spte(vcpu->kvm, sptep, shadow_trap_nonpresent_pte);
> >              kvm_flush_remote_tlbs(vcpu->kvm);
> >          } else
> >              was_rmapped = 1;
> >      }
> >
> >  If we set was_rmapped, that means rmap_add() was previously called
> >  for this spte/gfn/pfn pair, and all that changes is permissions, no?
>
> What if pfn is the same but gfn differs?

Could be.  Any way to verify if this was the case?

Isn't it nicer to have it detected by the test above and do the 
drop_spte()/kvm_flush_remote_tlbs() thing instead?

-- 
error compiling committee.c: too many arguments to function