From: Jan Beulich <jbeulich@suse.com>
To: "Roger Pau Monné" <roger.pau@citrix.com>
Cc: "Ian Jackson" <iwj@xenproject.org>,
"Andrew Cooper" <andrew.cooper3@citrix.com>,
"Frédéric Pierret" <frederic.pierret@qubes-os.org>,
"Dario Faggioli" <dfaggioli@suse.com>,
committers@xenproject.org, xen-devel@lists.xenproject.org
Subject: Re: [ANNOUNCE] Xen 4.15 release update - still in feature freeze
Date: Tue, 16 Mar 2021 11:12:58 +0100 [thread overview]
Message-ID: <7d27dffb-834d-1948-a410-c6d0c462ae63@suse.com> (raw)
In-Reply-To: <YFB9ux/06pP4hh/Y@Air-de-Roger>
On 16.03.2021 10:43, Roger Pau Monné wrote:
> On Mon, Mar 15, 2021 at 02:46:07PM +0100, Jan Beulich wrote:
>> On 15.03.2021 13:18, Ian Jackson wrote:
>>> ISSUES BELIEVED NEWLY RESOLVED
>>> ==============================
>>>
>>> Fallout from MSR handling behavioral change.
>>>
>>> I think there are now no outstanding patches to fix/change MSR
>>> behaviour and there is no longer any blocker here ?
>>
>> In addition to what Andrew has said, while not a blocker in that
>> sense I think the excessive verbosity of the logging is also an
>> issue.
>
> I think you meant the logging done for each MSR that's not explicitly
> handled?
>
> While I agree it might be too verbose, I don't see how we can change
> that right now. We could introduce a command line parameter to select
> whether to print those messages or not, but I think that's too
> specific for a command line option.
Yes, I agree.
> We should look into some kind of logging improvements that allow
> selecting which messages to print on a per-domain basis IMO.
Indeed, this was my thinking as well. I was wondering whether we
could at least limit reporting each unhandled MSR only once per
domain. But yes, this would require at least two extra pages to
hold the required bitmaps (one for the MSRs starting at 0x00000000
and the other for the group up from 0xC0000000; a 3rd one for AMD
for the group up from 0xC0010000).
> In any case, those messages will only show up in debug builds, so it's
> mostly annoying to developers but transparent to consumers of the
> production build.
Or when, because of things working differently than before, people
need to be told to increase verbosity for debugging purposes.
Jan
next prev parent reply other threads:[~2021-03-16 10:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-15 12:18 [ANNOUNCE] Xen 4.15 release update - still in feature freeze Ian Jackson
2021-03-15 13:10 ` Andrew Cooper
2021-03-15 13:46 ` Jan Beulich
2021-03-16 9:43 ` Roger Pau Monné
2021-03-16 10:12 ` Jan Beulich [this message]
2021-03-18 18:11 ` Dario Faggioli
2021-03-29 17:16 ` Dario Faggioli
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7d27dffb-834d-1948-a410-c6d0c462ae63@suse.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=committers@xenproject.org \
--cc=dfaggioli@suse.com \
--cc=frederic.pierret@qubes-os.org \
--cc=iwj@xenproject.org \
--cc=roger.pau@citrix.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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.