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. > > >> >> 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. >> > >
