Re: ABI coupling to hypervisors via CONFIG_PARAVIRT

[Chris Wright]

* Ingo Molnar (mingo@xxxxxxx) wrote:
> i claim that when the 'API cut' is done at the right level then no more 
> than say 100 hooks would be needed - with virtually zero kernel size 
> increase. We've got all the right highlevel abstractions: genirq, gtod, 
> clockevents. Whatever is missing at the moment from the framework (say 
> smp_send_reschedule()) we can abstract away. The bonus? It would be 
> almost directly applicable to other architectures as well. It would also 
> work with /any/ hypervisor.

Oddly enough, that's really what we are trying to acheive.  There is
definitely some tension between the VMI model which is modeled very
directly on hardware and something like the Xen model which prefers
higher level interfaces.

I don't really agree with your metrics w.r.t hooks.  My point is you
take callsites == hooks to arrive at 1463 hook, but then above say 100
hooks is sufficient.  But we have on the order of 100 hooks (I believe
it's ~75 in Linus' tree).  Put it another way.  Do you believe that
something like irq_{en,dis}able() is appropriate to hook (as that's >
1400 callsites already)?

> Firstly, i think this has been over-rushed. After years of being happy 
> with forks of the Linux kernel, all the hypervisors woke up at once and 
> want to have their stuff upstream /now/. This rush created a hodgepodge 
> of APIs/ABIs that we now in the end promise to support /all/. (if we 
> take CONFIG_VMI i can see little ethical reason to not take Xen's 
> paravirt_ops, lguest's paravirt_ops, KVM's paravirt_ops and i'm sure 
> Microsoft/Novell will have something nice and different for us too.)

It would be imminently helpful if you helped with some specific ideas
on where the paravirt_ops interface needs to be adjusted.

> Secondly, i'd like to see a paravirt approach that has /implicit/ 
> safeguards against the following type of crap:

How would you propose doing that?  Typically that's done with code
review and patches.

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