Avi Kivity wrote:
>
>> In theory yes. But we didn't observe this so far. Xen with this
>> feature with same assumption works for quit a long time.
>> Also given that we are using global shadow page table, so probably
>> we have to take this assumption :-)
>> 
> 
> We can workaround this by disabling the optimization when a guest has
> different addresses for the lapic.

Yes, this is a perfect solution, not only a workaround though a little
bit complex:-)

> 
> But I agree there's no need to do that now.
> 

Taking this chance to brainstorming what is the direction of slot
structure and
VT-d support. In later case, we have to generate a P2M (gpa to hpa or
mpa) table
eventually. This table won't replace slot data structure since we still
need 
struct page * some place, but it will help gpa_to_hpa search. Do u have
any 
solid idea right now? My suggestion is to add additional P2M table and
restructure
shadow code to use P2M table for most frequent APIs which will help
performance.

Increasing slot number will simply reduce performance of slot table :-(

thx,eddie

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
kvm-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Reply via email to