On 11.07.2013, at 15:13, Alexey Kardashevskiy wrote: > On 07/11/2013 10:58 PM, Benjamin Herrenschmidt wrote: >> On Thu, 2013-07-11 at 14:51 +0200, Alexander Graf wrote: >>> I don't like bloat usually. But Alexey even had an #ifdef DEBUG in >>> there to selectively disable in-kernel handling of multi-TCE. Not >>> calling ENABLE_CAP would give him exactly that without ugly #ifdefs in >>> the kernel. >> >> I don't see much point in disabling it... but ok, if that's a valuable >> feature, then shoot some VM level ENABLE_CAP (please don't iterate all >> VCPUs, that's gross). > > No use for me whatsoever as I only want to disable real more handlers and > keep virtual mode handlers enabled (sometime, for debug only) and this > capability is not about that - I can easily just not enable it in QEMU with > the exactly the same effect. > > So please, fellas, decide whether I should iterate vcpu's or add ENABLE_CAP > per KVM. Thanks.
Thinking hard about this it might actually be ok to not have an ENABLE_CAP for this, if kernel code always works properly, because from the guest's point of view nothing changes - it either gets handled by kernel or by user space. And user space either handles it or doesn't, so it's ok. Just leave it out this time. But be very weary of adding new features without an ENABLE_CAP switch. They might be guest visible changes. Alex _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
