Re: [Qemu-block] [Qemu-devel] [PATCH v5 00/11] hw/m68k: add Apple Machintosh Quadra 800 machine

[Laurent Vivier]

Le 30/10/2018 à 12:48, Mark Cave-Ayland a écrit :
> On 30/10/2018 08:15, Richard Henderson wrote:
> 
>> On 10/29/18 1:39 PM, Mark Cave-Ayland wrote:
>>> You can install your own disk using debian-installer, with:
>>>
>>>     ...
>>>     -M q800 \
>>>     -serial none -serial mon:stdio \
>>>     -m 1000M -drive file=m68k.qcow2,format=qcow2 \
>>>     -net nic,model=dp83932,addr=09:00:07:12:34:57 \
>>>     -append "console=ttyS0 vga=off" \
>>>     -kernel vmlinux-4.15.0-2-m68k \
>>>     -initrd initrd.gz \
>>>     -drive file=debian-9.0-m68k-NETINST-1.iso \
>>>     -drive file=m68k.qcow2,format=qcow2 \
>>>     -nographic
>>
>> I tried this and got
>>
>> Trace 0: 0x7f2e886c7140 [00000000/0000d404/0xe000]
>> INT      1: Unassigned(0xf4) pc=0000d404 sp=00393e60 sr=2700
>> INT      2: Access Fault(0x8) pc=00000000 sp=00393e58 sr=2700
>>             ssw:  00000506 ea:   00000000 sfc:  5    dfc: 5
>>
>> which lead straight to buserr and panic.  This happens way early in boot --
>> only 1926 TranslationBlocks generated.
>>
>> Is there some device missing from the command-line that the kernel is 
>> expecting?
> 
> Heh that's annoying. The original branch I forked that Laurent was working on 
> had
> some extra patches at the start of the series: some were required for q800 
> whilst
> others were for new development. I thought that all of the patches required 
> for q800
> had been applied over the past few months, but sadly that isn't the case :(
> 
> I've pushed an updated branch to 
> https://github.com/mcayland/qemu/tree/q800-test
> which contains the patchset plus two extra patches that are still needed to 
> boot to
> the debian installer here:
> 
> 9281a5371f "tmp"
> 629754d847 "target/m68k: manage FPU exceptions"
> 
> Laurent, are these patches ready for upstream or do they need work in which 
> case we
> should leave q800 until the 3.2 cycle?

The only needed part is from 9281a5371f.

--- a/target/m68k/translate.c
+++ b/target/m68k/translate.c
@@ -1552,7 +1552,7 @@ DISAS_INSN(undef)
        but actually illegal for CPU32 or pre-68020.  */
     qemu_log_mask(LOG_UNIMP, "Illegal instruction: %04x @ %08x\n",
                   insn, s->base.pc_next);
-    gen_exception(s, s->base.pc_next, EXCP_UNSUPPORTED);
+    gen_exception(s, s->base.pc_next, EXCP_ILLEGAL);
 }

 DISAS_INSN(mulw)
@@ -2799,7 +2799,7 @@ DISAS_INSN(mull)

     if (ext & 0x400) {
         if (!m68k_feature(s->env, M68K_FEATURE_QUAD_MULDIV)) {
-            gen_exception(s, s->base.pc_next, EXCP_UNSUPPORTED);
+            gen_exception(s, s->base.pc_next, EXCP_ILLEGAL);
             return;
         }

@@ -4509,7 +4509,7 @@ DISAS_INSN(strldsr)
     addr = s->pc - 2;
     ext = read_im16(env, s);
     if (ext != 0x46FC) {
-        gen_exception(s, addr, EXCP_UNSUPPORTED);
+        gen_exception(s, addr, EXCP_ILLEGAL);
         return;
     }
     ext = read_im16(env, s);

Because kernel only manages illegal instruction exception not unsupported.

Without the patch, we have:

IN:
0x0000d454:  071400

INT      1: Unassigned(0xf4) pc=0000d454 sp=00331e60 sr=2700

with the patch:

IN:
0x0000d454:  071400

INT      1: Illegal Instruction(0x10) pc=0000d454 sp=00331e60 sr=2700

We have in linux/arch/m68k/kernel/vectors.c:

/*
 * this must be called very early as the kernel might
 * use some instruction that are emulated on the 060
 * and so we're prepared for early probe attempts (e.g. nf_init).
 */
void __init base_trap_init(void)
{
...

        vectors[VEC_BUSERR] = buserr;
        vectors[VEC_ILLEGAL] = trap;
        vectors[VEC_SYS] = system_call;
}

So I think the unsupported vector jumps to an invalid address.

This seems triggered by the aranym native feature:

    d454:       7300            mvsb %d0,%d1

from linux/arch/m68k/emu/natfeat.c

Thanks,
Laurent