[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <jpgshv1d5gn.fsf@linux.bootlegged.copy>
Date: Fri, 22 Jul 2016 12:04:40 -0400
From: Bandan Das <bsd@...hat.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: Dave Jones <dsj@...com>,
Linux Kernel <linux-kernel@...r.kernel.org>,
Radim Krčmář <rkrcmar@...hat.com>,
kvm@...r.kernel.org
Subject: Re: RFC: silencing kvm unimplemented msr spew.
Paolo Bonzini <pbonzini@...hat.com> 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@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists