Re: State of current pv_ops backend for KVM?

Avi Kivity
2007-05-29T14:00:18Z

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