Re: [Qemu-devel] Memory API: handling unassigned physical memory

[Anthony Liguori]

On 04/29/2012 03:09 PM, Blue Swirl wrote:
> On Sun, Apr 29, 2012 at 19:35, Anthony Liguori<address@hidden>  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.