From nobody Mon Feb 9 07:07:09 2026 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; dkim=pass header.i=teddy.astie@vates.tech; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass(p=quarantine dis=none) header.from=vates.tech ARC-Seal: i=1; a=rsa-sha256; t=1711017703; cv=none; d=zohomail.com; s=zohoarc; b=h/m3POj8HL+fVvrxgSvYm6Ecpf1gix+R3bd2USjgVibtdWmahoq8tvFy5DefgNarJ1mhbUeT7ZMU2LOjIR3xMD08aAHIDYWk+s4To0tfSWTrKGHV4T6IBNdeXOmKglQEA9ZmYMzJ33O1Df0jb3SIJRIA8JWuegvRKONBTNwyCyE= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1711017703; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:In-Reply-To:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:References:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=yNxbTqH2YJSkOiphdTLQC16uPnEcVvW/4yCo8FASxpc=; b=kHleP0QMCBTLFn00DvSxJdXIYOcVAQZlli5QVZzVMSxh8ZdmOp2kQv6nUXBfr7n+jTXkDYXAnspisludPta04ABx5Jsjentbtw4cFB97UOPw80XIFdDtxvEuajhloLLqw6mj6NYEhlsnhu3tbQWVh0ga4SYFfea8h3JSd2UNV9E= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass header.i=teddy.astie@vates.tech; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org; dmarc=pass header.from= (p=quarantine dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1711017703571946.6550756534564; Thu, 21 Mar 2024 03:41:43 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.696304.1087153 (Exim 4.92) (envelope-from ) id 1rnFrT-0003Wv-OZ; Thu, 21 Mar 2024 10:41:27 +0000 Received: by outflank-mailman (output) from mailman id 696304.1087153; Thu, 21 Mar 2024 10:41: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 1rnFrT-0003Wm-M4; Thu, 21 Mar 2024 10:41:27 +0000 Received: by outflank-mailman (input) for mailman id 696304; Thu, 21 Mar 2024 10:28:30 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rnFew-0007v6-ND for xen-devel@lists.xenproject.org; Thu, 21 Mar 2024 10:28:30 +0000 Received: from mail135-12.atl141.mandrillapp.com (mail135-12.atl141.mandrillapp.com [198.2.135.12]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id c1b71590-e76d-11ee-afe0-a90da7624cb6; Thu, 21 Mar 2024 11:28:29 +0100 (CET) Received: from pmta14.mandrill.prod.atl01.rsglab.com (localhost [127.0.0.1]) by mail135-12.atl141.mandrillapp.com (Mailchimp) with ESMTP id 4V0hWG40jdz705xhc for ; Thu, 21 Mar 2024 10:28:26 +0000 (GMT) Received: from [37.26.189.201] by mandrillapp.com id b011fbae99164ddc94c4654e4770f1fb; Thu, 21 Mar 2024 10:28:26 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version 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: c1b71590-e76d-11ee-afe0-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mandrillapp.com; s=mte1; t=1711016906; x=1711277406; bh=yNxbTqH2YJSkOiphdTLQC16uPnEcVvW/4yCo8FASxpc=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=GrXDwdCVooZpyvoMeitKyaQInEHVkymkKLBQm/8/YFPW1agW77sofv8ykeXjEho8g u5SimoOzD2MoVVfYUSRwcqSgr4Fam1Ng0pi3BZB2o9NQfxijQV7BOKV06LZy2Cu+NU NYeP87ojRy8A5zPoRQFh20LbtTWr887n1D1wtdInwzi3t2CQ+x1Pb2p3oOL6EV9jm0 pAbHMKWOLj3bzc/CnzE1uhctbPCVv5Hx51E7PzVeZnaAy4/WXI2sFgVSQpSIs0Xc5r PfrLJOj5W49FZNJ+vgKoacoFnUaY/xhlX2NPKk7AdmNi13f3ylov/xuC1nImaMI/TN NK7Kv4M3SV76g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vates.tech; s=mte1; t=1711016906; x=1711277406; i=teddy.astie@vates.tech; bh=yNxbTqH2YJSkOiphdTLQC16uPnEcVvW/4yCo8FASxpc=; h=From:Subject:To:Cc:Message-Id:In-Reply-To:References:Feedback-ID: Date:MIME-Version:Content-Type:Content-Transfer-Encoding:CC:Date: Subject:From; b=etazsW80scRAm8wHgdOSjH8kDbgDAeyvUpZMos0tZ0mdDJ0LzAuy5cMyeZvH+WmCp rOqPtGtgryoMAAUvO6DoxuB4N35asD8zQHbffmX+3n9mX2Sgv4pkKAKBjdqJWMavW1 1Oss5ZpBCetnSacpcTggDFiRBou0uv0KDxdGHVbGYgrE3SBOtDMuA99NMzvdR4HWDD fpYwAhye6BnLblvkAU5RyH2n5Fj8QFTb/mRKIJ9+A6GR2WZ1M50137sbBmVtaeKc57 13QwqXX260rq3QXmdC4TPEjcTCEC1dmxuohLdSuj0+kXYHCwz70mLXZNuouybF+/m0 R/70vpZbnFc4Q== From: Teddy Astie Subject: =?utf-8?Q?[XEN=20PATCH=201/3]=20VT-d:=20Disable=20IOMMU=20if=20cx16=20isn't=20supported?= X-Mailer: git-send-email 2.44.0 X-Bm-Disclaimer: Yes X-Bm-Milter-Handled: 4ffbd6c1-ee69-4e1b-aabd-f977039bd3e2 X-Bm-Transport-Timestamp: 1711016905606 To: xen-devel@lists.xenproject.org Cc: Teddy Astie , Kevin Tian Message-Id: In-Reply-To: References: X-Native-Encoded: 1 X-Report-Abuse: =?UTF-8?Q?Please=20forward=20a=20copy=20of=20this=20message,=20including=20all=20headers,=20to=20abuse@mandrill.com.=20You=20can=20also=20report=20abuse=20here:=20https://mandrillapp.com/contact/abuse=3Fid=3D30504962.b011fbae99164ddc94c4654e4770f1fb?= X-Mandrill-User: md_30504962 Feedback-ID: 30504962:30504962.20240321:md Date: Thu, 21 Mar 2024 10:28:26 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @mandrillapp.com) (identity teddy.astie@vates.tech) X-ZM-MESSAGEID: 1711017704948100001 Content-Type: text/plain; charset="utf-8" No hardware has VT-d support while not having cx16 support, consider disabl= ing IOMMU in this case to avoid potentially buggy code. Now that IOMMU is only enabled if cx16 is supported, drop dead code that ha= ndles cases where cx16 isn't supported. Signed-off-by Teddy Astie --- xen/drivers/passthrough/vtd/intremap.c | 67 +++++---------------- xen/drivers/passthrough/vtd/iommu.c | 80 +++++++++----------------- 2 files changed, 41 insertions(+), 106 deletions(-) diff --git a/xen/drivers/passthrough/vtd/intremap.c b/xen/drivers/passthrou= gh/vtd/intremap.c index c504852eb8..312b73e693 100644 --- a/xen/drivers/passthrough/vtd/intremap.c +++ b/xen/drivers/passthrough/vtd/intremap.c @@ -173,47 +173,26 @@ bool __init cf_check intel_iommu_supports_eim(void) * Assume iremap_lock has been acquired. It is to make sure software will = not * change the same IRTE behind us. With this assumption, if only high qwor= d or * low qword in IRTE is to be updated, this function's atomic variant can - * present an atomic update to VT-d hardware even when cmpxchg16b - * instruction is not supported. + * present an atomic update to VT-d hardware. */ static void update_irte(struct vtd_iommu *iommu, struct iremap_entry *entr= y, const struct iremap_entry *new_ire, bool atomic) { - ASSERT(spin_is_locked(&iommu->intremap.lock)); - - if ( cpu_has_cx16 ) - { - __uint128_t ret; - struct iremap_entry old_ire; + __uint128_t ret; + struct iremap_entry old_ire; =20 - old_ire =3D *entry; - ret =3D cmpxchg16b(entry, &old_ire, new_ire); + ASSERT(spin_is_locked(&iommu->intremap.lock)); + =20 + old_ire =3D *entry; + ret =3D cmpxchg16b(entry, &old_ire, new_ire); =20 - /* - * In the above, we use cmpxchg16 to atomically update the 128-bit - * IRTE, and the hardware cannot update the IRTE behind us, so - * the return value of cmpxchg16 should be the same as old_ire. - * This ASSERT validate it. - */ - ASSERT(ret =3D=3D old_ire.val); - } - else - { - /* - * VT-d hardware doesn't update IRTEs behind us, nor the software - * since we hold iremap_lock. If the caller wants VT-d hardware to - * always see a consistent entry, but we can't meet it, a bug will - * be raised. - */ - if ( entry->lo =3D=3D new_ire->lo ) - write_atomic(&entry->hi, new_ire->hi); - else if ( entry->hi =3D=3D new_ire->hi ) - write_atomic(&entry->lo, new_ire->lo); - else if ( !atomic ) - *entry =3D *new_ire; - else - BUG(); - } + /* + * In the above, we use cmpxchg16 to atomically update the 128-bit + * IRTE, and the hardware cannot update the IRTE behind us, so + * the return value of cmpxchg16 should be the same as old_ire. + * This ASSERT validate it. + */ + ASSERT(ret =3D=3D old_ire.val); } =20 /* Mark specified intr remap entry as free */ @@ -394,8 +373,7 @@ static int ioapic_rte_to_remap_entry(struct vtd_iommu *= iommu, remap_rte->reserved =3D 0; /* Indicate remap format. */ remap_rte->format =3D 1; - - /* If cmpxchg16b is not available the caller must mask the IO-APIC pin= . */ + =20 update_irte(iommu, iremap_entry, &new_ire, !init && !masked); iommu_sync_cache(iremap_entry, sizeof(*iremap_entry)); iommu_flush_iec_index(iommu, 0, index); @@ -437,21 +415,6 @@ void cf_check io_apic_write_remap_rte( bool masked =3D true; int rc; =20 - if ( !cpu_has_cx16 ) - { - /* - * Cannot atomically update the IRTE entry: mask the IO-APIC pin to - * avoid interrupts seeing an inconsistent IRTE entry. - */ - old_rte =3D __ioapic_read_entry(apic, pin, true); - if ( !old_rte.mask ) - { - masked =3D false; - old_rte.mask =3D 1; - __ioapic_write_entry(apic, pin, true, old_rte); - } - } - /* Not the initializer, for old gcc to cope. */ new_rte.raw =3D rte; =20 diff --git a/xen/drivers/passthrough/vtd/iommu.c b/xen/drivers/passthrough/= vtd/iommu.c index c7110af7c9..47b56f37a9 100644 --- a/xen/drivers/passthrough/vtd/iommu.c +++ b/xen/drivers/passthrough/vtd/iommu.c @@ -1482,7 +1482,7 @@ int domain_context_mapping_one( { struct domain_iommu *hd =3D dom_iommu(domain); struct context_entry *context, *context_entries, lctxt; - __uint128_t old; + __uint128_t res, old; uint64_t maddr; uint16_t seg =3D iommu->drhd->segment, prev_did =3D 0; struct domain *prev_dom =3D NULL; @@ -1580,55 +1580,23 @@ int domain_context_mapping_one( ASSERT(!context_fault_disable(lctxt)); } =20 - if ( cpu_has_cx16 ) - { - __uint128_t res =3D cmpxchg16b(context, &old, &lctxt.full); + res =3D cmpxchg16b(context, &old, &lctxt.full); =20 - /* - * Hardware does not update the context entry behind our backs, - * so the return value should match "old". - */ - if ( res !=3D old ) - { - if ( pdev ) - check_cleanup_domid_map(domain, pdev, iommu); - printk(XENLOG_ERR - "%pp: unexpected context entry %016lx_%016lx (expected = %016lx_%016lx)\n", - &PCI_SBDF(seg, bus, devfn), - (uint64_t)(res >> 64), (uint64_t)res, - (uint64_t)(old >> 64), (uint64_t)old); - rc =3D -EILSEQ; - goto unlock; - } - } - else if ( !prev_dom || !(mode & MAP_WITH_RMRR) ) - { - context_clear_present(*context); - iommu_sync_cache(context, sizeof(*context)); - - write_atomic(&context->hi, lctxt.hi); - /* No barrier should be needed between these two. */ - write_atomic(&context->lo, lctxt.lo); - } - else /* Best effort, updating DID last. */ + /* + * Hardware does not update the context entry behind our backs, + * so the return value should match "old". + */ + if ( res !=3D old ) { - /* - * By non-atomically updating the context entry's DID field last, - * during a short window in time TLB entries with the old domain = ID - * but the new page tables may be inserted. This could affect I/O - * of other devices using this same (old) domain ID. Such updati= ng - * therefore is not a problem if this was the only device associa= ted - * with the old domain ID. Diverting I/O of any of a dying domai= n's - * devices to the quarantine page tables is intended anyway. - */ - if ( !(mode & (MAP_OWNER_DYING | MAP_SINGLE_DEVICE)) ) - printk(XENLOG_WARNING VTDPREFIX - " %pp: reassignment may cause %pd data corruption\n", - &PCI_SBDF(seg, bus, devfn), prev_dom); - - write_atomic(&context->lo, lctxt.lo); - /* No barrier should be needed between these two. */ - write_atomic(&context->hi, lctxt.hi); + if ( pdev ) + check_cleanup_domid_map(domain, pdev, iommu); + printk(XENLOG_ERR + "%pp: unexpected context entry %016lx_%016lx (expected %01= 6lx_%016lx)\n", + &PCI_SBDF(seg, bus, devfn), + (uint64_t)(res >> 64), (uint64_t)res, + (uint64_t)(old >> 64), (uint64_t)old); + rc =3D -EILSEQ; + goto unlock; } =20 iommu_sync_cache(context, sizeof(struct context_entry)); @@ -2630,6 +2598,15 @@ static int __init cf_check vtd_setup(void) int ret; bool reg_inval_supported =3D true; =20 + if ( unlikely(!cpu_has_cx16) ) + { + printk(XENLOG_ERR VTDPREFIX + "IOMMU: CPU doesn't support CMPXCHG16B, disabling\n"); + + ret =3D -ENOSYS; + goto error; + } + if ( list_empty(&acpi_drhd_units) ) { ret =3D -ENODEV; @@ -2692,12 +2669,7 @@ static int __init cf_check vtd_setup(void) iommu_intremap =3D iommu_intremap_off; =20 #ifndef iommu_intpost - /* - * We cannot use posted interrupt if X86_FEATURE_CX16 is - * not supported, since we count on this feature to - * atomically update 16-byte IRTE in posted format. - */ - if ( !cap_intr_post(iommu->cap) || !iommu_intremap || !cpu_has_cx1= 6 ) + if ( !cap_intr_post(iommu->cap) || !iommu_intremap ) iommu_intpost =3D false; #endif =20 --=20 2.44.0 Teddy Astie | Vates XCP-ng Intern XCP-ng & Xen Orchestra - Vates solutions web: https://vates.tech