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