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

[Thomas Huth]

On 2018-10-30 13:39, Laurent Vivier wrote:
> Le 30/10/2018 à 14:12, Mark Cave-Ayland a écrit :
>> On 30/10/2018 12:49, Laurent Vivier wrote:
>>
>>> 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.
>>
>> Yeah I think you're right, sorry about that. I'm sure I tried without 
>> 629754d847 and
>> I got a premature exit from QEMU but only in graphic mode, but I've just 
>> tried again
>> and can't seem to recreate it now.
[...]
>>> 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
>>
>> Interesting. So is this an actual bug in QEMU in terms of implementing the 
>> processor
>> specification, or is it relying on undefined behaviour on real hardware?
> 
> It's a bug in QEMU.
> 
> EXCP_UNSUPPORTED is defined to a QEMU specific value (61) that is in the
> Unassigned/Reserved range of the vector table.
> 
> It is used by QEMU user-mode to trigger illegal instruction, whereas
> illegal is also used to do simcalls (some thing like a syscall with an
> illegal instruction trap). I think this should be deprecated as no one
> is maintaining that and knows how to use that.
> 
> Perhaps Thomas as an idea as it comes with the coldfire implementation?
> (e6e5906b6e ColdFire target)

No clue, I've never used those simcalls before.

Maybe we could "fix" it simply by changing the #define in cpu.h like this:

#if defined(CONFIG_USER_ONLY)
#define EXCP_UNSUPPORTED    61
#else
#define EXCP_UNSUPPORTED    EXCP_ILLEGAL
#endif

?

If that does not work, I'm also fine if we simply deprecate the simcalls
(if possible).

 Thomas