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

[Jan Kiszka <jan.kiszka@siemens.com>]

On 2011-05-19 15:30, Avi Kivity wrote:
> 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.

It may supports it, but most users will not use it like this. That comes
with consequent qdev integration. PCI is just an exception here as it
already provides some instantiation services.

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

If we are sure we can reasonably evolve from this conversion level and
it will still fit the final model, then we may take that route. If you
want to go that way, OK, let's see what v2 will bring. We should use the
meantime and try to further develop the long-term APIs.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux