From mboxrd@z Thu Jan 1 00:00:00 1970 From: Malcolm Crossley Subject: Re: [PATCH] iommu/quirk: disable shared EPT for Sandybridge and earlier processors. Date: Wed, 25 Nov 2015 15:58:58 +0000 Message-ID: <5655DAC2.6010004@citrix.com> References: <1448385479-17614-1-git-send-email-anshul.makkar@citrix.com> <5654AF4C02000078000B8A11@prv-mh.provo.novell.com> <56558D35.2040800@citrix.com> <5655A04202000078000B8E8F@prv-mh.provo.novell.com> <5655D021.2010206@citrix.com> <5655E41302000078000B919B@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <5655E41302000078000B919B@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Andrew Cooper , Anshul Makkar Cc: yang.z.zhang@intel.com, kevin.tian@intel.com, xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On 25/11/15 15:38, Jan Beulich wrote: >>>> On 25.11.15 at 16:13, wrote: >> On 25/11/15 10:49, Jan Beulich wrote: >>>>>> On 25.11.15 at 11:28, wrote: >>>> On 24/11/15 17:41, Jan Beulich wrote: >>>>>>>> On 24.11.15 at 18:17, wrote: >>>>>> --- a/xen/drivers/passthrough/vtd/quirks.c >>>>>> +++ b/xen/drivers/passthrough/vtd/quirks.c >>>>>> @@ -320,6 +320,20 @@ void __init platform_quirks_init(void) >>>>>> /* Tylersburg interrupt remap quirk */ >>>>>> if ( iommu_intremap ) >>>>>> tylersburg_intremap_quirk(); >>>>>> + >>>>>> + /* >>>>>> + * Disable shared EPT ("sharept") on Sandybridge and older processors >>>>>> + * by default. >>>>>> + * SandyBridge has no huge page support for IOTLB which leads to >> fallback >>>>>> + * on 4k pages and leads to performance degradation. >>>>>> + * >>>>>> + * Shared EPT ("sharept") will be disabled only if user has not >>>>>> + * provided explicit choice on the command line thus iommu_hap_pt_share >> is >>>>>> + * at its initialized value of -1. >>>>>> + */ >>>>>> + if ( (boot_cpu_data.x86 == 0x06 && (boot_cpu_data.x86_model <= 0x2F || >>>>>> + boot_cpu_data.x86_model == 0x36)) && (iommu_hap_pt_share == -1) ) >>>>>> + iommu_hap_pt_share = 0; >>>>> If we really want to do this, then I think we should key this on >>>>> EPT but not VT-d having 2M support, instead of on CPU models. >>>> This check is already performed by vtd_ept_page_compatible() >>> Yeah, I realized there would be such a check on the way home. >>> >>>> The problem is that SandyBridge IOMMUs advertise 2M support and do >>>> function with it, but cannot cache 2MB translations in the IOTLBs. >>>> >>>> As a result, attempting to use 2M translations causes substantially >>>> worse performance than 4K translations. >>> So commit message and comment should make this more explicit, >>> to avoid the impression "IOTLB" isn't just the relatively common >>> mis-naming of "IOMMU". >>> >>> Plus I guess the sharing won't need suppressing if !opt_hap_2mb? >>> >>> Further the model based check is relatively broad, and includes >>> Atoms (0x36 actually is one), which can't be considered "Sandybridge >>> or older" imo. >>> >>> And finally I'm not fully convinced using CPU model info to deduce >>> chipset behavior is entirely correct (albeit perhaps in practice it'll >>> be fine except maybe when running Xen itself virtualized). >> >> What else would you suggest? I can't think of any better identifying >> information. > > Chipset IDs / revisions? In this case the IOMMU is integrated into the Sandybridge-EP processor itself. Unfortunately there's no register to query the IOTLB configuration of the IOMMU and so we're stuck identifying the via the processor model number itself. Malcolm > > Jan > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@lists.xen.org > http://lists.xen.org/xen-devel >