Re: [PATCH v2 1/4] xl: Add support for ignore_msrs option

[Jan Beulich <jbeulich@xxxxxxxx>]

On 18.02.2021 16:52, Roger Pau Monné wrote:
> On Thu, Feb 18, 2021 at 12:54:13PM +0100, Jan Beulich wrote:
>> On 18.02.2021 11:42, Roger Pau Monné wrote:
>>> Not that you need to implement the full thing now, but maybe we could
>>> have something like:
>>>
>>> "
>>> =item B<ignore_msrs=[ "MSR_RANGE, "MSR_RANGE", ..]>
>>>
>>> Specify a list of MSR ranges that will be ignored by the hypervisor:
>>> reads will return zeros and writes will be discarded without raising a
>>> #GP.
>>>
>>> Each MSR_RANGE is given in hexadecimal format and may be a range, e.g.
>>> c00102f0-c00102f1 (inclusive), or a single MSR, e.g. c00102f1.
>>> "
>>>
>>> Then you can print the messages in the hypervisor using a guest log
>>> level and modify it on demand in order to get more verbose output?
>>
>> "Modify on demand"? Irrespective of what you mean with this, ...
>>
>>> I don't think selecting whether the messages are printed or not from
>>> xl is that helpful as the same could be achieved using guest_loglvl.
>>
>> ... controlling this via guest_loglvl would affect various other
>> log messages' visibility.
> 
> Right, but do we really need this level of per-guest log control,
> implemented in this way exclusively for MSRs?
> 
> We don't have a way for other parts of the code to have such
> fine-grained control about what messages should be printed, and I
> don't think MSR should be an exception. I assume this would be used to
> detect which MSRs a guest is trying to access, and I would be fine
> just using guest_loglvl to that end, the more that it can be modified
> at run time now.

I can certainly see your point. The problem is that for guests
heavily accessing such MSRs, all other messages may disappear
due to rate limiting. That's not going to be helpful.

Jan