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

[Laurent Vivier]

On 02/11/2018 01:32, Thomas Huth wrote:
> 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
> 

I've found EXCP_UNSUPPORTED is a valid value to softmmu too, only
supported by some coldfire version.

In fact, we don't need the EXCP_UNSUPPORTED, the EXCP_ILLEGAL is used to
call the simcall interface. Before the introduction of m680x0 emulation
, EXCP_ILLEGAL was only used with the "illegal" instruction, other
unsupported instructions triggered the EXCP_UNSUPPORTED. So only the
"illegal" instruction was able to enter in the simcall interface.
As I have changed that, I think it should not work correctly anymore,
and I have no idea how to test that... and I'm pretty sure no one is
using that anymore (and if needed could switch to the standard "trap #0"
linux-user interface)

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

I have a patch to deprecate the interface. I will send it once the
release will be done.

Thanks,
Laurent