All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michał Leszczyński" <michal.leszczynski@cert.pl>
To: xen-devel@lists.xenproject.org
Cc: Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>,
	luwei.kang@intel.com, Wei Liu <wl@xen.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	Michal Leszczynski <michal.leszczynski@cert.pl>,
	Ian Jackson <ian.jackson@eu.citrix.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	tamas.lengyel@intel.com
Subject: [PATCH v5 01/11] memory: batch processing in acquire_resource()
Date: Sun,  5 Jul 2020 20:54:54 +0200	[thread overview]
Message-ID: <02415890e4e8211513b495228c790e1d16de767f.1593974333.git.michal.leszczynski@cert.pl> (raw)
In-Reply-To: <cover.1593974333.git.michal.leszczynski@cert.pl>
In-Reply-To: <cover.1593974333.git.michal.leszczynski@cert.pl>

From: Michal Leszczynski <michal.leszczynski@cert.pl>

Allow to acquire large resources by allowing acquire_resource()
to process items in batches, using hypercall continuation.

Be aware that this modifies the behavior of acquire_resource
call with frame_list=NULL. While previously it would return
the size of internal array (32), with this patch it returns
the maximal quantity of frames that could be requested at once,
i.e. UINT_MAX >> MEMOP_EXTENT_SHIFT.

Signed-off-by: Michal Leszczynski <michal.leszczynski@cert.pl>
---
 xen/common/memory.c | 49 ++++++++++++++++++++++++++++++++++++++++-----
 1 file changed, 44 insertions(+), 5 deletions(-)

diff --git a/xen/common/memory.c b/xen/common/memory.c
index 714077c1e5..eb42f883df 100644
--- a/xen/common/memory.c
+++ b/xen/common/memory.c
@@ -1046,10 +1046,12 @@ static int acquire_grant_table(struct domain *d, unsigned int id,
 }
 
 static int acquire_resource(
-    XEN_GUEST_HANDLE_PARAM(xen_mem_acquire_resource_t) arg)
+    XEN_GUEST_HANDLE_PARAM(xen_mem_acquire_resource_t) arg,
+    unsigned long *start_extent)
 {
     struct domain *d, *currd = current->domain;
     xen_mem_acquire_resource_t xmar;
+    uint32_t total_frames;
     /*
      * The mfn_list and gfn_list (below) arrays are ok on stack for the
      * moment since they are small, but if they need to grow in future
@@ -1069,7 +1071,7 @@ static int acquire_resource(
         if ( xmar.nr_frames )
             return -EINVAL;
 
-        xmar.nr_frames = ARRAY_SIZE(mfn_list);
+        xmar.nr_frames = UINT_MAX >> MEMOP_EXTENT_SHIFT;
 
         if ( __copy_field_to_guest(arg, &xmar, nr_frames) )
             return -EFAULT;
@@ -1077,8 +1079,28 @@ static int acquire_resource(
         return 0;
     }
 
+    total_frames = xmar.nr_frames;
+
+    /* Is the size too large for us to encode a continuation? */
+    if ( unlikely(xmar.nr_frames > (UINT_MAX >> MEMOP_EXTENT_SHIFT)) )
+        return -EINVAL;
+
+    if ( *start_extent )
+    {
+        /*
+         * Check whether start_extent is in bounds, as this
+         * value if visible to the calling domain.
+         */
+        if ( *start_extent > xmar.nr_frames )
+            return -EINVAL;
+
+        xmar.frame += *start_extent;
+        xmar.nr_frames -= *start_extent;
+        guest_handle_add_offset(xmar.frame_list, *start_extent);
+    }
+
     if ( xmar.nr_frames > ARRAY_SIZE(mfn_list) )
-        return -E2BIG;
+        xmar.nr_frames = ARRAY_SIZE(mfn_list);
 
     rc = rcu_lock_remote_domain_by_id(xmar.domid, &d);
     if ( rc )
@@ -1135,6 +1157,14 @@ static int acquire_resource(
         }
     }
 
