Re: RFC: silencing kvm unimplemented msr spew.

[Bandan Das]

Paolo Bonzini <pbonzini@xxxxxxxxxx> writes:
...
>> Yeah, that's close. Though I would have done the same for the other side of
>> the if's too.
>> (Still evaluating which mode is actually more useful for us).
>
> For Linux guests, there should be no reason to use ignore_msrs.  Linux
> is pretty resilient to "missing" MSRs (especially because they are already
> ignored if the kernel is compiled with CONFIG_PARAVIRT=y!).  The option is
> really more for Windows, because it doesn't have anything like CONFIG_PARAVIRT
> and because drivers are sometimes less vetted (and sometimes do RDMSR
> themselves for whatever reason).  In general we try to look at beta versions
> of Windows and add any required MSRs well before the final release date,
> but if you're using old kernels you might be stuck with ignore_msrs.
>
> IOW, if there was a really common reason to use ignore_msrs it would be
> the default. ;)
>
>> Paolo, would you prefer this, or the other approach you already ack'd ?
>
> I think I prefer the other, because vcpu_debug is not ratelimited.
> If the guest can trigger a printk it should always be ratelimited.

Agree with rate limiting, but making this the default for everything doesn't sound
right IMO, especially for ignore_msrs=1. vcpu_unimpl is already rate limited.

Or is this change specifically to suppress messages on ignore_msrs=1 ?

> Paolo
> --
> 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