Re: [Qemu-devel] [PATCH for-1.6] target-mips: do not raise exceptions when accessing invalid memory

2013-08-05 Thread Andreas Färber 
Am 05.08.2013 00:04, schrieb Aurélien Jarno:
 On Mon, Jul 29, 2013 at 10:35:31PM +0200, Stefan Weil wrote:
 Am 27.07.2013 22:58, schrieb Stefan Weil:
 Am 27.07.2013 22:43, schrieb Andreas Färber:
 Am 27.07.2013 21:37, schrieb Stefan Weil:
 Am 27.07.2013 19:43, schrieb Peter Maydell:
 On 27 July 2013 17:18, Hervé Poussineau hpous...@reactos.org wrote:
 Another solution would be to add a big dummy memory regions on all MIPS 
 boards
 to catch memory accesses and not raise an exception. However, this 
 means that
 each MIPS board will have its own unassigned memory handler, different 
 from the
 global QEMU one.
 Better would be to at least provide fake RAZ/WI implementations of
 devices for the boards, rather than making the dummy region cover
 the whole of the address space. Not 1.6 material, though.


 For MIPS Malta, Linux boot can be fixed by handling read access for two
 addresses:

 0x1fbf8008
 0x1bc80110

 The corresponding definitions in the Linux kernel code seem to be these
 lines:

 #define GCMP_BASE_ADDR  0x1fbf8000
 #define GCMP_ADDRSPACE_SZ   (256 * 1024)
 #define GCMP_GCB_GCMPB_OFS  0x0008  /* Global GCMP
 Base */

 #define MSC01_BIU_REG_BASE  0x1bc8
 #define MSC01_BIU_ADDRSPACE_SZ  (256 * 1024)
 #define MSC01_SC_CFG_OFS0x0110

 = mips_malta.c needs a handler for reads of
 (GCMP_BASE_ADDR + GCMP_GCB_GCMPB_OFS) and
 (MSC01_BIU_REG_BASE + MSC01_SC_CFG_OFS).
 
 I don't think it would be correct to emulate them as this are not
 present on the real Malta board, at least for the model emulated by
 QEMU. Theses addresses correspond to the SMP controller, and is
 therefore only present when an SMP daughter card is installed.
 
 The Linux kernel probes theses addresses, and look if they return
 something consistent. If not the corresponding devices are latter
 ignored.
 
 The real hardware probably returns all 1 or all 0 for addresses not
 decoded to a device. This is what QEMU should model, and it should
 not trigger a DBE or IBE exception.
[snip]

Have you tested Jan's patches limiting the new unassigned read value -1
to PIO?

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH for-1.6] target-mips: do not raise exceptions when accessing invalid memory

2013-08-05 Thread Jan Kiszka 
On 2013-08-05 10:45, Andreas Färber wrote:
 Am 05.08.2013 00:04, schrieb Aurélien Jarno:
 On Mon, Jul 29, 2013 at 10:35:31PM +0200, Stefan Weil wrote:
 Am 27.07.2013 22:58, schrieb Stefan Weil:
 Am 27.07.2013 22:43, schrieb Andreas Färber:
 Am 27.07.2013 21:37, schrieb Stefan Weil:
 Am 27.07.2013 19:43, schrieb Peter Maydell:
 On 27 July 2013 17:18, Hervé Poussineau hpous...@reactos.org wrote:
 Another solution would be to add a big dummy memory regions on all 
 MIPS boards
 to catch memory accesses and not raise an exception. However, this 
 means that
 each MIPS board will have its own unassigned memory handler, different 
 from the
 global QEMU one.
 Better would be to at least provide fake RAZ/WI implementations of
 devices for the boards, rather than making the dummy region cover
 the whole of the address space. Not 1.6 material, though.


 For MIPS Malta, Linux boot can be fixed by handling read access for two
 addresses:

 0x1fbf8008
 0x1bc80110

 The corresponding definitions in the Linux kernel code seem to be these
 lines:

 #define GCMP_BASE_ADDR  0x1fbf8000
 #define GCMP_ADDRSPACE_SZ   (256 * 1024)
 #define GCMP_GCB_GCMPB_OFS  0x0008  /* Global GCMP
 Base */

 #define MSC01_BIU_REG_BASE  0x1bc8
 #define MSC01_BIU_ADDRSPACE_SZ  (256 * 1024)
 #define MSC01_SC_CFG_OFS0x0110

 = mips_malta.c needs a handler for reads of
 (GCMP_BASE_ADDR + GCMP_GCB_GCMPB_OFS) and
 (MSC01_BIU_REG_BASE + MSC01_SC_CFG_OFS).

 I don't think it would be correct to emulate them as this are not
 present on the real Malta board, at least for the model emulated by
 QEMU. Theses addresses correspond to the SMP controller, and is
 therefore only present when an SMP daughter card is installed.

 The Linux kernel probes theses addresses, and look if they return
 something consistent. If not the corresponding devices are latter
 ignored.

 The real hardware probably returns all 1 or all 0 for addresses not
 decoded to a device. This is what QEMU should model, and it should
 not trigger a DBE or IBE exception.
 [snip]
 
 Have you tested Jan's patches limiting the new unassigned read value -1
 to PIO?

