Am 06.05.2012 12:58, schrieb Blue Swirl: > On Sun, May 6, 2012 at 10:18 AM, Andreas Färber <afaer...@suse.de> wrote: >> Am 06.05.2012 10:58, schrieb Alexander Graf: >>> Am 06.05.2012 um 10:29 schrieb Blue Swirl <blauwir...@gmail.com>: >>>> On Wed, May 2, 2012 at 2:38 PM, Artyom Tarasenko <atar4q...@gmail.com> >>>> wrote: >>>>> On Tue, May 1, 2012 at 4:06 PM, Blue Swirl <blauwir...@gmail.com> wrote: >>>>>> On Tue, May 1, 2012 at 13:54, Artyom Tarasenko <atar4q...@gmail.com> >>>>>> wrote: >>>>>>> To me it looks like at the end do_interrupt will have less >>>>>>> common parts between sun4u and sun4v than specific ones. >>>>>> >>>>>> Same as tlb_fill(), switch() or function pointer. The functions are >>>>>> different. >>>>>> >>>>>> This is unavoidable (unless maybe in the future the TLB handling can >>>>>> be pushed partially higher so mmu_idx parameters can be eliminated) >>>>>> and the performance cost is not great. >> [...] >>>> Architectures are not meant to handle small issues like this. >>>> Should performance become a problem, there are a plenty of lower >>>> hanging fruits where to start optimizing. >>>> >>>> Even in this case, rather than the new architecture solution, it could >>>> be possible to build separate TLB handlers which call directly the >>>> correct MMU functions without switches and these would be selected at >>>> translation time or earlier. For the PPCEMB case, maybe the memory API >>>> could be changed to handle different page sizes without loss of >>>> performance, I don't know. Devices should not depend on >>>> TARGET_PAGE_SIZE. >>> >>> It's not a matter of an API. The main problem is that the QEMU TLB has to >>> be fine grained enough to handle 1k faults, so it has to be in 1k-steps in >>> its current design. >> >> Due to the TLB being a common property of CPUs yet dependent on target >> sizes, I had the idea of breaking it out from CPU(Arch)State so that we >> can have a different inheritance hierarchy than for CPUs. But that's >> just an unevaluated idea so far and more than 138 commits in the future. > > Yes, this is in part what I wanted with cputlb.[ch] change. > >> Same problem for breakpoints and watchpoints btw. >> >> ppcemb is no priority for me, but in order to move the very basic halted >> and interrupt_request fields to CPUState, for a VMState post_load hook >> we need to be able to tlb_flush() based on CPUState rather than >> CPUArchState. Currently just a pointer hack on qom-cpu branch; as an >> interim solution I might just defer that to target code to workaround >> the problem... > > Could the TLB become a separate object?
That's what I meant with "breaking it out from CPU(Arch)State". :) /-F -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg
