From nobody Tue May 21 17:23:17 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=cloud.com ARC-Seal: i=1; a=rsa-sha256; t=1699895217; cv=none; d=zohomail.com; s=zohoarc; b=evZLwx53UuGPhM9pqRD4AXUdn8x8sf+y9XJdqrQF7aHNJMIGgAU7wrRy9fLcXOciE4o4cufpy2qe+KSCH5ssyB30DNVv+VGn3q4bKQ79s0fuo39unPMsT2AXoVZi/m7i4EHMdl+itvGJkN+g9n0iBfN2yzFH/f5oR3D59gyLdEU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=zohomail.com; s=zohoarc; t=1699895217; h=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=RMT7c/uiWiQZVRU+b+wZHF6Grzvo4YDAcSgfc5P5jVA=; b=hXaJ581wa8BqjI6pS+B0a61kB6f7vd5chtad6M5OD679sxpySJ1G1MdUAMoAUj1y0e/UmaJ1FsyCNqd75b5ifX0NmLbAceb48+EUTTlyhP3Ry2VdVi9PBY8Fq1NDLt3F/WgBcs8/M3aW3IvzdT+DqgJ+lHolXxPsUBwSNdHJtu4= 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 1699895217017402.78467219930155; Mon, 13 Nov 2023 09:06:57 -0800 (PST) Received: from list by lists.xenproject.org with outflank-mailman.631849.985562 (Exim 4.92) (envelope-from ) id 1r2aOG-0006g7-Qm; Mon, 13 Nov 2023 17:06:24 +0000 Received: by outflank-mailman (output) from mailman id 631849.985562; Mon, 13 Nov 2023 17:06: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 1r2aOG-0006g0-No; Mon, 13 Nov 2023 17:06:24 +0000 Received: by outflank-mailman (input) for mailman id 631849; Mon, 13 Nov 2023 17:06:23 +0000 Received: from se1-gles-flk1-in.inumbo.com ([94.247.172.50] helo=se1-gles-flk1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1r2aOF-0006fu-LA for xen-devel@lists.xenproject.org; Mon, 13 Nov 2023 17:06:23 +0000 Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [2a00:1450:4864:20::32c]) by se1-gles-flk1.inumbo.com (Halon) with ESMTPS id f7d490ba-8246-11ee-9b0e-b553b5be7939; Mon, 13 Nov 2023 18:06:21 +0100 (CET) Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-408382da7f0so38905355e9.0 for ; Mon, 13 Nov 2023 09:06:21 -0800 (PST) Received: from EMEAENGAAD19049.citrite.net (default-46-102-197-194.interdsl.co.uk. [46.102.197.194]) by smtp.gmail.com with ESMTPSA id v9-20020a5d43c9000000b0032da022855fsm5805800wrr.111.2023.11.13.09.06.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Nov 2023 09:06:20 -0800 (PST) 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: f7d490ba-8246-11ee-9b0e-b553b5be7939 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloud.com; s=cloud; t=1699895181; x=1700499981; 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=RMT7c/uiWiQZVRU+b+wZHF6Grzvo4YDAcSgfc5P5jVA=; b=a/tkkyxf1zD7/nmQyn6AI2Tx+NuRRWX1MLJ7TnNGOECNoguRQHnIeojqHUi60ijzRI mCK1OJAYPNdB79AxN7v8VzuVyZ0De8IiwgWInYri+jHP84BBuZhMHfDI3wbq8pAkbIbx UPJEffc5BaFTMpxZjhLHOQS5FesOmDiBFDKNc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699895181; x=1700499981; 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=RMT7c/uiWiQZVRU+b+wZHF6Grzvo4YDAcSgfc5P5jVA=; b=VPPQk7VlTL6aCbyhQPt9mCE44JffQ6QP3WqhVSX5zlnXXEAVHsS06h1HnG4NjMqSuh tW9FJzIPHGpG9lv05A4qASX6Idj4eZ2Iuj0cO+u1bdpwJOLvF77dysJ964Vly+Fwyy8J jYK3uxHvWYLXq6iL9T1Z5Hv+m1jjC2pG0M3Fbp/oZRCNPQx0AZPUh6rHC2dmUR5+JA38 Gq3n27bJY8CjhyLtzagqff1NgHaTA4mCn6KJ90sHv5nz6mtO5WxKV6hjF9hg/a5gMIPI ZtRJU65tComF0Ofcz67SSg3lqfi56csXV9XZoIENHBfNAYYgmGmK6oDqeG91/wKNRZnx KhXA== X-Gm-Message-State: AOJu0YyEenpGu7wqgrq6IqnKIZI7DhkgzT0LtLZ716PzPnrubMFeBqim PwDupbunjafZxkMvBTfyCQUmRaC6O5/h0BUKkYY= X-Google-Smtp-Source: AGHT+IEUIFDEjZ8xQCJ/lIc+4at+vBm1KT5Dn4H7fIPW60l+G2YIYq35bQOe1UO53pimBlWDq1pbow== X-Received: by 2002:a05:6000:186a:b0:32f:811f:5046 with SMTP id d10-20020a056000186a00b0032f811f5046mr4992740wri.11.1699895180712; Mon, 13 Nov 2023 09:06:20 -0800 (PST) From: Alejandro Vallejo To: Xen-devel Cc: Alejandro Vallejo , Jan Beulich , Andrew Cooper , =?UTF-8?q?Roger=20Pau=20Monn=C3=A9?= , Wei Liu Subject: [PATCH] xen/x86: On x2APIC mode, derive LDR from APIC_ID Date: Mon, 13 Nov 2023 16:50:23 +0000 Message-Id: <20231113165023.5824-1-alejandro.vallejo@cloud.com> X-Mailer: git-send-email 2.34.1 MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ZohoMail-DKIM: pass (identity @cloud.com) X-ZM-MESSAGEID: 1699895218519100001 Content-Type: text/plain; charset="utf-8" Both Intel and AMD manuals agree that on x2APIC mode, the APIC LDR and ID registers are derivable from each other through a fixed formula. Xen uses that formula, but applies it to vCPU IDs (which are sequential) rather than x2APIC_IDs (which are not, at the moment). As I understand it, this is an attempt to tightly pack vCPUs into clusters so each cluster has 16 vCPUs rather than 8, but this is problematic for OSs that might read the x2APIC_ID and internally derive LDR (or the other way around) This patch fixes the implementation so we follow the rules in the x2APIC spec(s). While in the neighborhood, replace the u32 type with the standard uint32_t Signed-off-by: Alejandro Vallejo --- xen/arch/x86/hvm/vlapic.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/xen/arch/x86/hvm/vlapic.c b/xen/arch/x86/hvm/vlapic.c index c7ce82d064..5a74e84445 100644 --- a/xen/arch/x86/hvm/vlapic.c +++ b/xen/arch/x86/hvm/vlapic.c @@ -1063,10 +1063,10 @@ static const struct hvm_mmio_ops vlapic_mmio_ops = =3D { =20 static void set_x2apic_id(struct vlapic *vlapic) { - u32 id =3D vlapic_vcpu(vlapic)->vcpu_id; - u32 ldr =3D ((id & ~0xf) << 12) | (1 << (id & 0xf)); + uint32_t id =3D vlapic_vcpu(vlapic)->vcpu_id * 2; + uint32_t ldr =3D ((id & ~0xf) << 12) | (1 << (id & 0xf)); =20 - vlapic_set_reg(vlapic, APIC_ID, id * 2); + vlapic_set_reg(vlapic, APIC_ID, id); vlapic_set_reg(vlapic, APIC_LDR, ldr); } =20 --=20 2.34.1