Let's add peterz? On Tue, Jul 28, 2015 at 2:57 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: > > > On 27/07/2015 20:45, Andy Lutomirski wrote: >> On Mon, Jul 27, 2015 at 11:30 AM, Paolo Bonzini <pbonzini@xxxxxxxxxx> wrote: >>> >>> >>> On 27/07/2015 19:51, Andy Lutomirski wrote: >>>>>> I think I'm missing something. Does KVM_GUEST hook read_msr and >>>>>> write_msr? I don't see it. >>>>> >>>>> PARAVIRT does, and it's the main reason why you'd want PARAVIRT for a >>>>> KVM guest. >>>> >>>> Still confused. On a KVM guest (with PARAVIRT=y), doesn't read_msr do >>>> exactly the same thing it does on native, albeit with more indirection >>>> and patching involved? >>> >>> With PARAVIRT=y it never #GPs: >>> >>> .read_msr = native_read_msr_safe, >>> .write_msr = native_write_msr_safe, >>> >>> I don't remember if it's this way on bare-metal too. >> >> Oh, whoops, I missed the "_safe". IMO that's just a bug, and I guess >> KVM relies on it? >> >> ISTM the host should be fixed so that a non-PARAVIRT guest won't crash >> when using perf (if it indeed currently crashes) > > It does. > >> and/or the perf code >> should be fixed to work without this bug^Wfeature. > > You can call it even feature^Wbug, I won't take it personal. :) It does > not prevent scary messages (such as "intel_rapl: no valid rapl domains > found in package 0") in the logs for example. See > https://bugzilla.redhat.com/show_bug.cgi?id=1178491 for a discussion > about such scary messages. > > Unfortunately, fixing the host vs. fixing the guest is an arms race. > > Fixing the host would entail adding support for a shitload of > non-architectural MSRs. Most of the time there is not even any correct > value that you can report for those MSRs (what's the FSB speed of a > virtual machine or its power consumption?) so there is nontrivial risk > that the guest code would anyway break or keep logging scary messages; > in which case we're back to square 1. > > Fixing the guest (perf and thermal and cpufreq and whatever) code isn't > any better. First of all, I wouldn't be surprised if maintainers > opposed the "fixes" (see the above BZ for an example, and see PeterZ's > love of KVM and "virt crap" for a hint). Second, it would break again > with all new processors, assuming that the patches are accepted in the > first place. > > So while the _safe hack is a hack and does result in scary messages > sometimes, we cannot really do much better than it just by modifying the > drivers, and at least the arms race is avoided. Perhaps one alternative > is to disable the thermal and cpufreq subsystems altogether if running > on a virt platform? PeterZ, can we fix this for real instead of relying on CONFIG_PARAVIRT=y accidentally turning all msr accesses into "safe" accesses? We have the CPUID "hypervisor" bit, but I still don't fully understand the problem. --Andy -- 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
