From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33312) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UOWUr-00026b-Nj for qemu-devel@nongnu.org; Sat, 06 Apr 2013 13:01:49 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UOWUl-0006xQ-6a for qemu-devel@nongnu.org; Sat, 06 Apr 2013 13:01:45 -0400 Received: from mail-ia0-x22d.google.com ([2607:f8b0:4001:c02::22d]:61881) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UOWUl-0006xG-03 for qemu-devel@nongnu.org; Sat, 06 Apr 2013 13:01:39 -0400 Received: by mail-ia0-f173.google.com with SMTP id h37so4040538iak.4 for ; Sat, 06 Apr 2013 10:01:38 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <6C596AF9-E5EE-4095-8025-957F74AD0DAF@suse.de> References: <20130218102749.9311.80891.malonedeb@gac.canonical.com> <6C596AF9-E5EE-4095-8025-957F74AD0DAF@suse.de> From: Blue Swirl Date: Sat, 6 Apr 2013 17:01:17 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: Re: [Qemu-devel] [Bug 1128935] Re: qemu IA64 emulation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bug 1128935 <1128935@bugs.launchpad.net> Cc: qemu-devel On Sat, Apr 6, 2013 at 9:31 AM, agraf <1128935@bugs.launchpad.net> 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. Out of curiosity, why doesn't GUEST_BASE help? > > 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 { > > 72 for (i = 0; i < env->tlb->tlb_in_use; i++) { > > 1865 void r4k_helper_tlbp(CPUMIPSState *env) > 1866 { > > 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 >