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: Jan Kiszka
Subject: Re: [Qemu-devel] [RFC] Memory API
Date: Thu, 19 May 2011 15:26:26 +0200
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

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.

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.

Jan

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



reply via email to

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