Re: [Android-virt] [PATCH v5 08/13] ARM: KVM: Handle guest faults in KVM

[Avi Kivity <avi@redhat.com>]

On 12/13/2011 03:10 PM, Christoffer Dall wrote:
> >> the question is just which mappings are the
> >> most efficient to reclaim.
> >
> > Do you have accessed bits in those PTEs?
> >
>
> nope. We can protect the underlying target pages though, but...

Yeah, we have the same issue with one of the vendors.  Fortunately only
90% of the market is affected.

> > It's not really critical to have efficient reclaim here, since it
> > happens so rarely.  It just needs to do something.
> >
>
> when would you trigger it - when it reaches a certain limit, or? And
> then what, free the lot and re-allocate what's needed?

The kernel triggers it based on internal pressure.  It tells you how
much pressure to apply, so you just translate it to a number of pages to
free.


> >> The other problem, the actual guest memory consuming too much memory,
> >> I assumed this limit would be set by the user when creating his/her
> >> VM, or can we do something smarter? (again, forgive my ignorance).
> >> What is the alternative to pinning actual guest pages
> >
> > mmu notifiers - pages aren't pinned; instead, Linux calls back into kvm
> > when modifying a host pte, and kvm responds by dropping or modifying its
> > translation (second stage pte in your case).
> >
>
> ah ok, so this works across VM boundary. Based on hyper-calls I presume?

No, it's completely internal to the host.

See for example kvm_mmu_notifier_invalidate_page() (in common code). 
It's called when Linux-as-host wants to change a pte (say to swap a
page).  kvm responds by translating the host virtual address into a
guest physical address (via the memory slots table), then zapping the
relevant pte and flushing and TLBs which may have cached the pte.

> > mmu notifiers are also useful for other optimizations, like ksm,
> > ballooning, and transparent huge pages.
> >
>
> I know those features have to be supported eventually. The question is
> if all this must be in place before a merge upstream?

It doesn't have to be there for the merge but I recommend giving it high
priority.  At least read and understand the code so the addition will
follow naturally.

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