On 22/02/17 04:08, Alexander Graf wrote: [irrelevant stuff] > Thanks for handling this quickly :). > > One thing I can't get my head around yet is VM propagation of these > erratas. For the dt property based approach, I can at least see how > someone adds that property into the guest dt when running on broken > hosts. > > But how would that work when the erratum matching happens based on > the OEM identifier? Would a VM suddenly have to have HiSilicon as > OEM? Or would we forbid kvm usage altogether on those CPUs? s/CPU/SoC/ Simple: you only use DT as a guest, because it is the only firmware interface that allows you to reliably describe an arbitrary erratum. ACPI is too inflexible for that. Injecting bits of the host's ACPI tables in the guest doesn't strike me as a reliable solution, as you're not describing the erratum itself. I imagine you 'd have some userspace tool to dump the host ACPI table, match it against a list of known errata, and inject the corresponding property into the guest's DT. Furthermore, I don't see any reason to actively prevent KVM from running on any system. If we did, we'd start with the RPi... Thanks, M. -- Jazz is not dead. It just smells funny... -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