Yeah, this sounds a lot like another side effect of using
unassigned_mem_ops for PIO...

Jan

-- 
Siemens AG, Corporate Technology, CT RTC ITP SES-DE
Corporate Competence Center Embedded Linux

Re: [Qemu-devel] [PATCH for-1.6] target-mips: do not raise exceptions when accessing invalid memory

2013-08-05 Thread Aurélien Jarno 
On Mon, Aug 05, 2013 at 07:19:08AM +0200, Stefan Weil wrote:
 Am 05.08.2013 00:37, schrieb Peter Maydell:
  On 4 August 2013 23:04, Aurélien Jarno aurel...@aurel32.net wrote:
  The real hardware probably returns all 1 or all 0 for addresses not
  decoded to a device. This is what QEMU should model, and it should
  not trigger a DBE or IBE exception. Looking at the current MIPS
  documentation, Bus Error is defined as:
 
A bus error exception occurs when an instruction or data access makes a
bus request (due to a cache miss or an  uncacheable reference) and
that request terminates in an error.
 
  Older CPU documentation like the R4000 have a more precise definition:
 
A Bus Error exception is raised by board-level circuitry for events such
as bus time-out, backplane bus parity errors, and invalid physical memory
addresses or access types.
 
  As we don't model this kind of errors, we should definitely just not
  trigger an exception in that case, and even logging the event as
  unimplemented is probably wrong.
  Well, we certainly can model invalid-physical-address and
  bus-timeout where that's what the board does for accesses
  to non-decoded addresses; but presumably in this case it
  doesn't...
 
  -- PMM
 
 Is there anybody who has access to physical Malta hardware?
 It would be interesting to see whether there is an exception
 during the gcmp test or not.
 
 With latest QEMU, the MIPS Malta system emulation starts
 handling the exception caused by the gcmp test, but then
 gets a second exception which is fatal (see below).
 
 There might be something missing in our very simple bios
 emulation.

Booting YAMON in QEMU also shows the same behaviour, that is trying to
access to the 1fbf8008 address and getting a DBE exception, causing it
to fail. So it is clearly not due to our simple bios emulation, but
rather to the way the I/O are emulated.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net

Re: [Qemu-devel] [PATCH for-1.6] target-mips: do not raise exceptions when accessing invalid memory

2013-08-05 Thread Aurélien Jarno 
On Mon, Aug 05, 2013 at 10:45:31AM +0200, Andreas Färber wrote:
 Am 05.08.2013 00:04, schrieb Aurélien Jarno:
  On Mon, Jul 29, 2013 at 10:35:31PM +0200, Stefan Weil wrote:
  Am 27.07.2013 22:58, schrieb Stefan Weil:
  Am 27.07.2013 22:43, schrieb Andreas Färber:
  Am 27.07.2013 21:37, schrieb Stefan Weil:
  Am 27.07.2013 19:43, schrieb Peter Maydell:
  On 27 July 2013 17:18, Hervé Poussineau hpous...@reactos.org wrote:
  Another solution would be to add a big dummy memory regions on all 
  MIPS boards
  to catch memory accesses and not raise an exception. However, this 
  means that
  each MIPS board will have its own unassigned memory handler, 
  different from the
  global QEMU one.
  Better would be to at least provide fake RAZ/WI implementations of
  devices for the boards, rather than making the dummy region cover
  the whole of the address space. Not 1.6 material, though.
 
 
  For MIPS Malta, Linux boot can be fixed by handling read access for two
  addresses:
 
  0x1fbf8008
  0x1bc80110
 
  The corresponding definitions in the Linux kernel code seem to be these
  lines:
 
  #define GCMP_BASE_ADDR  0x1fbf8000
  #define GCMP_ADDRSPACE_SZ   (256 * 1024)
  #define GCMP_GCB_GCMPB_OFS  0x0008  /* Global GCMP
  Base */
 
  #define MSC01_BIU_REG_BASE  0x1bc8
  #define MSC01_BIU_ADDRSPACE_SZ  (256 * 1024)
  #define MSC01_SC_CFG_OFS0x0110
 
  = mips_malta.c needs a handler for reads of
  (GCMP_BASE_ADDR + GCMP_GCB_GCMPB_OFS) and
  (MSC01_BIU_REG_BASE + MSC01_SC_CFG_OFS).
  
  I don't think it would be correct to emulate them as this are not
  present on the real Malta board, at least for the model emulated by
  QEMU. Theses addresses correspond to the SMP controller, and is
  therefore only present when an SMP daughter card is installed.
  
  The Linux kernel probes theses addresses, and look if they return
  something consistent. If not the corresponding devices are latter
  ignored.
  
  The real hardware probably returns all 1 or all 0 for addresses not
  decoded to a device. This is what QEMU should model, and it should
  not trigger a DBE or IBE exception.
 [snip]
 
 Have you tested Jan's patches limiting the new unassigned read value -1
 to PIO?
 

