All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleksandr Andrushchenko <andr2000@gmail.com>
To: xen-devel@lists.xenproject.org
Cc: julien@xen.org, sstabellini@kernel.org,
	oleksandr_tyshchenko@epam.com, volodymyr_babchuk@epam.com,
	Artem_Mygaiev@epam.com, roger.pau@citrix.com, jbeulich@suse.com,
	andrew.cooper3@citrix.com, george.dunlap@citrix.com,
	paul@xen.org, bertrand.marquis@arm.com, rahul.singh@arm.com,
	Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Subject: [PATCH v6 6/7] xen/arm: process pending vPCI map/unmap operations
Date: Fri,  5 Nov 2021 08:33:25 +0200	[thread overview]
Message-ID: <20211105063326.939843-7-andr2000@gmail.com> (raw)
In-Reply-To: <20211105063326.939843-1-andr2000@gmail.com>

From: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>

vPCI may map and unmap PCI device memory (BARs) being passed through which
may take a lot of time. For this those operations may be deferred to be
performed later, so that they can be safely preempted.

Currently this deferred processing is happening in common IOREQ code
which doesn't seem to be the right place for x86 and is even more
doubtful because IOREQ may not be enabled for Arm at all.
So, for Arm the pending vPCI work may have no chance to be executed
if the processing is left as is in the common IOREQ code only.
For that reason make vPCI processing happen in arch specific code.

Please be aware that there are a few outstanding TODOs affecting this
code path, see xen/drivers/vpci/header.c:map_range and
xen/drivers/vpci/header.c:vpci_process_pending.

Signed-off-by: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
---
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: Paul Durrant <paul@xen.org>

Since v5:
 - check_for_vcpu_work: vPCI addition is moved before the
   vcpu_ioreq__handle_completion(v). This is to avoid differences
   with the x86 version. (Julien)
Since v2:
 - update commit message with more insight on x86, IOREQ and Arm
 - restored order of invocation for IOREQ and vPCI processing (Jan)
Since v1:
 - Moved the check for pending vpci work from the common IOREQ code
   to hvm_do_resume on x86
 - Re-worked the code for Arm to ensure we don't miss pending vPCI work
---
 xen/arch/arm/traps.c   | 13 +++++++++++++
 xen/arch/x86/hvm/hvm.c |  6 ++++++
 xen/common/ioreq.c     |  9 ---------
 3 files changed, 19 insertions(+), 9 deletions(-)

diff --git a/xen/arch/arm/traps.c b/xen/arch/arm/traps.c
index 219ab3c3fbde..8757210a798b 100644
--- a/xen/arch/arm/traps.c
+++ b/xen/arch/arm/traps.c
@@ -34,6 +34,7 @@
 #include <xen/symbols.h>
 #include <xen/version.h>
 #include <xen/virtual_region.h>
+#include <xen/vpci.h>
 
 #include <public/sched.h>
 #include <public/xen.h>
