On Mon, 18 Jul 2011 12:09:53 +0200
Alexander Graf <agraf@xxxxxxx> wrote:
> On 08.07.2011, at 01:41, Scott Wood wrote:
>
> > +void kvmppc_core_heavy_exit(struct kvm_vcpu *vcpu)
> > +{
> > + struct kvmppc_vcpu_e500 *vcpu_e500 = to_e500(vcpu);
> > + int i;
> > +
> > + /*
> > + * We may have modified the guest TLB, so mark it dirty.
> > + * We only do it on an actual return to userspace, to avoid
> > + * adding more overhead to getting scheduled out -- and avoid
> > + * any locking issues with getting preempted in the middle of
> > + * KVM_CONFIG_TLB, etc.
> > + */
> > +
> > + for (i = 0; i < vcpu_e500->num_shared_tlb_pages; i++)
> > + set_page_dirty_lock(vcpu_e500->shared_tlb_pages[i]);
>
> Does this work? Why do we need to set them dirty in the first place? If the shared tlb pages are on file backed storage, we're screwed under memory pressure either way and they'd just get evicted despite us writing to them. Or does vmap pin them? Either way, they're either pinned or not. And if they're not, dirtying them here shouldn't really buy us anything, no?
They're pinned by get_user_pages_fast(). We (potentially) write to them, so
we should mark them dirty, because they are dirty. It's up to the rest
of Linux what to do with that. Will being pinned stop updates from being
written out if it is file-backed? And eventually the vm will be destroyed
(or the tlb reconfigured) and the pages will be unpinned.
-Scott
--
To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
