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? Paolo > Then KVM_GUEST kernels could be de-bloated by dropping PARAVIRT. > > Hi Arjan- A quick and dirty measurement suggests that this would save > 2-3 ms when booting a KVM_GUEST=y kernel under KVM by turning > apply_paravirt into a noop. > > --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
