Hi Peter,
On 09/18/2017 10:36 AM, Peter Maydell wrote:
On 18 September 2017 at 14:27, sundeep subbaraya <sundeep.l...@gmail.com> wrote:
Hi Sundeep, Peter,
On 09/15/2017 01:59 PM, Subbaraya Sundeep wrote:
+static void msf2_sysreg_write(void *opaque, hwaddr offset,
+ uint64_t val, unsigned size)
+{
+ MSF2SysregState *s = opaque;
+ uint32_t newval = val;
+
+ offset >>= 2;
+
+ switch (offset) {
+ case MSSDDR_PLL_STATUS:
+ trace_msf2_sysreg_write_pll_status();
+ break;
+
+ case ESRAM_CR:
+ case DDR_CR:
+ case ENVM_REMAP_BASE_CR:
+ if (newval != s->regs[offset]) {
+ qemu_log_mask(LOG_UNIMP,
+ TYPE_MSF2_SYSREG": remapping not supported\n");
I'd rather exit here than continue with inconsistent cpu, Peter what do
you recommend?
Could you please suggest.
We shouldn't exit QEMU for something the guest can provoke. If
the functionality isn't implemented then just LOG_UNIMP it.
This was commented here:
http://lists.nongnu.org/archive/html/qemu-devel/2017-05/msg02971.html
Guest remapping code is like non-return function. Hardware error here
can not happen, so there is no more guest code after a remap request.
Continuing running QEMU will lead to chaos, that's why I recommend
aborting instead of just LOG_UNIMP it.
Regards,
Phil.
