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

Re: [PATCH v2 5/8] xen/arm/gic: Allow routing/removing interrupt to running VMs


  • To: Julien Grall <julien@xxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • From: Henry Wang <xin.wang2@xxxxxxx>
  • Date: Mon, 20 May 2024 09:01:29 +0800
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=xen.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none (0)
  • 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=jAEzMUEC39/7LxxheMN8lvN9AclDqhjSvZZfjpOUyIg=; b=bI30MG9lTltSKUfJ3yVCGhJDVCoBXPtgcRIS2MIQ0dl0wqWScuBzaMCUdCfpXRCepsfPErAGe9TY/a3hs4yULsszQ9aOu/uQabQ1q2fFM1HAThVQifNze1OBDfy1MpuNkC9Z0boFwJ7alXPGujb25QtHfqoGTX3Dl47NqYgHYXF+DVjEh3YvKDy8v5+sPW599adkatZ7wIleXhJkJoe0W+WNghTYexyqNzm39pCTUuPY3mw2q8JrzUVeOH6Qi3A9EheOaZKmDVTrjozC1NBWzPLj9zyqKhnRdu/BbW3aa3YACRDfEK7aFqKm04Lh/J6Kqd+P3ZsBtLYMxvP4HSTvwQ==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ise0+4BTQSr6FGJCLw61MTRng3sQl8txOHZpJR1LCx6nQbI7NLdjrn3M0HTN5AQvFqkwPoR7QU+z6eEzxj0slS42XUFExsN/Dt/ggNJJOWvktOoxSWxcoo1jbX649pQlYNjz7QkE9oxZMwGdpsx0VYreIM85VhNPWCq29rJGUzXpQZXyMHGRKaNyhM+lP87+bluilQyAE6Dt4kDGfvsXc5JW4CNx+63p20OZ/thugPwhJfdmaNGOGecj8lqtKpE09ycjauW0w0HdbAnvTEX7fDvf1hBwj2+j+RZ12dztrXxzGJynQ0XcXcWM0tCWw/C3arGQGOCl5EDaW6fZgwrQbw==
  • Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>, Bertrand Marquis <bertrand.marquis@xxxxxxx>, Michal Orzel <michal.orzel@xxxxxxx>, "Volodymyr Babchuk" <Volodymyr_Babchuk@xxxxxxxx>
  • Delivery-date: Mon, 20 May 2024 01:01:48 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

Hi Julien,

On 5/19/2024 7:08 PM, Julien Grall wrote:
Hi,

On 17/05/2024 07:03, Henry Wang wrote:
@@ -444,14 +444,18 @@ int vgic_connect_hw_irq(struct domain *d, struct vcpu *v, unsigned int virq,
      {
          /* The VIRQ should not be already enabled by the guest */

This comment needs to be updated.

Yes, sorry. I will update this and the one in the new vGIC in v3.

          if ( !p->desc &&
-             !test_bit(GIC_IRQ_GUEST_ENABLED, &p->status) )
+             !test_bit(GIC_IRQ_GUEST_ENABLED, &p->status) &&
+             !test_bit(GIC_IRQ_GUEST_VISIBLE, &p->status) &&
+             !test_bit(GIC_IRQ_GUEST_ACTIVE, &p->status) )
              p->desc = desc;
          else
              ret = -EBUSY;
      }
      else
      {
-        if ( desc && p->desc != desc )
+        if ( desc && p->desc != desc &&
+             (test_bit(GIC_IRQ_GUEST_VISIBLE, &p->status) ||
+              test_bit(GIC_IRQ_GUEST_ACTIVE, &p->status)) )

This should be

+        if ( (desc && p->desc != desc) ||
+             test_bit(GIC_IRQ_GUEST_VISIBLE, &p->status) ||
+             test_bit(GIC_IRQ_GUEST_ACTIVE, &p->status) )
Looking at gic_set_lr(), we first check p->desc, before setting IRQ_GUEST_VISIBLE.

I can't find a common lock, so what would guarantee that p->desc is not going to be used or IRQ_GUEST_VISIBLE set afterwards?

I think the gic_set_lr() is supposed to be called with v->arch.vgic.lock taken, at least the current two callers (gic_raise_guest_irq() and gic_restore_pending_irqs()) are doing it this way. Would this address your concern? Thanks.

Kind regards,
Henry



 


Rackspace

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