[Top][All Lists]
[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: |
Tue, 01 May 2012 17:26:55 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 |
On 05/01/2012 05:15 PM, Anthony Liguori wrote:
>>> I think a nice fix would be to make it_shift as memory region mutator
>>> and allow it to be set after initialization.
>>
>> Indeed I wanted to make it_shift as part of the memory core. But a
>> mutator? It doesn't change in real hardware, so this looks artificial.
>> So far all mutators really change at runtime.
>
>
> QOM has a concept of initialization and realize. You can change
> properties after initialization but not before realize.
>
> So as long as it_shift can be set after initialization but before
> realize (which I think is roughly memory_region_add_subregion) it
> doesn't need to be a mutator.
Ok, good.
>
>> What is the problem with delaying region initialization until realize?
>
> We need to initialize the MemoryRegion in order to expose it as a
> property. We want to do that during initialize. Here's an example:
>
> qom-create isa-i8259 foo
> qom-set /peripheral/foo/io it_shift 1
> qom-set /peripheral/foo/realize true
>
> For this to work, it_shift needs to be a QOM property of the "io"
> MemoryRegion. The MemoryRegion needs to be created in instance_init.
So it looks like we need two phase initialization for memory regions as
well?
Not so pretty.
>
>>> b) There's some duplication in MemoryRegions with respect to QOM.
>>> Memory regions want to have a name but with QOM they'll be addressable
>>> via a path. I go back and forth about how aggressively we want to
>>> refactor MemoryRegions.
>>
>> These days region names are purely for debugging. The ABI bit was moved
>> to a separate function.
>
> Fair enough.
>
> BTW, in the branch I've posted, I've got a number of memory API
> conversions or removal of legacy interfaces.
Nice. But you use get_system_io(), which is bad.
--
error compiling committee.c: too many arguments to function
- Re: [Qemu-devel] Memory API: handling unassigned physical memory, (continued)
- Re: [Qemu-devel] Memory API: handling unassigned physical memory, Peter Maydell, 2012/05/01
- Re: [Qemu-devel] Memory API: handling unassigned physical memory, Anthony Liguori, 2012/05/01
- Re: [Qemu-devel] Memory API: handling unassigned physical memory, Peter Maydell, 2012/05/01
- Re: [Qemu-devel] Memory API: handling unassigned physical memory, Anthony Liguori, 2012/05/01
- Re: [Qemu-devel] Memory API: handling unassigned physical memory, Peter Maydell, 2012/05/01
- Re: [Qemu-devel] Memory API: handling unassigned physical memory, Anthony Liguori, 2012/05/01
- Re: [Qemu-devel] Memory API: handling unassigned physical memory, Mark Cave-Ayland, 2012/05/01
- Re: [Qemu-devel] Memory API: handling unassigned physical memory, Peter Maydell, 2012/05/01
- Re: [Qemu-devel] Memory API: handling unassigned physical memory, Avi Kivity, 2012/05/01
- Re: [Qemu-devel] Memory API: handling unassigned physical memory, Anthony Liguori, 2012/05/01
- Re: [Qemu-devel] Memory API: handling unassigned physical memory,
Avi Kivity <=
- Re: [Qemu-devel] Memory API: handling unassigned physical memory, Anthony Liguori, 2012/05/01
Re: [Qemu-devel] Memory API: handling unassigned physical memory, Avi Kivity, 2012/05/01
Re: [Qemu-devel] Memory API: handling unassigned physical memory, Avi Kivity, 2012/05/01