Re: Should KVM_GUEST stop depending on PARAVIRT?

[Paolo Bonzini <pbonzini@redhat.com>]

On 27/07/2015 20:45, Andy Lutomirski wrote:
> On Mon, Jul 27, 2015 at 11:30 AM, Paolo Bonzini <pbonzini@redhat.com> 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
>