Re: State of current pv_ops backend for KVM?

Avi Kivity
2007-05-29T14:28:49Z

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