I have tried this patches, and they don't fix the problem.


-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net

Re: [Qemu-devel] [PATCH for-1.6] target-mips: do not raise exceptions when accessing invalid memory

2013-08-05 Thread Andreas Färber 
Am 05.08.2013 15:31, schrieb Aurélien Jarno:
 On Mon, Aug 05, 2013 at 10:45:31AM +0200, Andreas Färber wrote:
 Am 05.08.2013 00:04, schrieb Aurélien Jarno:
 On Mon, Jul 29, 2013 at 10:35:31PM +0200, Stefan Weil wrote:
 Am 27.07.2013 22:58, schrieb Stefan Weil:
 Am 27.07.2013 22:43, schrieb Andreas Färber:
 Am 27.07.2013 21:37, schrieb Stefan Weil:
 Am 27.07.2013 19:43, schrieb Peter Maydell:
 On 27 July 2013 17:18, Hervé Poussineau hpous...@reactos.org wrote:
 Another solution would be to add a big dummy memory regions on all 
 MIPS boards
 to catch memory accesses and not raise an exception. However, this 
 means that
 each MIPS board will have its own unassigned memory handler, 
 different from the
 global QEMU one.
 Better would be to at least provide fake RAZ/WI implementations of
 devices for the boards, rather than making the dummy region cover
 the whole of the address space. Not 1.6 material, though.


 For MIPS Malta, Linux boot can be fixed by handling read access for two
 addresses:

 0x1fbf8008
 0x1bc80110

 The corresponding definitions in the Linux kernel code seem to be these
 lines:

 #define GCMP_BASE_ADDR  0x1fbf8000
 #define GCMP_ADDRSPACE_SZ   (256 * 1024)
 #define GCMP_GCB_GCMPB_OFS  0x0008  /* Global GCMP
 Base */

 #define MSC01_BIU_REG_BASE  0x1bc8
 #define MSC01_BIU_ADDRSPACE_SZ  (256 * 1024)
 #define MSC01_SC_CFG_OFS0x0110

 = mips_malta.c needs a handler for reads of
 (GCMP_BASE_ADDR + GCMP_GCB_GCMPB_OFS) and
 (MSC01_BIU_REG_BASE + MSC01_SC_CFG_OFS).

 I don't think it would be correct to emulate them as this are not
 present on the real Malta board, at least for the model emulated by
 QEMU. Theses addresses correspond to the SMP controller, and is
 therefore only present when an SMP daughter card is installed.

 The Linux kernel probes theses addresses, and look if they return
 something consistent. If not the corresponding devices are latter
 ignored.

 The real hardware probably returns all 1 or all 0 for addresses not
 decoded to a device. This is what QEMU should model, and it should
 not trigger a DBE or IBE exception.
 [snip]

 Have you tested Jan's patches limiting the new unassigned read value -1
 to PIO?

 
 I have tried this patches, and they don't fix the problem.

Too bad. So what do you propose? Restoring #ifdef and using
empty_slot_init() have been suggested so far, any other concrete ideas?

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH for-1.6] target-mips: do not raise exceptions when accessing invalid memory

2013-08-05 Thread Hervé Poussineau 

Andreas Färber a écrit :

[snip]

Have you tested Jan's patches limiting the new unassigned read value -1
to PIO?


I have tried this patches, and they don't fix the problem.


