qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC] Memory API


From: Avi Kivity
Subject: Re: [Qemu-devel] [RFC] Memory API
Date: Thu, 19 May 2011 16:30:12 +0300
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b3pre Thunderbird/3.1.10

On 05/19/2011 04:26 PM, Jan Kiszka wrote:
On 2011-05-19 15:07, Avi Kivity wrote:
>  On 05/19/2011 04:03 PM, Jan Kiszka wrote:
>>  On 2011-05-19 15:00, Avi Kivity wrote:
>>>   On 05/19/2011 03:58 PM, Jan Kiszka wrote:
>>>>>
>>>>>    Eventually we may make the memory API a sub-API of qdev.  I don't want
>>>>>    to start with that however, the change is large enough already.
>>>>
>>>>   Touching all devices again at that point to change the way they register
>>>>   regions may not be the best approach. I would try to consolidate the
>>>>   refactoring work that affects the majority of device models.
>>>
>>>   The risk is that the entire work will be stalled if it requires too much
>>>   effort.
>>
>>  Then we could still switch one gear down, converting at least some
>>  exemplary devices completely to demonstrate that the API changes fit
>>  into the big picture.
>
>  My plan is:
>
>  - post RFC v1 with updated API in patch form
>  - RFC v2 with implementation + significant fraction of PC devices coverted
>  - PATCH v3 with full conversion an elimination of the old API

And when introducing hierarchical registration, we will have to go
through all of this once again. Plus the API may have to be changed
again if it does not fulfill all requirements of the hierarchical region
management. And we have no proof that it allows an efficient core
implementation.

This API *is* hierarchical registration. v2 will (hopefully) prove that it can be done efficiently.

What is missing is to make qdev and this API the same hierarchy.

Before touching any device at all, what about building the
infrastructure to manage and address memory regions hierarchically via
qdev first? That could be started on a green field, then applied to the
PC architecture, and finally rolled out for all.

I feel a lot less comfortable about it since it introduces more variables. It also means a full conversion is impossible.

While doing it in one pass reduces the total effort, it increases the risk IMO.

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




reply via email to

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