+    if ( !rc )
+    {
+        *start_extent += xmar.nr_frames;
+
+        if ( *start_extent != total_frames )
+            rc = -ERESTART;
+    }
+
  out:
     rcu_unlock_domain(d);
 
@@ -1599,8 +1629,17 @@ long do_memory_op(unsigned long cmd, XEN_GUEST_HANDLE_PARAM(void) arg)
 #endif
 
     case XENMEM_acquire_resource:
-        rc = acquire_resource(
-            guest_handle_cast(arg, xen_mem_acquire_resource_t));
+        do {
+            rc = acquire_resource(
+                guest_handle_cast(arg, xen_mem_acquire_resource_t),
+                &start_extent);
+
+            if ( hypercall_preempt_check() )
+                return hypercall_create_continuation(
+                    __HYPERVISOR_memory_op, "lh",
+                    op | (start_extent << MEMOP_EXTENT_SHIFT), arg);
+        } while ( rc == -ERESTART );
+
         break;
 
     default:
-- 
2.17.1



  reply	other threads:[~2020-07-05 18:56 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-05 18:54 [PATCH v5 00/11] Implement support for external IPT monitoring Michał Leszczyński
2020-07-05 18:54 ` Michał Leszczyński [this message]
2020-07-05 18:54 ` [PATCH v5 02/11] x86/vmx: add Intel PT MSR definitions Michał Leszczyński
2020-07-05 18:54 ` [PATCH v5 03/11] x86/vmx: add IPT cpu feature Michał Leszczyński
2020-07-05 18:54 ` [PATCH v5 04/11] common: add vmtrace_pt_size domain parameter Michał Leszczyński
2020-07-06 10:13   ` Michał Leszczyński
2020-07-06 10:45   ` Julien Grall
2020-07-05 18:54 ` [PATCH v5 05/11] tools/libxl: add vmtrace_pt_size parameter Michał Leszczyński
2020-07-05 19:02   ` Michał Leszczyński
2020-07-06 10:53     ` Julien Grall
2020-07-05 18:54 ` [PATCH v5 06/11] x86/hvm: processor trace interface in HVM Michał Leszczyński
2020-07-05 19:11   ` Michał Leszczyński
2020-07-06  8:31     ` Jan Beulich
2020-07-06 10:31       ` Michał Leszczyński
2020-07-06  8:42   ` Roger Pau Monné
2020-07-06 10:09     ` Michał Leszczyński
2020-07-06 14:38       ` Roger Pau Monné
2020-07-05 18:55 ` [PATCH v5 07/11] x86/vmx: implement IPT in VMX Michał Leszczyński
2020-07-05 18:55 ` [PATCH v5 08/11] x86/mm: add vmtrace_buf resource type Michał Leszczyński
2020-07-06 10:28   ` Julien Grall
2020-07-05 18:55 ` [PATCH v5 09/11] x86/domctl: add XEN_DOMCTL_vmtrace_op Michał Leszczyński
2020-07-06 10:31   ` Julien Grall
2020-07-06 10:37     ` Jan Beulich
2020-07-06 10:38       ` Julien Grall
2020-07-06 11:20         ` Jan Beulich
2020-07-05 18:55 ` [PATCH v5 10/11] tools/libxc: add xc_vmtrace_* functions Michał Leszczyński
2020-07-05 18:55 ` [PATCH v5 11/11] tools/proctrace: add proctrace tool Michał Leszczyński
2020-07-05 18:58   ` Michał Leszczyński
2020-07-06  8:33     ` Jan Beulich
2020-07-06  9:47       ` Andrew Cooper
2020-07-06 10:18         ` Michał Leszczyński

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=02415890e4e8211513b495228c790e1d16de767f.1593974333.git.michal.leszczynski@cert.pl \
    --to=michal.leszczynski@cert.pl \
    --cc=andrew.cooper3@citrix.com \
    --cc=george.dunlap@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=luwei.kang@intel.com \
    --cc=sstabellini@kernel.org \
    --cc=tamas.lengyel@intel.com \
    --cc=wl@xen.org \
    --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.