@@ -2290,6 +2291,18 @@ static bool check_for_vcpu_work(void)
 {
     struct vcpu *v = current;
 
+    if ( has_vpci(v->domain) )
+    {
+        bool pending;
+
+        local_irq_enable();
+        pending = vpci_process_pending(v);
+        local_irq_disable();
+
+        if ( pending )
+            return true;
+    }
+
 #ifdef CONFIG_IOREQ_SERVER
     if ( domain_has_ioreq_server(v->domain) )
     {
diff --git a/xen/arch/x86/hvm/hvm.c b/xen/arch/x86/hvm/hvm.c
index eee365711d63..096a61b7ea02 100644
--- a/xen/arch/x86/hvm/hvm.c
+++ b/xen/arch/x86/hvm/hvm.c
@@ -546,6 +546,12 @@ void hvm_do_resume(struct vcpu *v)
 
     pt_restore_timer(v);
 
+    if ( has_vpci(v->domain) && vpci_process_pending(v) )
+    {
+        raise_softirq(SCHEDULE_SOFTIRQ);
+        return;
+    }
+
     if ( !vcpu_ioreq_handle_completion(v) )
         return;
 
diff --git a/xen/common/ioreq.c b/xen/common/ioreq.c
index d732dc045df9..689d256544c8 100644
--- a/xen/common/ioreq.c
+++ b/xen/common/ioreq.c
@@ -25,9 +25,7 @@
 #include <xen/lib.h>
 #include <xen/paging.h>
 #include <xen/sched.h>
-#include <xen/softirq.h>
 #include <xen/trace.h>
-#include <xen/vpci.h>
 
 #include <asm/guest_atomics.h>
 #include <asm/ioreq.h>
@@ -212,19 +210,12 @@ static bool wait_for_io(struct ioreq_vcpu *sv, ioreq_t *p)
 
 bool vcpu_ioreq_handle_completion(struct vcpu *v)
 {
-    struct domain *d = v->domain;
     struct vcpu_io *vio = &v->io;
     struct ioreq_server *s;
     struct ioreq_vcpu *sv;
     enum vio_completion completion;
     bool res = true;
 
-    if ( has_vpci(d) && vpci_process_pending(v) )
-    {
-        raise_softirq(SCHEDULE_SOFTIRQ);
-        return false;
-    }
-
     while ( (sv = get_pending_vcpu(v, &s)) != NULL )
         if ( !wait_for_io(sv, get_ioreq(s, v)) )
             return false;
-- 
2.25.1



  parent reply	other threads:[~2021-11-05  6:33 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-05  6:33 [PATCH v6 0/7] PCI devices passthrough on Arm, part 2 Oleksandr Andrushchenko
2021-11-05  6:33 ` [PATCH v6 1/7] xen/arm: rename DEVICE_PCI to DEVICE_PCI_HOSTBRIDGE Oleksandr Andrushchenko
2021-11-16 18:26   ` Julien Grall
2021-11-05  6:33 ` [PATCH v6 2/7] xen/arm: add pci-domain for disabled devices Oleksandr Andrushchenko
2021-11-16 18:48   ` Julien Grall
2021-11-17  6:56     ` Oleksandr Andrushchenko
2021-11-17 21:33       ` Julien Grall
2021-11-18  7:13         ` Oleksandr Andrushchenko
2021-11-22 15:29           ` Julien Grall
2021-11-22 16:23             ` Oleksandr Andrushchenko
2021-11-22 17:17               ` Julien Grall
2021-11-23  6:31                 ` Oleksandr Andrushchenko
2021-11-23 16:05                   ` Julien Grall
2021-11-23 16:44                     ` Oleksandr Andrushchenko
2021-11-23 17:15                       ` Julien Grall
2021-11-24  6:54                         ` Oleksandr Andrushchenko
2021-11-05  6:33 ` [PATCH v6 3/7] xen/arm: setup MMIO range trap handlers for hardware domain Oleksandr Andrushchenko
2021-11-09  9:20   ` Oleksandr Andrushchenko
2021-11-16 19:12   ` Julien Grall
2021-11-18  7:27     ` Oleksandr Andrushchenko
2021-11-18 10:46       ` Oleksandr Andrushchenko
2021-11-22 17:36         ` Julien Grall
2021-11-23  6:58           ` Oleksandr Andrushchenko
2021-11-23 16:12             ` Julien Grall
2021-11-23 16:41               ` Oleksandr Andrushchenko
2021-11-23 16:58                 ` Julien Grall
2021-11-24  7:22                   ` Oleksandr Andrushchenko
2021-11-05  6:33 ` [PATCH v6 4/7] xen/arm: do not map PCI ECAM and MMIO space to Domain-0's p2m Oleksandr Andrushchenko
2021-11-23 16:42   ` Julien Grall
2021-11-24  7:42     ` Oleksandr Andrushchenko
2021-11-05  6:33 ` [PATCH v6 5/7] xen/arm: do not map IRQs and memory for disabled devices Oleksandr Andrushchenko
2021-11-16 19:22   ` Julien Grall
2021-11-18  6:59     ` Oleksandr Andrushchenko
2021-11-22 19:31       ` Julien Grall
2021-11-23  7:23         ` Oleksandr Andrushchenko
2021-11-05  6:33 ` Oleksandr Andrushchenko [this message]
2021-11-05  7:40   ` [PATCH v6 6/7] xen/arm: process pending vPCI map/unmap operations Jan Beulich
2021-11-17 21:26   ` Julien Grall
2021-11-05  6:33 ` [PATCH v6 7/7] xen/arm: do not use void pointer in pci_host_common_probe Oleksandr Andrushchenko
2021-11-17 11:12   ` Rahul Singh
2021-11-17 21:45   ` Julien Grall
2021-11-18  7:34     ` Oleksandr Andrushchenko
2021-11-22 17:48       ` Julien Grall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20211105063326.939843-7-andr2000@gmail.com \
    --to=andr2000@gmail.com \
    --cc=Artem_Mygaiev@epam.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=bertrand.marquis@arm.com \
    --cc=george.dunlap@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=oleksandr_andrushchenko@epam.com \
    --cc=oleksandr_tyshchenko@epam.com \
    --cc=paul@xen.org \
    --cc=rahul.singh@arm.com \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=volodymyr_babchuk@epam.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.