Zachary Amsden wrote: > Yes, but if we want to stay with that forward compatibility story, we > need a way to allow paravirt device probing to be completely > orthogonal to paravirt-ops probing. Either the VMware hypervisor > needs to NOT implement a CPUID leaf, keeping the same ROM based > detection, or other VMI client drivers (say, as a wild example, a KVM > driver running on a VMI to KVM paravirt-ops backend) need not to check > CPUID leaf as a condition of execution.
Yes, this is something that keeps coming up. hpa originally floated the idea of reserving some PCI bus namespace as a gateway for probing for virtual/paravirtual devices, and Jun Nakajima proposed it again in the context of smart hardware which is virtualization friendly (ie, how to represent PCI-IOV to guests). I'm not wildly happy about the idea of using PCI for probing for otherwise completely non-PCI devices, but some kind of probing mechanism might be nice in the general case. Xen deals with it with Xenbus, but I figure I'm unlikely to convince everyone to adopt that. > We at least would like to use a CPUID leaf for the core paravirt-ops > on 64-bit and get rid of the need for ROM probing in that case, which > would mean we either need a CPUID sub-leaf for the device model, a > completely identical device model, or completely orthogonal device > probing. Well, cpuid leaf 0x40000000 seems to be gaining currency as a (semi-?)formal way for hypervisors to advertise themselves, so that seems completely doable. > Since there hasn't been a formal specification for how the device > probing should work, or, at least, I don't know all the details of how > device probing works for all the various hypervisors, I worry that > weird ad-hoc tests could trample the compatibility effort. Yes. That's the thinking behind using PCI as a somewhat common mechanism for device discovery. s390 folks hate it, of course. > The completely identical device model is of course ideal, but the > implementation and consolidation of that is a long term prospect to > move towards, not something that will happen immediately. We at least > emulate physical hardware devices already, and will continue to need > drivers compatible with those models for some time. Well, physical devices and completely emulated physical devices are fairly straightforward - do it like real hardware. Its the semi-virtual devices which pose problems. Either device emulations with a bit of performance paravirtualization sprinkled over them, or virtualization friendly devices which allow safe direct guest access, but need some paravirtual management interfaces as well. 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