Re: [Qemu-devel] [Bug 1128935] Re: qemu IA64 emulation

[Blue Swirl]

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