From: Jan Beulich <firstname.lastname@example.org>
To: "Roger Pau Monné" <email@example.com>
Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org,
Boris Ostrovsky <email@example.com>
Subject: Re: [PATCH v2 1/4] xl: Add support for ignore_msrs option
Date: Mon, 22 Feb 2021 11:33:42 +0100 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
On 22.02.2021 11:24, Roger Pau Monné wrote:
> On Fri, Feb 19, 2021 at 09:50:12AM -0500, Boris Ostrovsky wrote:
>> On 2/18/21 10:57 AM, Jan Beulich wrote:
>>> 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
>>>>>> 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?
>> In a multi-tenant environment we may need to figure out why a particular guest is failing to boot, without affecting behavior of other guests.
>> If we had per-guest log level in general then what you are suggesting would be the right thing to do IMO. Maybe that's what we should add?
> Yes, that would seem better IMO, but I don't think it's fair to ask
> you to do that work.
> Do you think it would be acceptable to untangle both, and try to get
> the MSR stuff without any logging changes?
> I know we would be addressing only one part of what the series
> originally tried to achieve, but I would rather prefer to have a
> generic way to set a per-guest log level rather than something
> specific to MSR accesses.
TBH I'd see us go the other route: Follow Boris'es approach for
4.15, and switch the logging control to per-guest once that
ability is there, _and_ if we're really convinced we don't want
to have this extra level of control. The latter because I think
a domain could end up pretty chatty just because of MSR accesses,
and it might therefore be undesirable to also hide all other
potentially relevant output. Perhaps the per-domain log level
control needs to be finer grained than what "guest_loglvl="
currently permits, more like what "hvm_debug=" has.
next prev parent reply other threads:[~2021-02-22 10:33 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-20 22:49 [PATCH v2 0/4] Permit fault-less access to non-emulated MSRs Boris Ostrovsky
2021-01-20 22:49 ` [PATCH v2 1/4] xl: Add support for ignore_msrs option Boris Ostrovsky
2021-01-21 14:56 ` Wei Liu
2021-01-21 22:43 ` Boris Ostrovsky
2021-01-22 9:52 ` Julien Grall
2021-01-22 18:28 ` Boris Ostrovsky
2021-01-22 18:33 ` Julien Grall
2021-01-22 18:39 ` Boris Ostrovsky
2021-01-22 20:42 ` Julien Grall
2021-02-18 10:42 ` Roger Pau Monné
2021-02-18 11:54 ` Jan Beulich
2021-02-18 15:52 ` Roger Pau Monné
2021-02-18 15:57 ` Jan Beulich
2021-02-19 14:50 ` Boris Ostrovsky
2021-02-22 10:24 ` Roger Pau Monné
2021-02-22 10:33 ` Jan Beulich [this message]
2021-01-20 22:49 ` [PATCH v2 2/4] x86: Introduce MSR_UNHANDLED Boris Ostrovsky
2021-01-22 11:51 ` Jan Beulich
2021-01-22 18:56 ` Boris Ostrovsky
2021-02-02 17:01 ` Boris Ostrovsky
2021-02-18 10:51 ` Roger Pau Monné
2021-02-19 14:56 ` Boris Ostrovsky
2021-02-22 11:08 ` Roger Pau Monné
2021-02-22 21:19 ` Boris Ostrovsky
2021-02-23 7:57 ` Jan Beulich
2021-02-23 9:34 ` Roger Pau Monné
2021-02-23 10:15 ` Jan Beulich
2021-02-23 12:17 ` Roger Pau Monné
2021-02-23 13:23 ` Jan Beulich
2021-02-23 15:39 ` Boris Ostrovsky
2021-02-23 16:10 ` Jan Beulich
2021-02-23 18:00 ` Roger Pau Monné
2021-02-23 16:11 ` Roger Pau Monné
2021-02-23 16:40 ` Boris Ostrovsky
2021-02-23 18:02 ` Roger Pau Monné
2021-02-23 18:45 ` Boris Ostrovsky
2021-01-20 22:49 ` [PATCH v2 3/4] x86: Allow non-faulting accesses to non-emulated MSRs if policy permits this Boris Ostrovsky
2021-01-22 12:51 ` Jan Beulich
2021-01-22 19:52 ` Boris Ostrovsky
2021-01-25 10:22 ` Jan Beulich
2021-01-25 18:42 ` Boris Ostrovsky
2021-01-26 9:05 ` Jan Beulich
2021-01-26 16:02 ` Boris Ostrovsky
2021-01-26 16:35 ` Jan Beulich
2021-02-18 11:24 ` Roger Pau Monné
2021-02-18 11:57 ` Jan Beulich
2021-02-18 15:53 ` Roger Pau Monné
2021-01-20 22:49 ` [PATCH v2 4/4] tools/libs: Apply MSR policy to a guest Boris Ostrovsky
2021-01-21 14:58 ` Wei Liu
2021-01-22 9:56 ` Julien Grall
2021-01-22 18:35 ` Boris Ostrovsky
2021-02-18 11:48 ` Roger Pau Monné
2021-02-19 14:57 ` Boris Ostrovsky
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.