Re: State of current pv_ops backend for KVM?

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Anthony Liguori wrote:
> Avi Kivity wrote:
>> Anthony Liguori wrote:
>>> Howdy,
>>>
>>> Does anyone know what the state of a pv_ops backend for KVM is?  I 
>>> know Ingo has an implementation that implements CR3 caching but I 
>>> don't see any branches in Avi's git tree.
>>>
>>> Perhaps we should try for a simple pv_ops backend for 2.6.23 seeing 
>>> as how the host infrastructure is there?  I'd be willing to do some 
>>> leg work here... 
>>
>> I think we should aim for a full direct paging implementation, where 
>> the cr3 cache is just the cherry on top that makes context switches 
>> proceed at native speed.  Jun has a paper on it for OLS and I hope 
>> patches too.
>
> That's a bit more ambitious than I was thinking.  I would be very 
> happy with a pv timer, interrupt controller, and some basic CPU 
> optimizations.  I'm still not convinced the perf benefits of direct 
> paging justify the annoyances that come with it (guests being aware of 
> pfns).  

I thought that with paravirt_ops, all the awareness is limited to the 
paravirt implementation, and nothing in the core kernel is actually 
aware of host pfns.

pv timer and interrupt controller make a lot of sense, especially if 
steal timer functionality is included.

> This is especially true with NPT/EPT right around the corner.

It depends on the workload.  It was advanced (by Ingo) that NPT/EPT 
increase the tlb miss latency, which is important for steady-state 
workloads, whereas shadow and direct paging do not.  It will be 
interesting to measure this.

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


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/