[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:09:07 +0300 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 |
On 05/01/2012 04:50 PM, Anthony Liguori wrote:
> On 05/01/2012 08:01 AM, Avi Kivity wrote:
>> On 05/01/2012 03:49 PM, Peter Maydell wrote:
>>> On 1 May 2012 13:48, Avi Kivity<address@hidden> wrote:
>>>> On 05/01/2012 03:43 PM, Peter Maydell wrote:
>>>>> On 1 May 2012 13:42, Avi Kivity<address@hidden> wrote:
>>>>>> sysbus should just die.
>>>>>
>>>>> Totally agreed. It's not going to go quietly though...
>>>>
>>>> Not if you keep suggesting workarounds when I tell unsuspecting
>>>> developers to qomify their devices.
>>>
>>> When QOM supports (1) exporting gpio signals and
>
> This is trivial. It'll come in as soon as 1.2 opens up. If folks
> want to start working on a branch with it:
>
> https://github.com/aliguori/qemu/tree/qom-pin.4
>
>>> (2) exporting memory regions, then it will be providing the
>>> main things that sysbus provides.
>
> This is a little tricky. Here's the problems I've encountered so far:
>
> a) A lot of devices need the equivalent of it_shift. it_shift affects
> how addresses are decoded and the size of the memory region. it_shift
> usually needs to be a device property.
>
> Since we need to know the size of the memory region to initialize it,
> we need to know the value of it_shift before we can initialize it
> which means we have to delay the initialization of the mmemory region
> until realize.
>
> 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.
What is the problem with delaying region initialization until realize?
>
> 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.
--
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, 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 <=
- 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, 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