Too bad. So what do you propose? Restoring #ifdef and using
empty_slot_init() have been suggested so far, any other concrete ideas?


Another idea (not tested): override the CPUClass-do_unassigned_level on 
board level, to only raise IBE and no DBE.
That way, right behaviour is kept in global code, and bad code is only 
at board level, where it can be removed later board after board.


Hervé

Re: [Qemu-devel] [PATCH for-1.6] target-mips: do not raise exceptions when accessing invalid memory

2013-08-05 Thread Aurélien Jarno 
On Mon, Aug 05, 2013 at 03:53:08PM +0200, Hervé Poussineau wrote:
 Andreas Färber a écrit :
 [snip]
 
 Have you tested Jan's patches limiting the new unassigned read value -1
 to PIO?
 
 I have tried this patches, and they don't fix the problem.
 
 Too bad. So what do you propose? Restoring #ifdef and using
 empty_slot_init() have been suggested so far, any other concrete ideas?
 
 Another idea (not tested): override the
 CPUClass-do_unassigned_level on board level, to only raise IBE and
 no DBE.
 That way, right behaviour is kept in global code, and bad code is
 only at board level, where it can be removed later board after
 board.

The problem is that it looks like the code is not bad. It seems that
real hardware just ignore such accesses, so this should stay forever.



-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net

Re: [Qemu-devel] [PATCH for-1.6] target-mips: do not raise exceptions when accessing invalid memory

2013-08-05 Thread Peter Maydell 
On 5 August 2013 15:07, Aurélien Jarno aurel...@aurel32.net wrote:
 On Mon, Aug 05, 2013 at 03:53:08PM +0200, Hervé Poussineau wrote:
 Another idea (not tested): override the
 CPUClass-do_unassigned_level on board level, to only raise IBE and
 no DBE.

This sounds like a bit of a layering violation...

 That way, right behaviour is kept in global code, and bad code is
 only at board level, where it can be removed later board after
 board.

 The problem is that it looks like the code is not bad. It seems that
 real hardware just ignore such accesses, so this should stay forever.

But this is just board level behaviour, right? So the right
place to implement it is definitely in the board model.
If this is how the board works I think my first try would
be to have the board register a background region covering
the whole system memory space which returns 0 or -1 or whatever
the board does.

-- PMM

Re: [Qemu-devel] [PATCH for-1.6] target-mips: do not raise exceptions when accessing invalid memory

2013-08-04 Thread Aurélien Jarno 
On Mon, Jul 29, 2013 at 10:35:31PM +0200, Stefan Weil wrote:
 Am 27.07.2013 22:58, schrieb Stefan Weil:
  Am 27.07.2013 22:43, schrieb Andreas Färber:
  Am 27.07.2013 21:37, schrieb Stefan Weil:
  Am 27.07.2013 19:43, schrieb Peter Maydell:
  On 27 July 2013 17:18, Hervé Poussineau hpous...@reactos.org wrote:
  Another solution would be to add a big dummy memory regions on all MIPS 
  boards
  to catch memory accesses and not raise an exception. However, this 
  means that
  each MIPS board will have its own unassigned memory handler, different 
  from the
  global QEMU one.
  Better would be to at least provide fake RAZ/WI implementations of
  devices for the boards, rather than making the dummy region cover
  the whole of the address space. Not 1.6 material, though.
 
 
 For MIPS Malta, Linux boot can be fixed by handling read access for two
 addresses:
 
 0x1fbf8008
 0x1bc80110

 The corresponding definitions in the Linux kernel code seem to be these
 lines:
 
 #define GCMP_BASE_ADDR  0x1fbf8000
 #define GCMP_ADDRSPACE_SZ   (256 * 1024)
 #define GCMP_GCB_GCMPB_OFS  0x0008  /* Global GCMP
 Base */
 
 #define MSC01_BIU_REG_BASE  0x1bc8
 #define MSC01_BIU_ADDRSPACE_SZ  (256 * 1024)
 #define MSC01_SC_CFG_OFS0x0110
 
 = mips_malta.c needs a handler for reads of
 (GCMP_BASE_ADDR + GCMP_GCB_GCMPB_OFS) and
 (MSC01_BIU_REG_BASE + MSC01_SC_CFG_OFS).

I don't think it would be correct to emulate them as this are not
present on the real Malta board, at least for the model emulated by
QEMU. Theses addresses correspond to the SMP controller, and is
therefore only present when an SMP daughter card is installed.

The Linux kernel probes theses addresses, and look if they return
something consistent. If not the corresponding devices are latter
ignored.

