qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Poking a sun4v machine


From: Blue Swirl
Subject: Re: [Qemu-devel] Poking a sun4v machine
Date: Sun, 6 May 2012 10:58:57 +0000

On Sun, May 6, 2012 at 10:18 AM, Andreas Färber <address@hidden> wrote:
> Am 06.05.2012 10:58, schrieb Alexander Graf:
>> Am 06.05.2012 um 10:29 schrieb Blue Swirl <address@hidden>:
>>> On Wed, May 2, 2012 at 2:38 PM, Artyom Tarasenko <address@hidden> wrote:
>>>> On Tue, May 1, 2012 at 4:06 PM, Blue Swirl <address@hidden> wrote:
>>>>> On Tue, May 1, 2012 at 13:54, Artyom Tarasenko <address@hidden> 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? The TLB functions could use a
pointer to struct CPUCommonTLB (containing approximately what
CPU_COMMON_TLB in cpu-defs.h has now) instead of CPUState. Though we
need to pass a CPUState to TLB fill function anyway.

>
> Andreas
>
> --
> SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
> GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg



reply via email to

[Prev in Thread] Current Thread [Next in Thread]