On 20.08.2013, at 12:38, Benjamin Herrenschmidt wrote: > On Tue, 2013-08-20 at 12:14 +0200, Paolo Bonzini wrote: >>> I suppose if RH is going to deploy 3.10 and we aren't going to backport >>> the multitce patches then there *might* be a case for supporting that >>> combo specifically... but it's going to be that bad every time we add >>> a new feature with a kernel counter part or start adding the gazillion >>> little bits of PAPR that we are still missing ? >> >> Yes. :( >> >> Unless you consider pSeries KVM not mature enough to provide a guest ABI >> (basically supporting live migration only between identical kernels and >> QEMUs). It would make some sense, for example (mutatis mutandis) Red >> Hat has a kernel ABI for the "regular" RHEL kernel, but not for the >> "real-time" RHEL kernel. > > Migration is somewhat less of an issue, and there is to consider what > "products" > will actually support KVM on Power. So at this early stage of the game, I > would > still play it by ear and stay flexible. When we have something we really need > to > have long term support for around the corner (or whatever we haven't announced > yet :-) we'll backport what's needed. > > But yes, the minute we have that out, I think the problem will present itself, > at which point we need to probably start considering features in "batches" to > limit the explosion of individual options ...
Yes, I completely agree. I am very happy to postpone that "always stay compatible" mode as far to the future as possible ;). So instead of making multi-tce support runtime switchable (which is a guarantee for exposing things differently to the guest), the easy way out is to always expose it. That way when we pull the trigger later to have a stable interface, we don't have to worry about this piece of code. If you like, add an if () on the multi-tce cap and warn the user that his system will be slow and that he should update his kernel. That way you get no headaches on compatibility and people won't get confused why they're being slow because you warned them. Alex
