On 04/29/2012 03:09 PM, Blue Swirl wrote:
On Sun, Apr 29, 2012 at 19:35, Anthony Liguori<anth...@codemonkey.ws>  wrote:
On 04/29/2012 12:25 PM, Mark Cave-Ayland wrote:


Hi all,

I've been having a look at handling SBUS probes within qemu-system-sparc
when I
came across a very simple crash bug with git master trying to access
unassigned
physical addresses:

(qemu) info mtree
memory
0000000000000000-7ffffffffffffffe (prio 0, RW): system
0000000000000000-0000000007ffffff (prio 0, RW): sun4m.ram
0000000008000000-000000000fffffff (prio 0, RW): empty-slot
0000000010000000-0000000010003fff (prio 0, RW): iommu
0000000010004000-000000001fffefff (prio 0, RW): empty-slot
0000000050200000-000000005020000f (prio 0, RW): tcx.dac
...
...

AFAICT the devices are mapped to physical addresses (uandsing
sysbus_mmio_map)
so the xp monitor command should be able to at least read these regions:

(qemu) xp 0x50200000
0000000050200000: 0x00000000
(qemu) xp 0x501ffff0
Segmentation fault

There is definitely a QEMU bug here in that an incorrect physical memory
access
shouldn't segfault QEMU. However some off-list discussions with Blue
suggested
that it may be possible to defer this behaviour to the memory API (rather
than
in exec.c) by allowing boards to register a simple device to handle
unassigned
memory accesses, e.g. like the empty_slot device used to trap certain
memory
accesses within SPARC.


What does real hardware do?  Does hardware assert a line if an invalid MMIO
request is generated?

I think the SBus controller (in IOMMU) detects a timeout if no device
responds to MMIO and raises an IRQ, same as with other bus errors.

I see, so it's similar to ISA. The memory API assumes positive decoding and I think the best way we have to cope with this is to register overlapped regions with the "default" region having a lower priority than anything that sits on top of it.

Would be nice to have a way to mark a MemoryRegion as allowing overlap even if you add a subregion without using memory_region_add_subregion_overlap().

Regards,

Anthony Liguori





This would enable us to easily solve the problem for SPARC since we could
create
a parent memory region for the entire physical address space that would
simply
update the status register and raise the required IRQ. Is this the best
way to
solve the problem or is there something else that I've missed?


I think you want to look at memory_region_add_subregion_overlap().

Regards,

Anthony Liguori



Many thanks,

Mark.





Reply via email to