Re: [PATCH 3/5] KVM: PPC: Book3S HV: Handle memory slot deletion and modification correctly

[Marcelo Tosatti <mtosatti@redhat.com>]

On Fri, Aug 10, 2012 at 11:09:09AM +0900, Takuya Yoshikawa wrote:
> On Thu, 9 Aug 2012 22:25:32 -0300
> Marcelo Tosatti <mtosatti@redhat.com> wrote:
> 
> > I'll send a patch to flush per memslot in the next days, you can work
> > out the PPC details in the meantime.

Not anymore.

> Are you going to implement that using slot_bitmap?
> 
> Since I'm now converting kvm_mmu_slot_remove_write_access() to
> rmap based protection, I'd like to hear your plan.
> 
> If you can use the stale memslot to restrict the flush, that
> should live with rmap based protection.

There's no plan. I just wanted to confirm this before converting 
to per-memslot flush.

1) __kvm_set_memory_region line 807:

                 *      - gfn_to_hva (kvm_read_guest, gfn_to_pfn)
                 *      - kvm_is_visible_gfn (mmu_check_roots)
                 */
                kvm_arch_flush_shadow(kvm);
                kfree(old_memslots);
        }

This can be converted to per-memslot flush.

2) __kvm_set_memory_region line 846:

        /*
         * If the new memory slot is created, we need to clear all
         * mmio sptes.
         */
        if (npages && old.base_gfn != mem->guest_phys_addr >> PAGE_SHIFT)
                kvm_arch_flush_shadow(kvm);

This must flush all translations in the new and old GPA ranges:
	a) to remove any mmio sptes that existed in the new GPA range
	   (see ce88decffd17bf9f373cc233c for a description).
	b) to remove any translations in the old range (this is
           necessary because change of GPA base is allowed).

Alex/Paul, slot creation should be rare (and modification of GPA base
should not be used, even though it is supported). But if you really need
a new callback, the two points above are what the second call needs (x86
will flush everything).

The other two kvm_arch_flush_shadow in kvm_mmu_notifier_release and
kvm_destroy_vm must remove all sptes obviously.