Alok Kataria wrote:
quoted text
> 
> Sure, some leaves have been defined already, but it's not too late to
> try to go the generic route for the remaining leaves.
> The longer we wait to come to a consensus on generic leaves, the more
> contention we will have.  So let's try to address it now.  
> 

We don't have a quorum to create a consensus, since we only have a 
subset of the relevant parties present.

We can get away with that if we agree on a standard that includes 
postive definition.

quoted text
> 1. This solution really bloats the kernel, below are few observations

You have no basis for that assertion.

quoted text
> i)  What happens if two ABI signature blocks define a cpuid leaf which
> have similar semantics, how does the kernel handle this ?

We already have this situation in a number of places.  The answer is 
generally that there is one form that the kernel prefer over another (in 
CPUID space, leaf 80000006 over leaf 2, for example) because it is 
better designed/more reliable/mode complete.

quoted text
> ii) Also, think about a case where a hypervisor supports 2 such ABI
> blocks - which have cpuid leafs with similar semantics - and decides to
> implement one of those and not the other leaf. How does the kernel
> handle this ?

The standard way to handle that in CPUID space is to leave the 
unimplemented leaf as zero.

quoted text
> I do understand that there are ways to handle this in the kernel but at
> the cost of just making the kernel more and more complicated for such
> corner cases.

The complexity is relatively minor.

quoted text
> 2. Also as a side note, what you are proposing just breaks down the
> problem in to sub-problems, i.e we still need to make sure that the
> individual cpuid leafs in the "block of leaves" are still generic. Also
> we may still have situations where hypervisor "A" wants to define a
> subset of cpuid block X, hypervisor B had defined.

It gives individual sub-APIs positive identification.  This is similar 
to PCI capabilities, for example.

quoted text
> 3. All in all, the end result of doing this would be that each
> hypervisor defines its own signature block forgetting about what the
> other hypervisor is doing. This is hardly generalizing this space.
> 
> Seriously, if we want to generalize this in the current situation, how
> about doing this ? 
> 
> 1. Have 0x40000000 as the hypervisor signature leaf.
> 2. Have 0x40000001-0x4000000F as the hypervisor specific leafs.
> 3. 0x40000010 - 0x400000FF as the generic space. 
> Use the non-zero meaning defined semantics for this generic space. 

As I said, I don't think we have any kind of quorum to declare such a 
"standard", and we'll see violations with failures as a result.

	-hpa
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/