Re: [Qemu-devel] Poking a sun4v machine

["Andreas Färber" <afaerber@suse.de>]

Am 06.05.2012 12:58, schrieb Blue Swirl:
> On Sun, May 6, 2012 at 10:18 AM, Andreas Färber <afaerber@suse.de> wrote:
>> Am 06.05.2012 10:58, schrieb Alexander Graf:
>>> Am 06.05.2012 um 10:29 schrieb Blue Swirl <blauwirbel@gmail.com>:
>>>> On Wed, May 2, 2012 at 2:38 PM, Artyom Tarasenko <atar4qemu@gmail.com> wrote:
>>>>> On Tue, May 1, 2012 at 4:06 PM, Blue Swirl <blauwirbel@gmail.com> wrote:
>>>>>> On Tue, May 1, 2012 at 13:54, Artyom Tarasenko <atar4qemu@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