On Sat, Apr 6, 2013 at 9:31 AM, agraf <1128...@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 { > <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 >
