qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Andreas Färber" <afaerber@suse.de>
To: Alexander Graf <agraf@suse.de>
Cc: Blue Swirl <blauwirbel@gmail.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Artyom Tarasenko <atar4qemu@gmail.com>,
	Juan Quintela <quintela@redhat.com>
Subject: Re: [Qemu-devel] Poking a sun4v machine
Date: Sun, 06 May 2012 12:18:42 +0200	[thread overview]
Message-ID: <4FA65002.1000000@suse.de> (raw)
In-Reply-To: <7692E997-2413-4B64-93D0-960BE4B260BB@suse.de>

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.

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...

Andreas

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

  parent reply	other threads:[~2012-05-06 10:18 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CACXAS8CHd-7ErnniLHSm3j8vrk4gOO7YfncfJ2Fsug0XvtaEHA@mail.gmail.com>
2012-05-01  9:19 ` [Qemu-devel] Poking a sun4v machine Blue Swirl
2012-05-01 13:33   ` Artyom Tarasenko
2012-05-01 13:54     ` Blue Swirl
2012-05-02 14:50       ` Artyom Tarasenko
2012-05-06  8:37         ` Blue Swirl
     [not found] ` <4F9EC895.5010303@suse.de>
     [not found]   ` <CACXAS8DvZ3Gy8asxvAZSw=YyRZ3cQf=b_nT5x=rr9U6dOSxJDw@mail.gmail.com>
2012-05-01  8:35     ` Andreas Färber
2012-05-01 14:05       ` Artyom Tarasenko
2012-05-01  9:25     ` Blue Swirl
2012-05-01 13:54       ` Artyom Tarasenko
2012-05-01 14:06         ` Blue Swirl
2012-05-02 14:38           ` Artyom Tarasenko
2012-05-06  8:29             ` Blue Swirl
2012-05-06  8:58               ` Alexander Graf
2012-05-06  9:13                 ` Blue Swirl
2012-05-06  9:16                   ` Alexander Graf
2012-05-06 10:18                 ` Andreas Färber [this message]
2012-05-06 10:58                   ` Blue Swirl
2012-05-06 14:08                     ` Andreas Färber
2012-05-01 18:48   ` Alexander Graf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FA65002.1000000@suse.de \
    --to=afaerber@suse.de \
    --cc=agraf@suse.de \
    --cc=atar4qemu@gmail.com \
    --cc=blauwirbel@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).