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

[Avi Kivity]

On 05/18/2011 07:39 PM, Jan Kiszka wrote:
> >>
> >>  That's fine, but also requires a change how, or better where devices
> >>  register their regions.
> >
> >  Lost you - please elaborate.
>
> Devices currently register against the core, that's nothing your API
> automatically changes (though it lays the foundation to do so). But
> devices should rather register against the corresponding bus. The bus
> (ie. the device managing it) could then forward the request, stick it
> into a subregion, or have it for dinner.

Yes.  We'd change pci_register_bar() to accept a MemoryRegion.

> However, we are yet in troubles if we want to change that because
> devices can only be on one bus - at least so far.

Nothing prohibits a device from calling pci_register_bar() for one 
region and some other API for another.

btw, another motivation for this API is for dual ISA/PCI devices.  This 
way most of the work is bus agnostic, with just the actual registration 
being bus specific.

> ...
> >>  I'm specifically thinking of fully trackable slot updates. The clients
> >>  should not have to maintain the flat layout. They should just receive
> >>  updates in the form of slot X added/modified/removed. For now, this
> >>  magic happens multiple times in the clients, and that is very bad.
> >
> >  Slots don't have any meaning.  You can have a RAM region which is
> >  overlaid by a smaller mmio region ->  the RAM slot is split into two.
> >
> >  We should just send clients a list of ranges, and they can associate
> >  them with slots themselves.
>
> And that association logic should be as simple as matching a unique
> range ID against an existing slot (for updates and deletions) or adding
> a new slot for a new range and storing the ID. Anything else will not
> allow to simplify the existing code bases noticeably. That's my point.

We won't have a natural ID.  But I'll see if I can have a library 
calculate the minimum difference between the previous layout and current 
layout.  Should not be too hard.

> >
> >>  Given that not only memory clients need that view but that ever TLB miss
> >>  (in TCG mode) requires to identify the effective slot as well, it might
> >>  be worth preparing a runtime structure at registration time that
> >>  supports this efficiently - but this time without wasting memory.
> >
> >  Yes.  Won't be easy though.  Perhaps a perfect hash table for small
> >  regions and a sorted-by-size array for large regions.
>
> Keep in mind that TCG will be our benchmark for these changes as it
> requires much more accesses than KVM. We must avoid designing the new
> infrastructure with exclusive focus on KVM (and also x86).

I think TCG will not be affected much since it stores ram_addr_t's in 
its TLBs, so the lookup is only done on a TLB miss.  In fact there's a 
change for a slight win since we'll probably be able to keep the new 
layout in cache compared to phys_desc.

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