On Wed, Mar 16, 2011 at 04:03:47PM +0100, Alexander Graf wrote:
> On 03/16/2011 05:56 AM, David Gibson wrote:
[snip]
> >@@ -248,6 +261,16 @@ static void ppc_spapr_init(ram_addr_t ram_size,
> > ram_offset = qemu_ram_alloc(NULL, "ppc_spapr.ram", ram_size);
> > cpu_register_physical_memory(0, ram_size, ram_offset);
> >
> >+ /* allocate hash page table */
> >+ htab_size = 1ULL<< (pteg_shift + 7);
>
> Linux makes the htab size depend on the provided amount of ram.
> Shouldn't we do the same?
Well... maybe. In fact the guidelines for hash allocation tend to be
rather larger than really necessary for a Linux guest, so generally
16mb for the hash will be fine. This does also correspond to the
allocation for the guest hash we use in our experimental kvm code
(making the hash exactly one hugepage makes the necessary contiguous
allocation easier).
[snip]
> >+ r&= ~(HPTE_R_PP0 | HPTE_R_PP | HPTE_R_N |
> >+ HPTE_R_KEY_HI | HPTE_R_KEY_LO);
> >+ r |= (flags<< 55)& HPTE_R_PP0;
> >+ r |= (flags<< 48)& HPTE_R_KEY_HI;
> >+ r |= flags& (HPTE_R_PP | HPTE_R_N | HPTE_R_KEY_LO);
> >+ rb = compute_tlbie_rb(v, r, pte_index);
> >+ stq_p(hpte, v& ~HPTE_V_VALID);
> >+ //ppc_tlb_invalidate_one(env, rb);
>
> Huh?
>
> >+ tlb_flush(env, 1);
>
> Wow, why do you need a full tlb flush here?
Ah, meant to revert that and forgot. Originally I wasn't sure if
compute_tlbie_rb was deducing enough of the full virtual address to
make a targetted tlb invalidate safe. I've since discovered it does,
but fixing this up to take advantage fell through the cracks.
Fixing that for the next version now.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
