Re: [Qemu-devel] [PATCH 0/4] VGA optimization

[Anthony Liguori <anthony@codemonkey.ws>]

Anthony Liguori wrote:
> Glauber Costa wrote:
>> hey guys,
>>   
>
> I gave you some bad advice that I think is causing the breakage I'm 
> seeing now.  I suggested that you simply do a lookup to find the slot 
> given a target_phys_addr_t but that isn't correct.  Let me explain why.

Except I'm completely backwards but at least consistently backwards :-)

Regards,

Anthony Liguori

> ram_addr_t represents a guest physical address.  From a ram_addr_t you 
> can get a target_phys_addr_t.  Sometimes these are the same but they 
> aren't always.
>
> You can have multiple ram_addr_t's pointing to the same 
> target_phys_addr_t.  This is ram aliasing and it happens for a variety 
> of reasons.  In general, it's pretty expensive to map a ram_addr_t to 
> a target_phys_addr_t because, among other things, for a range of 
> (ram_addr_t, size_t), you may have many (target_phys_addr_t, size) 
> tuples that you have to deal with.
>
> vga_common_init() takes a target_phys_addr_t (well, it really takes an 
> unsigned long, but that's a bug).  It takes this as an optimization.  
> It avoids having to do the conversion and ensures that it's one big 
> linear region.
>
> For dirty tracking, we have a bitmap indexed by target_phys_addr_t in 
> QEMU.  This means that we can happily set dirty bits based on 
> target_phys_addr_t's.  We don't have to worry about what ram_addr_t it 
> came from because they all map to the same bits.
>
> Since KVM uses a slot API, and that API is indexed in ram_addr_t's, we 
> need to enable dirty tracking on the ram_addr_t's.  We don't have a 
> ram_addr_t in the VGA code.
>
> The solution is pretty simple.  We need to keep track of the 
> ram_addr_t's in the VGA code and enable dirty tracking on the 
> appropriate ram_addr_ts.
>
> Regards,
>
> Anthony Liguori
>
>> I hope this is the last version (Of course, once this is merged,
>> the optimizations of the optimization can start ;-) )
>>
>> I split it in 4 patches. The first two ones are just moving
>> things out of the way, and then #3 and #4 do the real thing.
>> #3 kvm-side, #4 overall qemu.
>>
>> They merge most of the suggestion Anthony and Stefano's sent
>> on last iteration.
>>
>> Hope you like it.
>>  
>>
>>
>>
>>   
>