Hi,
Regarding all the comments on raising an exception. The real hardware does
only support a few basic exception (like div by zero or interrupts and system
calls). There is no checking if an instruction is supported or not. If an
illegal opcode (like divu if the hardware divider is not enabled) is decoded,
the behaviour is undefined.
Additionally, there are no privileged instructions, no distinction between
kernel and userspace, no memory protection, the LM32 CPU targets to be a
lightweight and relative fast softcore for FPGAs. There are many ways to kill
the VM from 'userspace' (in real hardware and in my qemu port :) )
I treat QEMU as a tool to help developers writing software for this platform,
rather than really running software inside a VM.
That said, IMHO the best handling of unknown opcodes would be to kill the VM.

On Sat, Feb 12, 2011 at 12:23 AM, Michael Walle <michael@walle.cc> wrote:
> Hi,>> Regarding all the comments on raising an exception. The real hardware does> only support a few basic exception (like div by zero or interrupts and system> calls). There is no checking if an instruction is supported or not. If an> illegal opcode (like divu if the hardware divider is not enabled) is decoded,> the behaviour is undefined.>> Additionally, there are no privileged instructions, no distinction between> kernel and userspace, no memory protection, the LM32 CPU targets to be a> lightweight and relative fast softcore for FPGAs. There are many ways to kill> the VM from 'userspace' (in real hardware and in my qemu port :) )>> I treat QEMU as a tool to help developers writing software for this platform,> rather than really running software inside a VM.>> That said, IMHO the best handling of unknown opcodes would be to kill the VM.
In this case it should be OK. Alternatively the VM could be halted, so
that instead of restarting QEMU, only system_reset needs to be issued.
This may be more useful for developers, since for example registers
and memory can be examined after the error.

Am Samstag 12 Februar 2011, 07:49:52 schrieb Blue Swirl:
> > That said, IMHO the best handling of unknown opcodes would be to kill the> > VM.> > In this case it should be OK. Alternatively the VM could be halted, so> that instead of restarting QEMU, only system_reset needs to be issued.> This may be more useful for developers, since for example registers> and memory can be examined after the error.
Good idea! May I call vm_stop() in a tcg helper? Like in the following
example:
void helper_vm_stop(uint32_t msg_id)
{
if (qemu_log_enabled()) {
qemu_log("VM stopped: %s", err_msg_str[msg_id]);
} else {
fprintf(stderr, "VM stopped: %s", err_msg_str[msg_id]);
}
#ifndef CONFIG_USER_ONLY
vm_stop(0);
#endif
env->exception_index = EXCP_HALTED;
cpu_loop_exit();
}
If not, what is the proper way to stop/pause the VM from within the executed
code?

On 17.02.2011, at 23:51, Michael Walle wrote:
> Am Samstag 12 Februar 2011, 07:49:52 schrieb Blue Swirl:>>> That said, IMHO the best handling of unknown opcodes would be to kill the>>> VM.>> >> In this case it should be OK. Alternatively the VM could be halted, so>> that instead of restarting QEMU, only system_reset needs to be issued.>> This may be more useful for developers, since for example registers>> and memory can be examined after the error.> > Good idea! May I call vm_stop() in a tcg helper? Like in the following > example:> > void helper_vm_stop(uint32_t msg_id)> {> if (qemu_log_enabled()) {> qemu_log("VM stopped: %s", err_msg_str[msg_id]);> } else {> fprintf(stderr, "VM stopped: %s", err_msg_str[msg_id]);> }> #ifndef CONFIG_USER_ONLY> vm_stop(0);> #endif> env->exception_index = EXCP_HALTED;> cpu_loop_exit();> }> > If not, what is the proper way to stop/pause the VM from within the executed > code?
Since I haven't seen any reply yet: Can't you just do the same as hlt and disable interrupts?
Alex

On 17.03.2011, at 00:08, Michael Walle <michael@walle.cc> wrote:
> Am Freitag 11 März 2011, 06:57:18 schrieben Sie:>> On 17.02.2011, at 23:51, Michael Walle wrote:>>> Am Samstag 12 Februar 2011, 07:49:52 schrieb Blue Swirl:>>>>> That said, IMHO the best handling of unknown opcodes would be to kill>>>>> the VM.>>>> >>>> In this case it should be OK. Alternatively the VM could be halted, so>>>> that instead of restarting QEMU, only system_reset needs to be issued.>>>> This may be more useful for developers, since for example registers>>>> and memory can be examined after the error.>>> >>> Good idea! May I call vm_stop() in a tcg helper? Like in the following>>> example:>>> >>> void helper_vm_stop(uint32_t msg_id)>>> {>>> >>> if (qemu_log_enabled()) {>>> >>> qemu_log("VM stopped: %s", err_msg_str[msg_id]);>>> >>> } else {>>> >>> fprintf(stderr, "VM stopped: %s", err_msg_str[msg_id]);>>> >>> }>>> >>> #ifndef CONFIG_USER_ONLY>>> >>> vm_stop(0);>>> >>> #endif>>> >>> env->exception_index = EXCP_HALTED;>>> cpu_loop_exit();>>> >>> }>>> >>> If not, what is the proper way to stop/pause the VM from within the>>> executed code?>> >> Since I haven't seen any reply yet: Can't you just do the same as hlt and>> disable interrupts?> This won't set the VM stopped property, eg. 'info status' will still report > the VM status as running.> > And the timer would still be running, wouldn't it?>
Well you got the code in as is anyway, so it doesn't really matter ;)
Alex
> -- > Michael