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:53:49 +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:49 PM, Anthony Liguori wrote:
On 05/19/2011 08:30 AM, Avi Kivity wrote:
On 05/19/2011 04:26 PM, Jan Kiszka wrote:
On 2011-05-19 15:07, Avi Kivity wrote:

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.

We also need hierarchical dispatch. Priorities are just a weak attempt to emulate hierarchical dispatch but I don't think there's an improvement over a single dispatch table.

Hierarchical dispatch is simpler. You just need a simple list at each bus.


The API itself says nothing about whether the hierarchy is evaluated at run-time or registration time. We could easily have the implementation walk the memory hierarchy to dispatch an mmio.

However, RAM cannot be dispatched this way (we need to resolve which ranges are RAM when the regions are registered, not accessed) so a data structure that contains all of the information is mandatory.

Since the first implementation will use the existing cpu_physical_register_memory() API as a back-end, we'll end up with a flattened dispatch model (which I think is the right thing anyway).

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




reply via email to

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