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

Re: x86/PV: (lack of) MTRR exposure


  • To: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Fri, 29 Apr 2022 12:00:21 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=2RPmWF+WLhZ49qd/qXvvWeU0bAoV+1Ztkr8p0t6aoOo=; b=Aw/YZTCc7ks0m4ZujqUf4sYkPaaVM8WJ8REF/zCvdvYNLrjDcQ39kNoEIPNAh1BamwVyPFYhre949bubadvQhbLxxYI/tFwK2xgJdPm2oZv+gKMAij8DKdjT2MD+8GpueWpq4MYMJKxyxqingM7Nptg6YQDJK8RpNEt2gl1yKBBRRuKC84vYgCq3Oush1XpS90osRukcSOdk8tgPoibuzzWU1nTTgXVXWD4SvHpS4R2/KiooxH53XqI+XajVQFwm4WSwsuV8xqd2bMcmilh3+PVOCejjidJyB9oNcLHPB8F22ktc6C+2/dFUxwTAt47KQiFXtcty1T1gbnnhEKqGJg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IgW7GMaoU17Najrg4oMUZxVuRbSz6btVj3Thnz2085Ay05i609/z1weMaPgNfQIG9yKcPX1FDl/a5GsmASdvOfURyZl2LqfyVVfa3yhxqcWbRyLAEg8WlitjjTcrdkfbUnjkS+ryDQ+G3AZvrFbjOyq9fjrN8ZvUJE26oLh8sAbKe3K7orFZZ3UauxCpigiWdeCMvsdjq0BiJkkP/m3cFpEFH1ny9pdPnZyawTyT9tuV/JDXVPuH0Iek9zsdwpXQQdbjUo05NupzqztNMeRX+xtHIjN3uDutvchXu7CNoU5QfHOH53aufda5k4mJH86Dyl1x7uEKce+QBvcNLp/7KA==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Juergen Gross <jgross@xxxxxxxx>, Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
  • Delivery-date: Fri, 29 Apr 2022 10:00:38 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 29.04.2022 10:00, Roger Pau Monné wrote:
> On Thu, Apr 28, 2022 at 05:53:17PM +0200, Jan Beulich wrote:
>> Hello,
>>
>> in the course of analyzing the i915 driver causing boot to fail in
>> Linux 5.18 I found that Linux, for all the years, has been running
>> in PV mode as if PAT was (mostly) disabled. This is a result of
>> them tying PAT initialization to MTRR initialization, while we
>> offer PAT but not MTRR in CPUID output. This was different before
>> our moving to CPU featuresets, and as such one could view this
>> behavior as a regression from that change.
>>
>> The first question here is whether not exposing MTRR as a feature
>> was really intended, in particular also for PV Dom0. The XenoLinux
>> kernel and its forward ports did make use of XENPF_*_memtype to
>> deal with MTRRs. That's functionality which (maybe for a good
>> reason) never made it into the pvops kernel. Note that PVH Dom0
>> does have access to the original settings, as the host values are
>> used as initial state there.
>>
>> The next question would be how we could go about improving the
>> situation. For the particular issue in 5.18 I've found a relatively
>> simple solution [1] (which also looks to help graphics performance
>> on other systems, according to my initial observations with using
>> the change), albeit its simplicity likely means it either is wrong
>> in some way, or might not be liked for looking hacky and/or abusive.
> 
> I wonder whether the patch needs to be limited to the CPUID Hypervisor
> bit being present.  If the PAT MSR is readable and returns a value !=
> 0 then PAT should be available?

I simply didn't want to be too "aggressive". There may be reasons why
they want things to be the way they are on native. All I really care
about is that things are broken on PV Xen; as such I wouldn't even
mind tightening the check to xen_pv_domain(). But first I need
feedback from the maintainers there anyway.

> I guess we should instead check that the current PAT value matches
> what Linux expects, before declaring PAT enabled?

I don't think such a check is needed, the code ...

> Note there's already a comment in init_cache_modes that refers to Xen
> in the check for PAT CPUID bit.

... in __init_cache_modes() already does it the other way around:
Adapt behavior to what is found in PAT.

>  We might want to expand that comment
> (or add one to the new check you are adding).

I don't see what further information you would want to put there.

Jan




 


Rackspace

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