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

[Avi Kivity <avi@redhat.com>]

On 05/18/2011 08:04 PM, Anthony Liguori wrote:
>> The TLBs map a virtual address to a ram_addr_t.
>
>
> It actually maps virtual address to host virtual addresses.  Virtual 
> addresses that map to I/O memory never get stored in the TLB.

They are stored.  Look at glue(io_read, SUFFIX) and its caller for example.

>
> You don't need separate I/O registration addresses in order to do 
> per-CPU dispatch provided that you route the dispatch routines through 
> the CPUs first.

Right, but you pay for an extra lookup which always fails.

>>> Overlapping regions can be handled differently at each level. For
>>> instance, if a PCI device registers an IO region to the same location
>>> as the APIC, the APIC always wins because the PCI bus will never see
>>> the access.
>>>
>>
>> That's inefficient, since you always have to traverse the hierarchy.
>
> Is efficiency really a problem here?  Besides, I don't think that's 
> really correct.  You're adding at most 2-3 extra function pointer 
> invocations.  I don't think you can really call that inefficient.

Well, you'll need something special for SMM as well.  Per-cpu memory map 
solves all that neatly.

>
>>> You cannot do this properly with a single dispatch table because the
>>> behavior depends on where in the hierarchy the I/O is being handled.
>>
>> You can. When you have a TLB miss, you walk the memory hierarchy (which
>> is per-cpu) and end up with a ram_addr_t which is stowed in the TLB
>> entry.
>
> I think we're overloading the term TLB.  Are you referring to 
> l1_phys_map as the TLB because I thought Jan was referring to the 
> actual emulated TLB that TCG uses?

env->iotlb.  For some reason I though this was folded into 
enc->tlb_table, but it isn't (should it be? saves a lookup).

>
>> Further accesses dispatch via this ram_addr_t, without taking the
>> cpu into consideration (the TLB is, after all, already per-cpu).
>>
>> Since each APIC will have its own ram_addr_t, we don't need per-cpu
>> dispatch.
>
> You need to have per-CPU l1_phys_maps which would result in quite a 
> lot of additional memory overhead.

This is predicated on a better lookup method, yes.

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