[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Poking a sun4v machine
From: |
Andreas Färber |
Subject: |
Re: [Qemu-devel] Poking a sun4v machine |
Date: |
Sun, 06 May 2012 16:08:05 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120421 Thunderbird/12.0 |
Am 06.05.2012 12:58, schrieb Blue Swirl:
> 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?
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
- Re: [Qemu-devel] Poking a sun4v machine, (continued)
- Re: [Qemu-devel] Poking a sun4v machine, Blue Swirl, 2012/05/01
- Re: [Qemu-devel] Poking a sun4v machine, Artyom Tarasenko, 2012/05/01
- Re: [Qemu-devel] Poking a sun4v machine, Blue Swirl, 2012/05/01
- Re: [Qemu-devel] Poking a sun4v machine, Artyom Tarasenko, 2012/05/02
- Re: [Qemu-devel] Poking a sun4v machine, Blue Swirl, 2012/05/06
- Re: [Qemu-devel] Poking a sun4v machine, Alexander Graf, 2012/05/06
- Re: [Qemu-devel] Poking a sun4v machine, Blue Swirl, 2012/05/06
- Re: [Qemu-devel] Poking a sun4v machine, Alexander Graf, 2012/05/06
- Re: [Qemu-devel] Poking a sun4v machine, Andreas Färber, 2012/05/06
- Re: [Qemu-devel] Poking a sun4v machine, Blue Swirl, 2012/05/06
- Re: [Qemu-devel] Poking a sun4v machine,
Andreas Färber <=
Re: [Qemu-devel] Poking a sun4v machine, Alexander Graf, 2012/05/01