On 07.08.2012, at 16:14, Avi Kivity <avi@xxxxxxxxxx> wrote:
> On 08/07/2012 04:52 PM, Alexander Graf wrote:
>>>>
>>>> +/************* MMU Notifiers *************/
>>>> +
>>>> +int kvm_unmap_hva(struct kvm *kvm, unsigned long hva)
>>>> +{
>>>> + /* Is this a guest page? */
>>>> + if (!hva_to_memslot(kvm, hva))
>>>> + return 0;
>>>> +
>>>> + /*
>>>> + * Flush all shadow tlb entries everywhere. This is slow, but
>>>> + * we are 100% sure that we catch the to be unmapped page
>>>> + */
>>>> + kvm_flush_remote_tlbs(kvm);
>>>
>>> Wow.
>>
>> Yeah, cool, eh? It sounds worse than it is. Usually when we need to page out, we're under memory pressure. So we would get called multiple times to unmap different pages. If we just drop all shadow tlb entries, we also freed a lot of memory that can now be paged out without callbacks.
>
> And it's just a shadow tlb yes? So there's a limited amount of stuff
> there. But it'd be hell on x86.
>
>>
>>>
>>>> +
>>>> + return 0;
>>>> +}
>>>> +
>>>
>>> Where do you drop the reference count when installing a page in a shadow
>>> tlb entry?
>>
>> Which reference count? Essentially the remote tlb flush calls kvmppc_e500_prov_release() on all currently mapped shadow tlb entries. Are we missing out on something more?
>>
>
> With mmu notifiers mapped pages are kept without elevated reference
> counts; the mmu notifier protects them, not the refcount. This allows
> core mm code that looks at refcounts to work.
Hrm. I wonder why it works then. We only drop the refcount after we got an mmu notifier callback. Maybe we get a callback on an unmapped page, but then happen to clear all the shadow entries as well, hence unpinning them along the way?
That explains why it works, but sure isn't exactly working as intended. Thanks for the hint!
Alex
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/cucslists/listinfo/kvmarm
