[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: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Mon, 22 Feb 2021 11:24:24 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.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=/djj7M5mquJQDj1u6cxQhbBU22AEShavrxn4mhwoRxk=; b=ClNIVnOlq4hKbpr7AB8XtPqzjNKZPhcK9hVdIHFAGWMyumzWg9/OVQ5ViCm3Dv8cTvkH+ULMprk+0xo84t5aSr1ueU/338ibTt3G9o4yr2HfkRb/W3ZSXsUAX0BQ7rHxLvaUxEqXf/+CNmPydaK8GW3O3FCsd7d0Tyxr07X1aWMGpHAi2UYnjZ7tKYUnUXBVaZiy3jL1d8KnEmQSQFeuTpsLIcJkTiF4LMV7MUU2N4eSYdBUruhgh64soDscVVEJFNMKzU86NLqatZ+Mf+okTygcenXTSt/AUq3C9URaGHZtSdtR6RAaa/S2qczFjv93puVreTXzB9i+MEcOFcTqzw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BJLrVSSWoNYC9mU7FBVgMwGJM99HCSIoe/yJqZbignXYXmonU/GkwdKW0eEkBInQxm+28++YdEjDErsF2j07xhy6Pi7IE2XgZDxADZn/h8DaQYp4beA856TN5ZsBBTkyZCa7bT7GAjRQTqYWQ3hOgHSmUpGq6AjE7+ctCUb/Pdnnk7elvBNKWrE7bVaPW6+MMUVonokaOxR7D7euvUxZg6AG7IRN6570/99jwZPCXfQdfI778m1auIvkkazQeZFAg3nkSuo/zbCfD6JfTwlx8+0c595RGeabT5BOf+0z0L//9ObcjxSyjZyfQAjH4oKY+0+0lEPxhgciVNeyBUI2zA==
  • Authentication-results: esa6.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: Jan Beulich <jbeulich@xxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>, <iwj@xxxxxxxxxxxxxx>, <wl@xxxxxxx>, <anthony.perard@xxxxxxxxxx>, <andrew.cooper3@xxxxxxxxxx>, <jun.nakajima@xxxxxxxxx>, <kevin.tian@xxxxxxxxx>
  • Delivery-date: Mon, 22 Feb 2021 10:24:39 +0000
  • Ironport-sdr: zqposPiWRB/2qI/Btpwd1YgV1DxSCxj+GKrJSS5DdhgIlNzi+eHQkeVK4ANlXb9hPXtMspA+hN h1EemKuVk+sxwWSHgknlns2/3NwxJv5tkZ2tpAf9+gy6IZj1D3os/k0hn505IbCTDuujPDImw/ EYq8myw1IJOhk1DYjFEzhP0hx9oMMNbNRqbynQk5DUL2myfeHa60X6j+RX6qxMGZiWVQP7UxKJ nLXezcU/XBtlLKM5oAzB3D0do8vrRvVLR7VEscQ0ohomBVcktFJ96WKtbjVpFN+UIplJ8KG8lB 7I4=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

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

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.

Thanks, Roger.



 


Rackspace

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