The real hardware probably returns all 1 or all 0 for addresses not
decoded to a device. This is what QEMU should model, and it should
not trigger a DBE or IBE exception. Looking at the current MIPS
documentation, Bus Error is defined as:

  A bus error exception occurs when an instruction or data access makes a
  bus request (due to a cache miss or an  uncacheable reference) and
  that request terminates in an error.

Older CPU documentation like the R4000 have a more precise definition:

  A Bus Error exception is raised by board-level circuitry for events such
  as bus time-out, backplane bus parity errors, and invalid physical memory
  addresses or access types.

As we don't model this kind of errors, we should definitely just not
trigger an exception in that case, and even logging the event as
unimplemented is probably wrong.

-- 
Aurelien Jarno  GPG: 1024D/F1BCDB73
aurel...@aurel32.net http://www.aurel32.net

Re: [Qemu-devel] [PATCH for-1.6] target-mips: do not raise exceptions when accessing invalid memory

2013-08-04 Thread Peter Maydell 
On 4 August 2013 23:04, Aurélien Jarno aurel...@aurel32.net wrote:
 The real hardware probably returns all 1 or all 0 for addresses not
 decoded to a device. This is what QEMU should model, and it should
 not trigger a DBE or IBE exception. Looking at the current MIPS
 documentation, Bus Error is defined as:

   A bus error exception occurs when an instruction or data access makes a
   bus request (due to a cache miss or an  uncacheable reference) and
   that request terminates in an error.

 Older CPU documentation like the R4000 have a more precise definition:

   A Bus Error exception is raised by board-level circuitry for events such
   as bus time-out, backplane bus parity errors, and invalid physical memory
   addresses or access types.

 As we don't model this kind of errors, we should definitely just not
 trigger an exception in that case, and even logging the event as
 unimplemented is probably wrong.

Well, we certainly can model invalid-physical-address and
bus-timeout where that's what the board does for accesses
to non-decoded addresses; but presumably in this case it
doesn't...

-- PMM

Re: [Qemu-devel] [PATCH for-1.6] target-mips: do not raise exceptions when accessing invalid memory

2013-08-04 Thread Stefan Weil 
Am 05.08.2013 00:37, schrieb Peter Maydell:
 On 4 August 2013 23:04, Aurélien Jarno aurel...@aurel32.net wrote:
 The real hardware probably returns all 1 or all 0 for addresses not
 decoded to a device. This is what QEMU should model, and it should
 not trigger a DBE or IBE exception. Looking at the current MIPS
 documentation, Bus Error is defined as:

   A bus error exception occurs when an instruction or data access makes a
   bus request (due to a cache miss or an  uncacheable reference) and
   that request terminates in an error.

 Older CPU documentation like the R4000 have a more precise definition:

   A Bus Error exception is raised by board-level circuitry for events such
   as bus time-out, backplane bus parity errors, and invalid physical memory
   addresses or access types.

 As we don't model this kind of errors, we should definitely just not
 trigger an exception in that case, and even logging the event as
 unimplemented is probably wrong.
 Well, we certainly can model invalid-physical-address and
 bus-timeout where that's what the board does for accesses
 to non-decoded addresses; but presumably in this case it
 doesn't...

 -- PMM

Is there anybody who has access to physical Malta hardware?
It would be interesting to see whether there is an exception
during the gcmp test or not.

With latest QEMU, the MIPS Malta system emulation starts
handling the exception caused by the gcmp test, but then
gets a second exception which is fatal (see below).

There might be something missing in our very simple bios
emulation.

= If real hardware triggers an exception, then fixing the
bios emulation would be the correct way to handle this in
QEMU.

Stefan




