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

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 19/03/2021 13:56, Jan Beulich wrote:
> 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.

Sure.  I'll try to make this clearer.

~Andrew