On Wed, 2008-10-01 at 14:08 -0700, Anthony Liguori wrote: > 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? Your explanation below answers the question you raised, the problem being we need to have support for each of these different hypercall mechanisms in the kernel. I understand that this was the correct thing to do at that moment. But do we want to go the same way again for CPUID when we can make it generic (flat enough) for anybody to use it in the same manner and expose a generic interface to the kernel. > Just agreeing on CPUID > doesn't help very much. Yeah, nobody is removing any of the paravirt ops support. > 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. Thanks, Alok _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
