qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Blue Swirl
Subject: Re: [Qemu-devel] Memory API: handling unassigned physical memory
Date: Sun, 29 Apr 2012 20:09:45 +0000

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.

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

[Prev in Thread] Current Thread [Next in Thread]