Re: [PATCH 0/5] KVM paravirt_ops implementation

[Jeremy Fitzhardinge <jeremy-TSDbQ3PG+2Y@public.gmane.org>]

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/