[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: Anthony Liguori
Subject: Re: [Qemu-devel] Memory API: handling unassigned physical memory
Date: Tue, 01 May 2012 09:15:40 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20120329 Thunderbird/11.0.1

On 05/01/2012 09:09 AM, Avi Kivity wrote:
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:


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

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.

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.

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.


Anthony Liguori

reply via email to

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