[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

  • To: Jan Beulich <jbeulich@xxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
  • Date: Fri, 19 Feb 2021 09:50:12 -0500
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kUskgIqVNaYeclYwmhNYIZ2o+1wQAjk9lE4jRdS2drI=; b=CuvOnTmh9JUoBG14A8Bi2XhhwcRV0TShc5AlY5QvggrEAz/+ejSIZA8/I9zIaZzcEhI8P6qNRiReSTUiN8E1U8tvKipfxmp2Vl9F8B6ptmvOEbJpCLo3ABXTOnOZcBlgTp93x/K9chTZp3xsUCV4ff40DXG+GMx2fXUhxmg0SB+/Rujkd0GKganEhcR7cZKpOlGaOGFv7GtZNlJJUB1YqC29CkmxsHGIlcr9uIcMggzBl6w31YoZPYrRR6tUkmg6BW3FBYzgZG4d0iO3HlGjofP5Qb3jpICVgCA1MJXP8lS9EXXZHSnw6Qa5fgEFK1iubnJjh8e2isttWDF0fawvVA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nyUMEkpVaK6x2Ym2Bd8x/O8zODtYq7BlPrMXRWu1QBvKjxcWuR0B4nK1orNF85rvz8Z3i0nL2VUI6tSJr9d6Cdg/ToAMBguOrQbL5TBqQb8QzTZxhlGMHVUQpDFLNz34GshpzNvy3re7yWRncZYpRvkLseVb4NMBy0tReV5B7OyvdyxZ5+p5HFv5kJD7vVVxck13klzTb5fwzFp3C/9E+ZrO7l/AI6fKoqTHZ/qBg4StgDtXXLYyDqnDSk2fSi4lFs94o103s+ojC3c4IrIpn47PAgsWmggYbqKIJ1v/4XD9/Dzc4rWNvDtdRdhBm1799r34nlGuEtM5N0fGpKHvbQ==
  • Authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=oracle.com;
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx, iwj@xxxxxxxxxxxxxx, wl@xxxxxxx, anthony.perard@xxxxxxxxxx, andrew.cooper3@xxxxxxxxxx, jun.nakajima@xxxxxxxxx, kevin.tian@xxxxxxxxx
  • Delivery-date: Fri, 19 Feb 2021 14:50:33 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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
>>>> #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?

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?


>> 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.



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.