All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gigi D'Agostino <iurcic@gmail.com>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] [Bug 1128935] Re: qemu IA64 emulation
Date: Sat, 06 Apr 2013 16:01:01 -0000	[thread overview]
Message-ID: <CAFpdKSC_166BSpzdq4G6sVAMaGPjuznq+CfuqswVEnmrDrL5fw@mail.gmail.com> (raw)
In-Reply-To: 6C596AF9-E5EE-4095-8025-957F74AD0DAF@suse.de

hi,
thank you very much for the answer. i will try do some more easy projects
durring this summer related to asm and things like that and i hope in the
following year to do this project.

best regards


On 6 April 2013 10:31, Alexander Graf <agraf@suse.de> wrote:

> Hi Lurie,
>
> On 04.04.2013, at 19:34, Iurie wrote:
>
> hello,
> in the past year gsoc qemu proposed projects there where on eproject that
> i liked, which were: qemu IA64 emulation :
> http://wiki.qemu.org/Google_Summer_of_Code_2012#IA64_emulation
>
> this year i have not seen this project to be proposed, so i would like to
> know if the qemu will be selected i would like to know if i will be able to
> begin to make this project.
> i am also a very novice in the asm programming (so very noobish in the
> field, so u will have to answer a lot of noobish questions :) ), so would u
> accept such a student to make this project?
>
>
> We had a student working on IA64 emulation last year. Typically, to get a
> new target working, you start off implementing Linux user space emulation,
> then continue to system emulation. User space emulation is a lot easier to
> debug, you need less features of the CPU (no MMU emulation, no privileged
> instructions) and you don't need device emulation code.
>
> However, IA64 maps its virtual memory to locations that x86_64 can not map
> at all. Since in QEMU, Linux user emulation leverages the host's MMU to do
> virtual memory maps, IA64 programs can't be mapped on x86_64 hosts, which
> are the typical development environment for QEMU target code.
>
> So at the end of the day, we had to cancel the IA64 emulation project last
> year.
>
> There is still the slight chance to do IA64 emulation if you take the KVM
> IA64 code from ~3-4 years ago, forward port that to current QEMU, get the
> device model running with KVM on a real IA64 machine, and then implement
> system emulation straight on.
>
> However, that is not an easy task. It requires quite in-depth knowledge of
> all the changes that happened in QEMU device models within the last years
> and a lot of debugging skills to get KVM working. So unless you have a lot
> of IA64 background, I'm afraid this is vastly out of scope for summer of
> code. Unfortunately.
>
>
> Alex
>
>

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1128935

Title:
  MIPS r4k "TLB modified exception" generated for TLB entries that are
  not visible to the TLBP instruction

Status in Home for various HelenOS development branches:
  New
Status in QEMU:
  New

Bug description:
  I occasionally see that the TLBP instruction fails to find the
  corresponding TLB entry in the TLB Modified exception handler.  This
  behavior is unexpected, because the invocation of the TLB Modified
  exception suggests there indeed is such an entry in the TLB and only
  requires its dirty bit to be set.

  The operating system which can trigger and is susceptible to this
  behavior is a HelenOS branch located in lp:~jakub/helenos/mips-malta.
  The QEMU version on which this is reproducible is QEMU 1.4.0 and also
  some others.

  When I looked into the QEMU sources, I noticed the following
  discrepancy, which could potentially explain the behavior:

    65  /* MIPS32/MIPS64 R4000-style MMU emulation */
    66 int r4k_map_address (CPUMIPSState *env, hwaddr *physical, int *prot,
    67                      target_ulong address, int rw, int access_type)
    68 {
    <snip>
    72     for (i = 0; i < env->tlb->tlb_in_use; i++) {

  1865 void r4k_helper_tlbp(CPUMIPSState *env)
  1866 {
   <snip>
  1875     for (i = 0; i < env->tlb->nb_tlb; i++) {

  From the above it appears as if the the code which searches the TLB
  for a matching entry searched also the QEMU-specific "shadow" TLB
  entries, which is, however, not in line with how the TLBP instruction
  searches the TLB. So if a matching entry is found on index >=
  tlb_in_use, the HelenOS exception handler using TLBP to locate the
  entry would hit an assertion on seeing the Index register bit P set.

  I also suspect there is a similar issue with the TLB Invalid
  exception, but thanks to the specifics of the MIPS 4Kc CPU, HelenOS is
  not susceptible in this case.

To manage notifications about this bug go to:
https://bugs.launchpad.net/helenos/+bug/1128935/+subscriptions

  reply	other threads:[~2013-04-06 16:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20130218102749.9311.80891.malonedeb@gac.canonical.com>
2013-04-04 17:34 ` [Qemu-devel] [Bug 1128935] qemu IA64 emulation Gigi D'Agostino
2013-04-04 18:24   ` [Qemu-devel] [Bug 1128935] " Jakub Jermar
2013-04-06  9:31   ` agraf
2013-04-06 16:01     ` Gigi D'Agostino [this message]
2013-04-06 17:01     ` Blue Swirl
2013-04-06 17:26       ` Jakub Jermar
2017-12-15 16:25 ` [Qemu-devel] [Bug 1128935] Re: MIPS r4k "TLB modified exception" generated for TLB entries that are not visible to the TLBP instruction Thomas Huth
2017-12-15 16:50 ` Jakub Jermar
2017-12-15 16:54 ` Jakub Jermar
2017-12-15 17:07 ` Jakub Jermar
2021-05-03 11:28 ` Thomas Huth

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=CAFpdKSC_166BSpzdq4G6sVAMaGPjuznq+CfuqswVEnmrDrL5fw@mail.gmail.com \
    --to=iurcic@gmail.com \
    --cc=1128935@bugs.launchpad.net \
    --cc=qemu-devel@nongnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.