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
