Re: [PATCH 1/3] Revert "x86/msr: drop compatibility #GP handling in guest_{rd,wr}msr()"

[Jan Beulich <jbeulich@xxxxxxxx>]

On 19.03.2021 13:59, Andrew Cooper wrote:
> On 16/03/2021 16:58, Jan Beulich wrote:
>> On 16.03.2021 17:18, Andrew Cooper wrote:
>>> In hindsight, this was a poor move.  Some of these MSRs require probing for,
>>> causing unhelpful spew into xl dmesg, as well as spew from unit tests
>>> explicitly checking behaviour.
>> I can indeed see your point for MSRs that require probing. But what about
>> the others (which, as it seems, is the majority)? And perhaps specifically
>> what about the entire WRMSR side, which won't be related to probing? I'm
>> not opposed to the change, but I'd like to understand the reasoning for
>> every one of the MSRs, not just a subset.
>>
>> Of course such ever-growing lists of case labels aren't very nice - this
>> going away was one of the things I particularly liked about the original
>> change.
> 
> The logging in the default case is only useful when it is genuinely MSRs
> we haven't considered.
> 
> It is very useful at pointing bugs in guests, or bugs in Xen, but only
> when the logging is not drowned out by things we know about.

So would you mind adjusting the description accordingly? Right now, the
way it's written, it reads (to my non-native interpretation) as entirely
focusing on guests' probing needs. Even an adjustment as simple as

"In hindsight, this was a poor move.  Some of these MSRs require probing for,
 cause unhelpful spew into xl dmesg, or cause spew from unit tests
 explicitly checking behaviour."

would already shift the focus imo.

Jan