[0.00] CPU 0 Unable to handle kernel paging request at virtual
address 0048, epc == 80100f74, ra == 80107f1c
[0.00] Oops[#1]:
[0.00] Cpu 0
[0.00] $ 0   :  1000 f800 
[0.00] $ 4   : 804edeb8  8051684c 
[0.00] $ 8   : 1000 101f 8f5b 277b0001
[0.00] $12   : af5b 8054  4218
[0.00] $16   :  804edeb8 0002 0004
[0.00] $20   :    8054
[0.00] $24   :  8010f7f0 
[0.00] $28   : 804ec000 804edd38  80107f1c
[0.00] Hi: 
[0.00] Lo: 
[0.00] epc   : 80100f74 malta_be_handler+0x4c/0x224 Not tainted
[0.00] ra: 80107f1c do_be+0x11c/0x1ac
[0.00] Status: 1002KERNEL EXL
[0.00] Cause : 0088
[0.00] BadVA : 0048
[0.00] PrId  : 00019000 (MIPS 4KEc)
[0.00] Modules linked in:
[0.00] Process swapper (pid: 0, threadinfo=804ec000,
task=804ee168, tls=)
[0.00] Stack :  0001  0002 0400
802ae1c0 804eded0 804edeee
[0.00]  804eded4 0006 0001 804edee8
804edf06  804edeec
[0.00] 0006 0001 8050  804edf08
804edf26  804edf0c
[0.00] 0006 0001 8050  7fb120e3
802ae1c0 802ae2a4 0002
[0.00]  0002 000a 0006 
0001 0775 0775
[0.00] ...
[0.00] Call Trace:
[0.00] [80100f74] malta_be_handler+0x4c/0x224
[0.00] [80107f1c] do_be+0x11c/0x1ac
[0.00] [80101900] ret_from_exception+0x0/0x24
[0.00] [8051684c] gcmp_probe+0x38/0xa0
[0.00] [805168dc] arch_init_irq+0x28/0x124
[0.00] [8050eb10] start_kernel+0x1d4/0x400
[0.00] [80433cb0] kernel_entry+0x0/0x90

Re: [Qemu-devel] [PATCH for-1.6] target-mips: do not raise exceptions when accessing invalid memory

2013-07-29 Thread Stefan Weil 
Am 27.07.2013 22:58, schrieb Stefan Weil:
 Am 27.07.2013 22:43, schrieb Andreas Färber:
 Am 27.07.2013 21:37, schrieb Stefan Weil:
 Am 27.07.2013 19:43, schrieb Peter Maydell:
 On 27 July 2013 17:18, Hervé Poussineau hpous...@reactos.org wrote:
 Another solution would be to add a big dummy memory regions on all MIPS 
 boards
 to catch memory accesses and not raise an exception. However, this means 
 that
 each MIPS board will have its own unassigned memory handler, different 
 from the
 global QEMU one.
 Better would be to at least provide fake RAZ/WI implementations of
 devices for the boards, rather than making the dummy region cover
 the whole of the address space. Not 1.6 material, though.


For MIPS Malta, Linux boot can be fixed by handling read access for two
addresses:

0x1fbf8008
0x1bc80110

The corresponding definitions in the Linux kernel code seem to be these
lines:

#define GCMP_BASE_ADDR  0x1fbf8000
#define GCMP_ADDRSPACE_SZ   (256 * 1024)
#define GCMP_GCB_GCMPB_OFS  0x0008  /* Global GCMP
Base */

#define MSC01_BIU_REG_BASE  0x1bc8
#define MSC01_BIU_ADDRSPACE_SZ  (256 * 1024)
#define MSC01_SC_CFG_OFS0x0110

= mips_malta.c needs a handler for reads of
(GCMP_BASE_ADDR + GCMP_GCB_GCMPB_OFS) and
(MSC01_BIU_REG_BASE + MSC01_SC_CFG_OFS).

Regards,

Stefan W.

[Qemu-devel] [PATCH for-1.6] target-mips: do not raise exceptions when accessing invalid memory

2013-07-27 Thread Hervé Poussineau 
c658b94f6e8c206c59d02aa6fbac285b86b53d2c (cpu: Turn cpu_unassigned_access()
into a CPUState hook) made MIPS raise exceptions when accessing
invalid memory for data, by unconditionally calling CPUState unassigned hook.

While this seems to be the right behaviour, this breaks a lot of guests
(Linux on Malta, NetBSD on Magnum...) which try to access not emulated devices
and crash because they don't handle the data load/store exception.

Revert to previous behaviour by not handling the !is_exec case in MIPS CPU hook.

Signed-off-by: Hervé Poussineau hpous...@reactos.org
---

Another solution would be to add a big dummy memory regions on all MIPS boards
to catch memory accesses and not raise an exception. However, this means that
each MIPS board will have its own unassigned memory handler, different from the
global QEMU one.

---
 target-mips/op_helper.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/target-mips/op_helper.c b/target-mips/op_helper.c
index 5cf1c3f..94f1692 100644
--- a/target-mips/op_helper.c
+++ b/target-mips/op_helper.c
@@ -2156,7 +2156,8 @@ void mips_cpu_unassigned_access(CPUState *cs, hwaddr addr,
 if (is_exec) {
 helper_raise_exception(env, EXCP_IBE);
 } else {
-helper_raise_exception(env, EXCP_DBE);
+qemu_log_mask(LOG_UNIMP, should raise DBE exception 
+  due to accessing memory at % HWADDR_PRIx \n, addr);
 }
 }
 #endif /* !CONFIG_USER_ONLY */
-- 
1.7.10.4

Re: [Qemu-devel] [PATCH for-1.6] target-mips: do not raise exceptions when accessing invalid memory

2013-07-27 Thread Andreas Färber 
Am 27.07.2013 18:18, schrieb Hervé Poussineau:
 c658b94f6e8c206c59d02aa6fbac285b86b53d2c (cpu: Turn cpu_unassigned_access()
 into a CPUState hook) made MIPS raise exceptions when accessing
 invalid memory for data, by unconditionally calling CPUState unassigned hook.
 
 While this seems to be the right behaviour, this breaks a lot of guests
 (Linux on Malta, NetBSD on Magnum...) which try to access not emulated devices
 and crash because they don't handle the data load/store exception.
 
 Revert to previous behaviour by not handling the !is_exec case in MIPS CPU 
 hook.
 
 Signed-off-by: Hervé Poussineau hpous...@reactos.org

So before my refactoring the following targets called it in files...

alpha: cputlb.c and memory.c
microblaze: memory.c
mips: cputlb.c
sparc: cputlb.c and memory.c

... and now all four call it in both places, breaking mips.

The proposed solution looks acceptable to me, but I am no mips expert;
CC'ing Aurélien, Stefan and some Imagination guys.

As a reminder, 1.6-rc0 is due on Monday.

 ---
 
 Another solution would be to add a big dummy memory regions on all MIPS boards
 to catch memory accesses and not raise an exception. However, this means that
 each MIPS board will have its own unassigned memory handler, different from 
 the
 global QEMU one.

sparc uses the empty_slot device to catch accesses to devices that we
are not yet emulating IIUC. I.e., empty_slot_init(addr, size).

Peter/Edgar, can you double-check whether calling the unassigned_access
handler from cputlb.c rather than cpu_abort()ing is OK for microblaze?

Thanks,
Andreas

 ---
  target-mips/op_helper.c |3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
 
 diff --git a/target-mips/op_helper.c b/target-mips/op_helper.c
 index 5cf1c3f..94f1692 100644
 --- a/target-mips/op_helper.c
 +++ b/target-mips/op_helper.c
 @@ -2156,7 +2156,8 @@ void mips_cpu_unassigned_access(CPUState *cs, hwaddr 
 addr,
  if (is_exec) {
  helper_raise_exception(env, EXCP_IBE);
  } else {
 -helper_raise_exception(env, EXCP_DBE);
 +qemu_log_mask(LOG_UNIMP, should raise DBE exception 
 +  due to accessing memory at % HWADDR_PRIx \n, addr);
  }
  }
  #endif /* !CONFIG_USER_ONLY */
 


-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH for-1.6] target-mips: do not raise exceptions when accessing invalid memory

