From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: [PATCH RFC 28/31] xen/x86: Context switch all levelling state in context_switch() Date: Fri, 22 Jan 2016 07:31:05 -0700 Message-ID: <56A24B3902000078000CA23E@prv-mh.provo.novell.com> References: <1450301073-28191-1-git-send-email-andrew.cooper3@citrix.com> <1450301073-28191-29-git-send-email-andrew.cooper3@citrix.com> <56A209DA02000078000C9F06@prv-mh.provo.novell.com> <56A23A58.3070403@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <56A23A58.3070403@citrix.com> Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper Cc: Xen-devel List-Id: xen-devel@lists.xenproject.org >>> On 22.01.16 at 15:19, wrote: > On 22/01/16 09:52, Jan Beulich wrote: >>>>> On 16.12.15 at 22:24, wrote: >>> @@ -145,6 +145,13 @@ void intel_ctxt_switch_levelling(const struct domain *nextd) >>> struct cpumasks *these_masks = &this_cpu(cpumasks); >>> const struct cpumasks *masks = &cpumask_defaults; >>> >>> + if (cpu_has_cpuid_faulting) { >>> + set_cpuid_faulting(nextd && is_pv_domain(nextd) && >>> + !is_control_domain(nextd) && >>> + !is_hardware_domain(nextd)); >>> + return; >>> + } >> Considering that you don't even probe the masking MSRs, this seems >> inconsistent with your "always level the entire system" choice. > > In the case that faulting is available, we never want to touch masking. > Faulting is newer and strictly superior to masking. > > As documented, there is no hardware which support both. (In reality, > there is one SKU of IvyBridge CPUs which experimentally have both.) > > > The fact that dom0 and the hardware domain are bypassed is a bug IMO. And we appear to disagree here. I'd rather see the rest of the series match this current behavior. > However, I am preserving the existing behaviour until phase 2 when I fix > other parts of the cpuid policy. Currently imposing faulting on dom0 > causes carnage because nothing generates it a sane policy. > > ~Andrew