Alok Kataria wrote:
> 1. Kernel complexity : Just thinking about the complexity that this will
> put in the kernel to handle these multiple ABI signatures and scanning
> all of these leaf block's is difficult to digest.
>
The scanning for the signatures is trivial; it's not a significant
amount of code. Actually implementing them is a different matter, but
that's the same regardless of where they are placed or how they're
discovered. After discovery its the same either way: there's a leaf
base with offsets from it.
> 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.
>
I guess, but the bulk of the uses of this stuff are going to be
hypervisor-specific. You're hard-pressed to come up with any other
generic uses beyond tsc. In general, if a hypervisor is going to put
something in a special cpuid leaf, its because there's no other good way
to represent it. Generic things are generally going to appear as an
emulated piece of the virtualized platform, in ACPI, DMI, a
hardware-defined cpuid leaf, etc...
> 3. Is their a need to do all this over engineering :
> Aren't we over engineering a simple interface over here. The point is,
> there are right now 256 cpuid leafs do we realistically think we are
> ever going to exhaust all these leafs. We are really surprised to know
> that people may think this space is small enough. It would be
> interesting to know what all use you might want to put cpuid for.
>
Look, if you want to propose a way to use that cpuid space in a
reasonably flexible way that allows it to be used as the need arises,
then we can talk about it. But I think your proposal is a poor way to
achieve those ends
If you want blessing for something that you've already implemented and
shipped, well, you don't need anyone's blessing for that.
J
_______________________________________________
Virtualization mailing list
Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/virtualization
