From nobody Mon Dec 2 14:37:49 2024 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; 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=reject dis=none) header.from=citrix.com ARC-Seal: i=1; a=rsa-sha256; t=1730365079; cv=none; d=zohomail.com; s=zohoarc; b=bxjyWeeuIjlaDxEi59KH0Wzp1t4KTpUgyWDpG8Tbk0xvcL6xRyDjXzO/U6uLiXFg//2AbLVFgVQIGMkbtXh/jBTQ6t4afYHr0YULzGKZRjWQLSUDpc2zEFAhkE3loBxW+AblvYj2ZkmuCyoqFL0WJB5uNIAGLEnV8uoZEirWMA4= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1730365079; h=Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:From:From:List-Subscribe:List-Post:List-Id:List-Help:List-Unsubscribe:MIME-Version:Message-ID:Sender:Subject:Subject:To:To:Message-Id:Reply-To; bh=3uizCbIY2s+221YKyswHMeA/NQsRqfyL2z9npNMZBLs=; b=SMc8Xa4OQhW52c/2wEGgi91jn7YyFUFKDgI8K/G+Fy7ut7KkH/6IkD5YJxrFsP1ubpQyMyg7xh9X5hV1Q87LcSH5F/XkMD8LPG1SsVZjdnYZRsJyB78K9RpO0QeYXjagIY7kiPeo/L/yUoQrS3V5Pb8ngDWM+6nLbKPZ/+w8p0Q= ARC-Authentication-Results: i=1; mx.zohomail.com; dkim=pass; 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=reject dis=none) Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 1730365079807499.1787788174005; Thu, 31 Oct 2024 01:57:59 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.828482.1243368 (Exim 4.92) (envelope-from ) id 1t6Qzc-0004ER-TL; Thu, 31 Oct 2024 08:57:24 +0000 Received: by outflank-mailman (output) from mailman id 828482.1243368; Thu, 31 Oct 2024 08:57:24 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1t6Qzc-0004EK-Qp; Thu, 31 Oct 2024 08:57:24 +0000 Received: by outflank-mailman (input) for mailman id 828482; Thu, 31 Oct 2024 08:57:23 +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 1t6Qzb-0004EE-L7 for xen-devel@lists.xenproject.org; Thu, 31 Oct 2024 08:57:23 +0000 Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [2a00:1450:4864:20::536]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 229626d4-9766-11ef-a0c3-8be0dac302b0; Thu, 31 Oct 2024 09:57:19 +0100 (CET) Received: by mail-ed1-x536.google.com with SMTP id 4fb4d7f45d1cf-5c9150f9ed4so976856a12.0 for ; Thu, 31 Oct 2024 01:57:19 -0700 (PDT) Received: from localhost ([213.195.115.182]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-a9e56645dcbsm43101266b.177.2024.10.31.01.57.18 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 31 Oct 2024 01:57:18 -0700 (PDT) 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: 229626d4-9766-11ef-a0c3-8be0dac302b0 X-Custom-Connection: eyJyZW1vdGVpcCI6IjJhMDA6MTQ1MDo0ODY0OjIwOjo1MzYiLCJoZWxvIjoibWFpbC1lZDEteDUzNi5nb29nbGUuY29tIn0= X-Custom-Transaction: eyJpZCI6IjIyOTYyNmQ0LTk3NjYtMTFlZi1hMGMzLThiZTBkYWMzMDJiMCIsInRzIjoxNzMwMzY1MDM5LjYyMTIxNSwic2VuZGVyIjoicm9nZXIucGF1QGNsb3VkLmNvbSIsInJlY2lwaWVudCI6Inhlbi1kZXZlbEBsaXN0cy54ZW5wcm9qZWN0Lm9yZyJ9 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1730365039; x=1730969839; darn=lists.xenproject.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=3uizCbIY2s+221YKyswHMeA/NQsRqfyL2z9npNMZBLs=; b=CyOC8RWGuIHxNX7nYU+rjhkjHQRcB8KpcP4GWokakMhCTm8ZZhsRig6f7Y/FBHJ0yO qyCfz+1DjkqmtowKIRDhhtqN/KM2I0LxxNKNg56t2rlnAH+3pRdEqq0+df0pkiVgFb9G tcKyiq/EJtVd0Ts5HDCHhrwEAwvFO5e8g6LCE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1730365039; x=1730969839; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=3uizCbIY2s+221YKyswHMeA/NQsRqfyL2z9npNMZBLs=; b=Fh1m0h7D1VMmt1PMzVB6vIwvNRORwEMAIyUI+RrRjBxHy6MoIO2RY4JZxeN8GpwDM8 CuIjnqEkOown6GAprE7WXyBy3TB4sVRQ2Q9pKYsr4Z2zAb503oroenyIjzg8fisePJK+ e2dXdWDKpYy2sNA0YD8dzyvtIOvySCmpPn6b4q8mi9NQ2w0VUHM/czZoQKOVPdvuR6eI EGcQl0ujwuwadTaaJhfKnktyROKvNlFlXpNXT755hkiXAjYbCE08WBEu8qlKlDjkuQ7w 0X1UNFlImN9EVB/A80GUq01zqTkH7UCfs3KZ5EJ8G+wO9al1Cab00kdYlvUoKZcJyUya SIpw== X-Gm-Message-State: AOJu0Ywz6+et33T76VnIHmTlIZTYARDXh7/glvtA7pnkGp55K5B6fZY+ JFRpSfNIqHut5PojVlOS/w0J6K88qivGf+TTR/90GoMqWdKPHk7hs5hnjnkaZoB3znjd4nIwe17 U X-Google-Smtp-Source: AGHT+IE5P3Oc9RQt3z9HwuijyhXGCE0M0uw/3AfDk+hylBvDGef/9D3D7SXdf0BNoeM5at29INqNNQ== X-Received: by 2002:a17:907:970a:b0:a9a:4a:284a with SMTP id a640c23a62f3a-a9de5d8690amr1839220466b.26.1730365038748; Thu, 31 Oct 2024 01:57:18 -0700 (PDT) From: Roger Pau Monne To: xen-devel@lists.xenproject.org Cc: Roger Pau Monne , Jan Beulich , Andrew Cooper , Willi Junga , David Woodhouse Subject: [PATCH v4] x86/io-apic: fix directed EOI when using AMD-Vi interrupt remapping Date: Thu, 31 Oct 2024 09:57:13 +0100 Message-ID: <20241031085713.6156-1-roger.pau@citrix.com> X-Mailer: git-send-email 2.46.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @citrix.com) X-ZM-MESSAGEID: 1730365081227116600 When using AMD-Vi interrupt remapping the vector field in the IO-APIC RTE is repurposed to contain part of the offset into the remapping table. Previou= s to 2ca9fbd739b8 Xen had logic so that the offset into the interrupt remapping table would match the vector. Such logic was mandatory for end of interrup= t to work, since the vector field (even when not containing a vector) is used by= the IO-APIC to find for which pin the EOI must be performed. A simple solution wold be to read the IO-APIC RTE each time an EOI is to be performed, so the raw value of the vector field can be obtained. However that's likely to perform poorly. Instead introduce a cache to store the EOI handles when using interrupt remapping, so that the IO-APIC driver can translate pins into EOI handles without having to read the IO-APIC RTE entr= y. Note that to simplify the logic such cache is used unconditionally when interrupt remapping is enabled, even if strictly it would only be required for AMD-Vi. Reported-by: Willi Junga Suggested-by: David Woodhouse Fixes: 2ca9fbd739b8 ('AMD IOMMU: allocate IRTE entries instead of using a s= tatic mapping') Signed-off-by: Roger Pau Monn=C3=A9 Reviewed-by: Jan Beulich Tested-by: Marek Marczykowski-G=C3=B3recki --- Changes since v3: - Remove the usage of a sentinel value (again). - Allocate an initialize the cache in enable_IO_APIC(). - Fix MISRA compliance. - Use xvmalloc. Changes since v2: - Restore sentinel value. Changes since v1: - s/apic_pin_eoi/io_apic_pin_eoi/. - Expand comment about io_apic_pin_eoi usage and layout. - Use uint8_t instead of unsigned int as array type. - Do not use a sentinel value. --- xen/arch/x86/io_apic.c | 76 +++++++++++++++++++++++++++++++++++++++--- 1 file changed, 71 insertions(+), 5 deletions(-) diff --git a/xen/arch/x86/io_apic.c b/xen/arch/x86/io_apic.c index e40d2f7dbd75..4e5ee2b890a0 100644 --- a/xen/arch/x86/io_apic.c +++ b/xen/arch/x86/io_apic.c @@ -29,6 +29,7 @@ #include #include #include +#include =20 #include #include @@ -71,6 +72,24 @@ static int apic_pin_2_gsi_irq(int apic, int pin); =20 static vmask_t *__read_mostly vector_map[MAX_IO_APICS]; =20 +/* + * Store the EOI handle when using interrupt remapping. + * + * If using AMD-Vi interrupt remapping the IO-APIC redirection entry remap= ped + * format repurposes the vector field to store the offset into the Interru= pt + * Remap table. This breaks directed EOI, as the CPU vector no longer mat= ches + * the contents of the RTE vector field. Add a translation cache so that + * directed EOI uses the value in the RTE vector field when interrupt rema= pping + * is enabled. + * + * Intel VT-d Xen code still stores the CPU vector in the RTE vector field= when + * using the remapped format, but use the translation cache uniformly in o= rder + * to avoid extra logic to differentiate between VT-d and AMD-Vi. + * + * The matrix is accessed as [#io-apic][#pin]. + */ +static uint8_t **io_apic_pin_eoi; + static void share_vector_maps(unsigned int src, unsigned int dst) { unsigned int pin; @@ -273,6 +292,17 @@ void __ioapic_write_entry( { __io_apic_write(apic, 0x11 + 2 * pin, eu.w2); __io_apic_write(apic, 0x10 + 2 * pin, eu.w1); + /* + * Might be called before io_apic_pin_eoi is allocated. Entry wil= l be + * initialized to the RTE value once the cache is allocated. + * + * The vector field is only cached for raw RTE writes when using I= R. + * In that case the vector field might have been repurposed to sto= re + * something different than the CPU vector, and hence need to be c= ached + * for performing EOI. + */ + if ( io_apic_pin_eoi ) + io_apic_pin_eoi[apic][pin] =3D e.vector; } else iommu_update_ire_from_apic(apic, pin, e.raw); @@ -288,18 +318,36 @@ static void ioapic_write_entry( spin_unlock_irqrestore(&ioapic_lock, flags); } =20 -/* EOI an IO-APIC entry. Vector may be -1, indicating that it should be +/* + * EOI an IO-APIC entry. Vector may be -1, indicating that it should be * worked out using the pin. This function expects that the ioapic_lock is * being held, and interrupts are disabled (or there is a good reason not * to), and that if both pin and vector are passed, that they refer to the - * same redirection entry in the IO-APIC. */ + * same redirection entry in the IO-APIC. + * + * If using Interrupt Remapping the vector is always ignored because the R= TE + * remapping format might have repurposed the vector field and a cached va= lue + * of the EOI handle to use is obtained based on the provided apic and pin + * values. + */ static void __io_apic_eoi(unsigned int apic, unsigned int vector, unsigned= int pin) { /* Prefer the use of the EOI register if available */ if ( ioapic_has_eoi_reg(apic) ) { - /* If vector is unknown, read it from the IO-APIC */ - if ( vector =3D=3D IRQ_VECTOR_UNASSIGNED ) + if ( io_apic_pin_eoi ) + /* + * If the EOI handle is cached use it. When using AMD-Vi IR th= e CPU + * vector no longer matches the vector field in the RTE, becau= se + * the RTE remapping format repurposes the field. + * + * The value in the RTE vector field must always be used to si= gnal + * which RTE to EOI, hence use the cached value which always + * mirrors the contents of the raw RTE vector field. + */ + vector =3D io_apic_pin_eoi[apic][pin]; + else if ( vector =3D=3D IRQ_VECTOR_UNASSIGNED ) + /* If vector is unknown, read it from the IO-APIC */ vector =3D __ioapic_read_entry(apic, pin, true).vector; =20 *(IO_APIC_BASE(apic)+16) =3D vector; @@ -1317,12 +1365,30 @@ void __init enable_IO_APIC(void) vector_map[apic] =3D vector_map[0]; } =20 + if ( iommu_intremap !=3D iommu_intremap_off ) + { + io_apic_pin_eoi =3D xvmalloc_array(typeof(*io_apic_pin_eoi), nr_io= apics); + BUG_ON(!io_apic_pin_eoi); + } + for(apic =3D 0; apic < nr_ioapics; apic++) { int pin; - /* See if any of the pins is in ExtINT mode */ + + if ( io_apic_pin_eoi ) + { + io_apic_pin_eoi[apic] =3D xvmalloc_array(typeof(**io_apic_pin_= eoi), + nr_ioapic_entries[apic]= ); + BUG_ON(!io_apic_pin_eoi[apic]); + } + + /* See if any of the pins is in ExtINT mode and cache EOI handle */ for (pin =3D 0; pin < nr_ioapic_entries[apic]; pin++) { struct IO_APIC_route_entry entry =3D ioapic_read_entry(apic, p= in, false); =20 + if ( io_apic_pin_eoi ) + io_apic_pin_eoi[apic][pin] =3D + ioapic_read_entry(apic, pin, true).vector; + /* If the interrupt line is enabled and in ExtInt mode * I have found the pin where the i8259 is connected. */ --=20 2.46.0