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. >>> More importantly, now device drivers for virtual devices would have a >>> way to inquire into which set of paravirt-ops was loaded by having an >>> official registered interface rather than an ad-hoc (if xxx_running >>> == 1) mess, and now the paravirt driver modules are nicely decoupled >>> from the boot-strap code and can be loaded dynamically. >>> >> I'm not familiar with the particular problem here, but I don't think >> that driver modules should be checking to see what paravirt_ops is >> active. Each VMM has it's own discovery mechanism (KVM and Xen are >> both based on CPUID) so that seems like a much better method to use. >> > > I think he's referring to the xen/kvm/vmi paravirt implementation as a > "driver" here. I think. > > I don't know of any "if (xxx_running)" tests at present. > For a VMM which supports both full emulation and para-virtualization, testing CPUID leaves is not sufficient to determine applicability of a paravirt device driver. This only indicates the presence of the functionality, not the fact that the functionality has been activated. For 32-bit Xen, this might be an already assumed fact - but for VMI, KVM, and HV assisted Xen, which do support guests running without paravirt, you need a way to test whether the particular family of paravirt has been activated - for device drivers which assume paravirt semantics might well require this activation to work, or need to behave differently in an unactivated environment (emulate hypercalls with port I/O, for example). Thus, all the paravirt drivers as modules would need to test if (xen_running) or (vmi_enabled) or (kvm_active), and then all these symbols need to be exported, and now you have an ad-hoc activation detection system for each brand of paravirt. Better to have a standard interface, IMHO, where a paravirt-ops "parent" module gets registered and activated, and then well defined symbols to query that activation. You also have module dependencies between the parent and child which are nicely modeled with the module system (xenbus dependes on xen, vmitimer depends on vmi, etc..). Zach ------------------------------------------------------------------------- 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
