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: Avi Kivity
Subject: Re: [Qemu-devel] Memory API: handling unassigned physical memory
Date: Mon, 30 Apr 2012 11:41:12 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

On 04/29/2012 10:35 PM, Anthony Liguori 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.

Yes.  I think it's even possible to do this now, you can create an mmio
region for the bus and add subregions to it.  All subregions
automatically overlap the container region.

Simply replace

  memory_region_init(&bus->address_space, ...)
  memory_region_add_subregion(&bus->address_space, addr, &dev->mmio)

with

  memory_region_init_io(&bus->address_space, &bus_nodev_ops, bus, ...)
  memory_region_add_subregion(&bus->address_space, addr, &dev->mmio) //
unchanged

This was never used so it hasn't been tested, but the code was written
with it in mind.  I didn't want to document this so we could back out of
it, but if it's useful, let's use it.

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

Note that real hardware varies within the board.  Different buses can
take different actions (and possibly even be reconfigured at runtime).

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

Unneeded, see above.  And remember, every time you need something from
the memory API, look at a window system.  In this case, we're replacing
a transparent container window with an opaque one.

Note that this may have side effects if the container region overlaps
another region with higher priority.  It's unlikely, but 'info mtree' is
recommended before use.

-- 
error compiling committee.c: too many arguments to function




reply via email to

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