[PATCH 1/2] KVM: PPC: Add generic hpte management functions
Avi Kivity
avi at redhat.com
Sun Jun 27 17:53:01 EST 2010
On 06/27/2010 01:58 AM, Benjamin Herrenschmidt wrote:
>
>> Then mmu intensive loads can expect to be slow.
>>
> Well, depends. ppc64 indeed requires the hash to be managed by the
> hypervisor, so inserting or invalidating translations will mean a
> roundtrip to the hypervisor, though there are ways at least the
> insertion could be alleviated (for example, the HV could service the
> hash misses directly walking the guest page tables).
>
But the guest page tables are software defined, no? That means the
interface will break if the page table format changes.
> But that's due in part to a design choice (whether it's a good one or
> not I'm not going to argue here) which favors huge reasonably static
> workloads where the hash is expected to contain all translations for
> everything.
>
What about when you have memory pressure? The hash will have to reflect
those pte_clear_flush_young(), no?
It seems horribly expensive.
> However, note that BookE (the embedded variant of the architecture) uses
> a different model for virtualization, including options in its latest
> variant for a HW logical->real translation (via a small dedicated TLB)
> and direct access to some TLB ops from the guest.
>
I'm somewhat familiar with it, yes.
--
error compiling committee.c: too many arguments to function
More information about the Linuxppc-dev
mailing list