Re: State of current pv_ops backend for KVM?

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

Anthony Liguori wrote:
>>>
>>> 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.
>
> The pv_ops implementation still has to deal with guest pfn => host pfn 
> translation.  This means that a guest has to be put into a special 
> mode for save/restore/migrate to work to ensure that no host pfn's are 
> on the stack or in registers.  Changing save/restore/migration to from 
> guest-transparent to guest-interactive is a big loss to me.

I think it can be done without guest awareness, by having a special code 
section where the translation is done.  The hypervisor can choose not to 
transfer control when rip points there.

>>> 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.
>
> There will most certainly be trade-offs, but I certainly don't expect 
> direct paging to beat out NPT/EPT in certain areas.

Sure.  Like I said, we'll need measurements to decide 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/