Alok Kataria wrote: > On Wed, 2008-10-01 at 11:04 -0700, Jeremy Fitzhardinge wrote: > > 2. Divergence in the interface provided by the hypervisors : > The reason we brought up a flat hierarchy is because we think we should > be moving towards a approach where the guest code doesn't diverge too > much when running under different hypervisors. That is the guest > essentially does the same thing if its running on say Xen or VMware. > > This design IMO, will take us a step backward to what we already have > seen with para virt ops. Each hypervisor (mostly) defines its own cpuid > block, the guest correspondingly needs to have code to handle each of > these cpuid blocks, with these blocks will mostly being exclusive. > What's wrong with what we have in paravirt_ops? Just agreeing on CPUID doesn't help very much. You still need a mechanism for doing hypercalls to implement anything meaningful. We aren't going to agree on a hypercall mechanism. KVM uses direct hypercall instructions, Xen uses a hypercall page, VMware uses VMI, Hyper-V uses MSR writes. We all have already defined the hypercall namespace in a certain way. We've already gone down the road of trying to make standard paravirtual interfaces (via virtio). No one was sufficiently interested in collaborating. I don't see why other paravirtualizations are going to be much different. Regards, Anthony Liguori _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
