Re: [PATCH 0/5] KVM paravirt_ops implementation

Zachary Amsden
2007-06-20T20:03:55Z

Anthony Liguori wrote:
> Zachary Amsden wrote:
>> Jeremy Fitzhardinge wrote:
>>> Anthony Liguori wrote:
>>>
>>>> I don't agree that having paravirt_ops within a normal module is all
>>>> that useful. By the time modules can be loaded, the kernel has
>>>> completely booted. There should only be a handful of paravirt_ops
>>>> implementations and they aren't large so I don't think there's a big
>>>> size savings either.
>>>>
>>>
>>> It doesn't seem terribly valuable to me either. But Zach is talking
>>> about something very similar to the kvm case, where you have a fully
>>> virtualized environment (with hardware support), but then you load a
>>> module containing paravirtualized helpers at some late stage which
>>> makes
>>> things more efficient but isn't required for functional correctness.
>>>
>>
>> Yes, the value isn't the space savings - it's the ability to include
>> paravirtualized driver support for Xen, KVM, VMI, lhype - which need
>> not be compiled in, but can now be modules in a ramdisk. The goal is
>> minimal effort for a single bootable image which works across native
>> and all virtualization environments.
>
> But what's the value in having it not in the kernel? Let's take Xen
> and lhype out of the picture because it clearly has to be there for
> them. You have a little less in the kernel now but then your kernel
> boots more slowly. There's already a noticable difference in
> boot-time with the KVM paravirt_ops implementation. I imagine there
> is for VMI too.

If it isn't compiled in the core kernel, then a distro need not do
anything special to distribute VMI or KVM support - other than compile
support for paravirt-ops. Then the paravirt-ops module can be installed
along with the guest tools and drivers, but need not be on install media.

Basically, it just makes it easier on distributors and allows any old
kernel with paravirt-ops module support to run on any modern, new
hypervisor - that might not have even existed at the time the distro was
created.

>
> In the case of KVM, the paravirt_ops implementation is orthogonal to
> paravirt device drivers. A PV device driver can happily exist even if
> the paravirt_ops backend isn't activated. This is assuming that
> hypercalls aren't used btw. If hypercalls are desirable to use, then
> the paravirt_ops backend would have to EXPORT_GPL the hypercall
> interface. I imagine returning a specific errno would suffice.

I'm mostly in agreement on that - although making dual hypercall / I/O
emulated drivers is a bit more work.

Zach