On 21.08.2013, at 08:11, Alexander Graf wrote: > > 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.
Or keep the code as is, but print a warning to the user on the "kernel does not expose multi-tce" case so that he knows he uses an outdated version of KVM. That way the guest visible difference is at least visible in the logs. Alex
