[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] PPC: Fix large page support in TCG
From: |
David Gibson |
Subject: |
Re: [Qemu-devel] [PATCH] PPC: Fix large page support in TCG |
Date: |
Fri, 9 Mar 2012 14:42:55 +1100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
On Thu, Mar 08, 2012 at 09:24:53AM -0600, Nathan Whitehorn wrote:
>
> On Mar 7, 2012, at 7:25 PM, David Gibson wrote:
>
> >On Sat, Mar 03, 2012 at 10:39:34AM -0600, Nathan Whitehorn wrote:
> >>Fix large page support in TCG. The old code would overwrite the
> >>large page table entry with the fake 4 KB
> >>one generated here whenever the ref/change bits were updated,
> >>causing it to point to the wrong area of memory. Instead of creating
> >>a fake PTE, just update the real address at the end.
> >>
> >>Signed-off-by: Nathan Whitehorn <address@hidden>
> >
> >Hrm. This looks like a cleaner way of handling things, but I don't
> >really follow what exactly was going wrong in the old way. Can you
> >spell out in more detail where the modified pte1 value caused
> >problems?
>
> The problem was that pte1 would get extra bits added into it in
> _find_pte() to produce a new, fake 4KB page table entry. When the
> ref/change bits were updated, pte1 would be written back to the page
> table -- *including* the bits added to make a fake 4K page. At the
> next access, since this function does not clear the low bits of
> large pages (which is probably itself a bug) when it interprets
> them, the generated address would be the large page base, ored with
> the large page remainder for this access, ored with the large page
> remainder from the *previous* access, etc. and you would get a
> progressively more bogus address in the end.
Ah, yes, I see it now. Good catch.
Acked-by: David Gibson <address@hidden>
--
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