[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCHv3 02/14] unicore32-softmmu: Add coprocessor 0(sy

From: guanxuetao
Subject: Re: [Qemu-devel] [PATCHv3 02/14] unicore32-softmmu: Add coprocessor 0(sysctrl) and 1(ocd) instruction support
Date: Mon, 25 Jun 2012 11:23:25 +0800 (CST)
User-agent: SquirrelMail/1.4.8-4.0.1.el5

>>> > +unrecognized:
>>> > + �� ��cpu_abort(env, "Wrong register (%d) or wrong operation (%d) in
>>> cp0_set!\n",
>>> > + �� �� �� �� �� ��creg, cop);
>>> The call to cpu_abort() would mean that the guest is able to terminate
>>> QEMU at will, which is not OK. What does real HW do?
>> In my opinion, I just want to terminate qemu when any unhandled or
>> unknown operations happen.
> This can make the emulator vulnerable in the security sense. Probably
> Unicore CPUs are not used now in an environment where the guest can
> not be trusted (like cloud computing), but who knows the future?
Is it proper to print such information to monitor? by using monitor_printf().

>>> The printout should be enabled only for DEBUG_UC32.
>> Here, I just want to print a char in the text console.
>> I tried printw and addch under curses environment, but their color
>> schemes had some problems in my server, and I must call scrollok() at
>> every new-line. (scrl() didn't work) So, I left printf here to output a
>> character from ocd_console in kernel, and it works.
> It breaks the abstraction layer. CPUs very rarely have any direct
> instructions for high level I/O (like console output), instead I/O is
> handled via devices which are accessible via MMIO (or I/O ports for
> x86).
> For debugging, anything can be possible, but that's why I suggested
> using DEBUG_UC32.
I've found my errors. I'm going to use waddch() here. Please see my next

Thanks & Regards,
Guan Xuetao

reply via email to

[Prev in Thread] Current Thread [Next in Thread]