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
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization
