2016-12-06 10:37+0100, David Hildenbrand: >> I think the agreement is to embrace compatibility, so we pile new >> mistakes to hide known ones. >> (Rewriting the past requires far more power than accepting it: >> If we didn't force unfixed kernels out of existence, then userspace >> couldn't tell if hotplug up to high VCPU ID limit is supported.) > > I agree, the question is how old the bug is (you should know better than me > :) ) Just half a year old, since v4.7. > and if introducing a capability is strictly necessary. Do we have to do > the check in QEMU or can we simply fix implementations out there silently. This fix is too big for stable and I don't think that patches outside of stable get backported much. > (especially as hotplugging cpuid > 255 doesn't sound like setups wildly used > already today - and it doesn't work ;) ). Yes, it seems that no-one using high APIC ID noticed/cared. > But as I said, I don't know the > history, so you decide if this check in QEMU is necessary. QEMU can decide not to check (I actually expect it won't :]). I think the option to check is worth two lines of code in KVM, though. > Fix all QEMUs (introduce capability check) vs fix all relevant kernels > (limiting VCPU id to 255). APID ID over 255 works without hotplug and has few users, so lowering the limit would regress cases that are more important, IMO. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
