From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,INCLUDES_PATCH, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 45B47C433ED for ; Tue, 20 Apr 2021 12:37:37 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id D6338611F2 for ; Tue, 20 Apr 2021 12:37:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D6338611F2 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.113618.216528 (Exim 4.92) (envelope-from ) id 1lYpdA-0007cv-0o; Tue, 20 Apr 2021 12:37:28 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 113618.216528; Tue, 20 Apr 2021 12:37:27 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lYpd9-0007co-UH; Tue, 20 Apr 2021 12:37:27 +0000 Received: by outflank-mailman (input) for mailman id 113618; Tue, 20 Apr 2021 12:37:27 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lYpd9-0007cj-7i for xen-devel@lists.xenproject.org; Tue, 20 Apr 2021 12:37:27 +0000 Received: from mga02.intel.com (unknown [134.134.136.20]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id d37eb6c9-581c-4eb4-ac03-68d33f006aea; Tue, 20 Apr 2021 12:37:22 +0000 (UTC) Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Apr 2021 05:37:21 -0700 Received: from gao-cwp.sh.intel.com (HELO gao-cwp) ([10.239.159.149]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 20 Apr 2021 05:37:18 -0700 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: d37eb6c9-581c-4eb4-ac03-68d33f006aea IronPort-SDR: 8ENSriSrf/ef9mDRmsr9Guol8FOaFEcS+lR5v9WwPSQ9GVYewRDpPMiu+JVJ4bSdepl47X6GB2 Olimjc2ujYwg== X-IronPort-AV: E=McAfee;i="6200,9189,9959"; a="182629102" X-IronPort-AV: E=Sophos;i="5.82,236,1613462400"; d="scan'208";a="182629102" IronPort-SDR: O7KmZDvxuhOz0prwu+3x444EnRXqTsEP7IEi60RmoghTIxR/41DlrkSB+S1aVzBzhJwWlvAuwm lK8joYWbc8Aw== X-IronPort-AV: E=Sophos;i="5.82,236,1613462400"; d="scan'208";a="426910262" Date: Tue, 20 Apr 2021 20:41:29 +0800 From: Chao Gao To: Jan Beulich Cc: Andrew Cooper , George Dunlap , Ian Jackson , Julien Grall , Stefano Stabellini , Wei Liu , Kevin Tian , xen-devel@lists.xenproject.org Subject: Re: [PATCH v2] VT-d: Don't assume register-based invalidation is always supported Message-ID: <20210420124127.GA12175@gao-cwp> References: <20200401200606.48752-1-chao.gao@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) On Tue, Apr 20, 2021 at 01:38:26PM +0200, Jan Beulich wrote: >On 01.04.2020 22:06, Chao Gao wrote: >> According to Intel VT-d SPEC rev3.3 Section 6.5, Register-based Invalidation >> isn't supported by Intel VT-d version 6 and beyond. >> >> This hardware change impacts following two scenarios: admin can disable >> queued invalidation via 'qinval' cmdline and use register-based interface; >> VT-d switches to register-based invalidation when queued invalidation needs >> to be disabled, for example, during disabling x2apic or during system >> suspension or after enabling queued invalidation fails. >> >> To deal with this hardware change, if register-based invalidation isn't >> supported, queued invalidation cannot be disabled through Xen cmdline; and >> if queued invalidation has to be disabled temporarily in some scenarios, >> VT-d won't switch to register-based interface but use some dummy functions >> to catch errors in case there is any invalidation request issued when queued >> invalidation is disabled. >> >> Signed-off-by: Chao Gao > >In principle (with a minor nit further down) >Reviewed-by: Jan Beulich > >However, ... > >> --- >> Changes in v2: >> - verify system suspension and resumption with this patch applied >> - don't fall back to register-based interface if enabling qinval failed. >> see the change in init_vtd_hw(). >> - remove unnecessary "queued_inval_supported" variable >> - constify the "struct vtd_iommu *" of has_register_based_invalidation() >> - coding-style changes > >... while this suggests this is v2 of a recently sent patch, the >submission is dated a little over a year ago. This is confusing. >It is additionally confusing that there were two copies of it in >my inbox, despite mails coming from a list normally getting >de-duplicated somewhere at our end (I believe). You are right. I messed the system time of my server somehow. Sorry for this. If it is possible, please help to update the date of this patch also. > >> --- a/xen/drivers/passthrough/vtd/iommu.c >> +++ b/xen/drivers/passthrough/vtd/iommu.c >> @@ -1193,6 +1193,14 @@ int __init iommu_alloc(struct acpi_drhd_unit *drhd) >> >> iommu->cap = dmar_readq(iommu->reg, DMAR_CAP_REG); >> iommu->ecap = dmar_readq(iommu->reg, DMAR_ECAP_REG); >> + iommu->version = dmar_readl(iommu->reg, DMAR_VER_REG); >> + >> + if ( !iommu_qinval && !has_register_based_invalidation(iommu) ) >> + { >> + printk(XENLOG_WARNING VTDPREFIX "IOMMU %d: cannot disable Queued Invalidation.\n", >> + iommu->index); > >Here (and at least once more yet further down): We don't normally end >log messages with a full stop. Easily addressable while committing, of >course. Okay. Please go ahead. Thanks Chao