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.
>> 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
