Re: [PATCH 0/5] KVM paravirt_ops implementation

Anthony Liguori
2007-06-20T20:27:07Z

Jeremy Fitzhardinge wrote:
> Zachary Amsden wrote:
>> 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.
>
> Hey, isn't that what VMI's for? ;)
>
> I'd been thinking about the possibility of allowing the domain builder
> to provide a new paravirt_ops implementation to the booting kernel.
> It would be akin to a kernel module, in that its built for a specific
> kernel, but obviously run a lot earlier. But at this point I think
> the idea is too crack-ridden to be taken seriously.

I've been thinking about this wrt the hypercall page in KVM. The
problem is that in a model like KVM (or presumably VMI), migration gets
really difficult if you have anything but a trivial hypercall page since
the hypercall page will change after migration.

If you cannot guarantee the guest isn't executing code within the
hypercall page (or in your case, doing something with paravirt_ops),
then you cannot safely migrate.

Regards,

Anthony Liguori

>>> 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.
>
> Semi-paravirtualized real-hardware drivers seems like a difficult
> mishmash. I would hope we could deal with it with a virtio-like thing.
>
> J