[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[PATCH] arm/vgic-v3: fix virq offset in the rank


  • To: <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Hongda Deng <Hongda.Deng@xxxxxxx>
  • Date: Fri, 15 Jul 2022 18:46:20 +0800
  • Arc-authentication-results: i=2; mx.microsoft.com 1; spf=pass (sender ip is 63.35.35.123) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com; arc=pass (0 oda=1 ltdi=1 spf=[1,1,smtp.mailfrom=arm.com] dmarc=[1,1,header.from=arm.com])
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 40.67.248.234) smtp.rcpttodomain=lists.xenproject.org smtp.mailfrom=arm.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=arm.com; dkim=none (message not signed); arc=none
  • Arc-message-signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=be62q+eqSPIlABcw9yzXa9Ay/ADAWlWUIE8vacmfxBo=; b=evcSwLdbMHeElTF1UDGeK46ka1vgPmvZ+aI5aXxP5Y3XxWwIuweL/DGgj+WUDR/bRpoyA3k3uacKKj40jFk6rvWBeEQgx2uAlGCydr1hz7aM/ERDMgQO/Boi/vcOlTYp69du70rDWsZxHu2cattuzRuTAKXgBtbssyleD57TBZlaJb25yzU2iT+RYkkmRjzJ6fL+rl7agBSVOMlliw1MhYe9cTTF/JEWYNDR6OYCXtT6P2lTLrO6lHxLjxTU4oTIgD/8NOEv6Fh6nKmbXE4B6hqLlXA9YCHfSCvYCMJwcq+DcK9S8VpOXc52Ho7KU6nTat0IcaKA+9baorgjCQyLrw==
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=be62q+eqSPIlABcw9yzXa9Ay/ADAWlWUIE8vacmfxBo=; b=ehA43hgOaky8UXBEkgmVfvqMzoi81CQa6PXBSBiIFZ9labHug4cY7n4cy7ihJRUI7NTngb0rEvRSpK4ABTh5diD89K0uYF4dRM4QbNE1LoOxpERuHbBnSq58VfmwWsC+U5RtrYH7cNPgrgQJNUvTfT6RwrLt1GXzQ9MvdUj1Ntr9G7rQluZy4hJ8KVz/V+xU09upQdjS/XZY4SOS0ZsBoZ3fo0+oO1IHghPSeZmOYkg5V54wVeS2W1EFdXqFbO3+mDb3AX9TwjlfJJkRPB8ePON5+v9i3lLQpWFBaWs23UT38VXabPBUdjB96PPhb5jRqk7wPuAz/Lja5pDiRYJMBw==
  • Arc-seal: i=2; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=pass; b=WLZKzkvyJEmMQrkyjiSiyLQC94kONBpsD/4YlDSpsjG5COF0aBje1zvfhizukdmr2Umsqu9pRDa9pFVo0mVCpdARTp1Ozn8F19w5P/WU3HUfN8Gw1t9Fv8ya4cHlrWEQUWJk5BLE8ip6N+MHojHj/tM2sGuBJqEQRsBpa9BiZnEflmQYdagi1m+arCHsMvTsqmSv4/Esd5Kx9Z2JBhG1pDkv0sTZV2NVVkznzHdhorAY2Pe3FCsK4p4CdYINYywLOzbpgQaQ27nnadAuztlDxrMOK5IDTxaA4cnGeSxX0mLlpxZQyd0/7JVEDJFGpjjXGH7f/cOiN4WnEpfj1dDfcA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lOC2GatxIcjXdx2iR8xsmi88/DFQ6IxbEQmJ7jlRxCWyYP5/V6To/KRokjsM596yCbd0vTYp9k/SvnpdDtg/BCsNHlNCQzzVNCjYqoxfvv2jcDBUdDnhpexxWNB0BYrPvmr7QPzNAVs2WJkDZIONkhaKV5UD+RZ7a8w6Kg9zz3UZ5kiRAGU4fvGUNFHn1oNCrIXij0pin0dghzclorfjRARbGi0Wx/em959DlrSTnJt0DZfMRkE9t2HD/UePdyfdBVZZgrdk6t8JWwye/KaHWvotjdBXOEtHiSOry5/zEtYCTqJtgtqyymsJJ/TUuG6J2pYh+PYYMfYhDO8U3BnDpw==
  • Cc: <nd@xxxxxxx>, Hongda Deng <Hongda.Deng@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Delivery-date: Fri, 15 Jul 2022 10:47:04 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Nodisclaimer: true

When vgic performs irouter registers emulation, to get the target vCPU
via virq conveniently, Xen doesn't store the irouter value directly,
instead it will use the value (affinities) in irouter to calculate the
target vCPU, and then save the target vCPU in irq rank->vCPU[offset].
But there seems to be a bug in the way the offset is calculated when
vgic tries to store irouter.

When vgic tries to get the target vcpu, it first calculates the target
vcpu index via
  int target = read_atomic(&rank->vcpu[virq & INTERRUPT_RANK_MASK]);
and then get the target vcpu via
  v->domain->vcpu[target];

When vgic tries to store irouter for one virq, the target vcpu index
in the rank is got via
  offset &= virq & INTERRUPT_RANK_MASK;
finally it gets the target vcpu via
  d->vcpu[read_atomic(&rank->vcpu[offset])];

There is a difference between them when gets the target vcpu index in
the rank.

Here (virq & INTERRUPT_RANK_MASK) would already get the  target vcpu
index in the rank, so we don't need the '&' before '=' when calculate
the offset.

For example, the target vcpu index in the rank should be 6 for virq 38,
but vgic will get offset=0 when vgic stores the irouter for this virq,
and finally vgic will access wrong target vcpu index in the rank when
it updates the irouter.

Fixes: 5d495f4349b5 ("xen/arm: vgic: Optimize the way to store the target vCPU 
in the rank")
Signed-off-by: Hongda Deng <Hongda.Deng@xxxxxxx>
---
 xen/arch/arm/vgic-v3.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/xen/arch/arm/vgic-v3.c b/xen/arch/arm/vgic-v3.c
index e4ba9a6476..7fb99a9ff2 100644
--- a/xen/arch/arm/vgic-v3.c
+++ b/xen/arch/arm/vgic-v3.c
@@ -135,7 +135,7 @@ static void vgic_store_irouter(struct domain *d, struct 
vgic_irq_rank *rank,
     ASSERT(virq >= 32);
 
     /* Get the index in the rank */
-    offset &= virq & INTERRUPT_RANK_MASK;
+    offset = virq & INTERRUPT_RANK_MASK;
 
     new_vcpu = vgic_v3_irouter_to_vcpu(d, irouter);
     old_vcpu = d->vcpu[read_atomic(&rank->vcpu[offset])];
-- 
2.25.1




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.