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@xxxxxxxxxx> 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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
