On 08/19/2013 01:22 AM, Paolo Bonzini wrote: > Il 16/08/2013 11:49, Alexey Kardashevskiy ha scritto: >> With KVM, we could fall back to the qemu implementation >>> + * when KVM doesn't support them, but that would be much slower >>> + * than just using the KVM implementations of the single TCE >>> + * hypercalls. */ >>> + if (kvmppc_spapr_use_multitce()) { >>> + _FDT((fdt_property(fdt, "ibm,hypertas-functions", hypertas_propm, >>> + sizeof(hypertas_propm)))); >>> + } else { >>> + _FDT((fdt_property(fdt, "ibm,hypertas-functions", hypertas_prop, >>> + sizeof(hypertas_prop)))); >>> + } > > This prevents migration from newer kernel to older kernel. Can you > ensure that the fallback to the QEMU implementation works, even though > it is not used in practice?
How would it break? By having a device tree with "multi-tce" in it and not having KVM PPC capability for that? If this is the case, it will not prevent from migration as the "multi-tce" feature is supported anyway by this patch. The only reason for not advertising it to the guest is that the host kernel already has acceleration for H_PUT_TCE (single page map/unmap) and advertising "multi-tce" without having it in the host kernel (but only in QEMU) would slow things down (but it still will work). -- Alexey