2013-07-27 Thread Peter Maydell 
On 27 July 2013 17:18, Hervé Poussineau hpous...@reactos.org wrote:
 Another solution would be to add a big dummy memory regions on all MIPS boards
 to catch memory accesses and not raise an exception. However, this means that
 each MIPS board will have its own unassigned memory handler, different from 
 the
 global QEMU one.

Better would be to at least provide fake RAZ/WI implementations of
devices for the boards, rather than making the dummy region cover
the whole of the address space. Not 1.6 material, though.

-- PMM

Re: [Qemu-devel] [PATCH for-1.6] target-mips: do not raise exceptions when accessing invalid memory

2013-07-27 Thread Andreas Färber 
Am 27.07.2013 21:37, schrieb Stefan Weil:
 Am 27.07.2013 19:43, schrieb Peter Maydell:
 On 27 July 2013 17:18, Hervé Poussineau hpous...@reactos.org wrote:
 Another solution would be to add a big dummy memory regions on all MIPS 
 boards
 to catch memory accesses and not raise an exception. However, this means 
 that
 each MIPS board will have its own unassigned memory handler, different from 
 the
 global QEMU one.
 Better would be to at least provide fake RAZ/WI implementations of
 devices for the boards, rather than making the dummy region cover
 the whole of the address space. Not 1.6 material, though.
 
 I prefer keeping the correct code for target-mips/op_helper.c
 and adding either the big dummy memory regions or fake
 device implementations (both with TODO comments) for 1.6.

