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 > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