The problem I see with that is, so far no one has stepped up with a list
of what memory ranges / devices we are talking about.

The simplest for 1.6 might be to re-add an #ifndef TARGET_MIPS around
the refactored call to restore old behavior.

Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg

Re: [Qemu-devel] [PATCH for-1.6] target-mips: do not raise exceptions when accessing invalid memory

2013-07-27 Thread Stefan Weil 
Am 27.07.2013 19:43, schrieb Peter Maydell:
 On 27 July 2013 17:18, Hervé Poussineau hpous...@reactos.org wrote:
 Another solution would be to add a big dummy memory regions on all MIPS 
 boards
 to catch memory accesses and not raise an exception. However, this means that
 each MIPS board will have its own unassigned memory handler, different from 
 the
 global QEMU one.
 Better would be to at least provide fake RAZ/WI implementations of
 devices for the boards, rather than making the dummy region cover
 the whole of the address space. Not 1.6 material, though.

 -- PMM

I prefer keeping the correct code for target-mips/op_helper.c
and adding either the big dummy memory regions or fake
device implementations (both with TODO comments) for 1.6.

It would also be acceptable to fix the boards in 1.6.1 and add
a comment to the 1.6 release notes about the regression.

Stefan

Re: [Qemu-devel] [PATCH for-1.6] target-mips: do not raise exceptions when accessing invalid memory

2013-07-27 Thread Peter Maydell 
On 27 July 2013 21:43, Andreas Färber afaer...@suse.de wrote:
 Am 27.07.2013 21:37, schrieb Stefan Weil:
 Am 27.07.2013 19:43, schrieb Peter Maydell:
 On 27 July 2013 17:18, Hervé Poussineau hpous...@reactos.org wrote:
 Another solution would be to add a big dummy memory regions on all MIPS 
 boards
 to catch memory accesses and not raise an exception. However, this means 
 that
 each MIPS board will have its own unassigned memory handler, different 
 from the
 global QEMU one.
 Better would be to at least provide fake RAZ/WI implementations of
 devices for the boards, rather than making the dummy region cover
 the whole of the address space. Not 1.6 material, though.

 I prefer keeping the correct code for target-mips/op_helper.c
 and adding either the big dummy memory regions or fake
 device implementations (both with TODO comments) for 1.6.

 The problem I see with that is, so far no one has stepped up with a list
 of what memory ranges / devices we are talking about.

Yeah, that was what I meant with my comment about providing
fake devices being not 1.6. Longer term if nobody
cares enough about the boards to dig up enough info to do this
then maybe we should drop the board models, but for 1.6 trying
to get that right for all the affected boards in the time we
have seems a bit risky.

 The simplest for 1.6 might be to re-add an #ifndef TARGET_MIPS around
 the refactored call to restore old behavior.

The advantage of adding single whole-space RAZ/WI regions
for each affected board is that then we can fix them up
one at a time to be more discriminating about how much
space they do this for. A single ifdef would certainly
be simpler though.

-- PMM

Re: [Qemu-devel] [PATCH for-1.6] target-mips: do not raise exceptions when accessing invalid memory

2013-07-27 Thread Stefan Weil 
Am 27.07.2013 22:43, schrieb Andreas Färber:
 Am 27.07.2013 21:37, schrieb Stefan Weil:
 Am 27.07.2013 19:43, schrieb Peter Maydell:
 On 27 July 2013 17:18, Hervé Poussineau hpous...@reactos.org wrote:
 Another solution would be to add a big dummy memory regions on all MIPS 
 boards
 to catch memory accesses and not raise an exception. However, this means 
 that
 each MIPS board will have its own unassigned memory handler, different 
 from the
 global QEMU one.
 Better would be to at least provide fake RAZ/WI implementations of
 devices for the boards, rather than making the dummy region cover
 the whole of the address space. Not 1.6 material, though.
 I prefer keeping the correct code for target-mips/op_helper.c
 and adding either the big dummy memory regions or fake
 device implementations (both with TODO comments) for 1.6.
 The problem I see with that is, so far no one has stepped up with a list
 of what memory ranges / devices we are talking about.

 The simplest for 1.6 might be to re-add an #ifndef TARGET_MIPS around
 the refactored call to restore old behavior.

 Andreas

Hervé's patch or the big dummy memory region can be used to get
the memory addresses in a certain test scenario from log messages.

These addresses can then be added as undefined devices with a TODO comment.

I might send a fix for MIPS Malta which gets Linux working again,
but maybe not before 1.6.1.

Stefan