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

Re: [Xen-devel] [PATCH v3 04/38] arm/p2m: Add first altp2m HVMOP stubs

On 02/09/16 10:26, Sergej Proskurin wrote:
Hi Julien,

Hello Sergej,

On 09/01/2016 06:09 PM, Julien Grall wrote:
Hello Sergej,

On 16/08/16 23:16, Sergej Proskurin wrote:
This commit moves the altp2m-related code from x86 to ARM. Functions


However, this is not really true because the code is current patch is
not a verbatim copy.

Ok, I will adapt the commit msg to "copies and extends" in the next patch.

Lastly, what is the status to have x86 and ARM implementation of
do_altp2m_op merged?

It would allow us to get code clean-up more easily. I have in mind the
recent patch [1] from Paul Lai.

I am also worry to see the code diverging, for instance the locking is
likely needed on x86 too.

We believe that (while merging of both code bases definitely does makes
sense) it is out of scope in this patch. The changes you are suggesting
would further blow up this patch series. The current patch series is
already large enough and we really think we should keep focusing on the
implementation the ARM architecture in the first place. We agree that a
merge of both architectures is necessary but also strongly believe that
the merging should be done in a separate patch.

That's why you usually have small series to clean-up/move the code beforehand. Some of the patch in this series could have been avoided if you had a series beforehand to move the x86 code in the common code (which is very straight forward).

My concern here is this code will never get merged and it will continue to diverge. A lot of locking issue are also present in x86 path, so I don't understand why they should not be fixed now and wait until it get merged. So with the plan suggested, ARM and x86 does not benefit of each others patches.

Anyway, I would like to get an action from you to send a series merging the two implementation as soon as possible (i.e before Xen 4.9).

that are no yet supported notify the caller or print a BUG message
stating their absence.

Also, the struct arch_domain is extended with the altp2m_active
attribute, representing the current altp2m activity configuration of the

Signed-off-by: Sergej Proskurin <proskurin@xxxxxxxxxxxxx>
Cc: Stefano Stabellini <sstabellini@xxxxxxxxxx>
Cc: Julien Grall <julien.grall@xxxxxxx>
v2: Removed altp2m command-line option: Guard through HVM_PARAM_ALTP2M.
    Removed not used altp2m helper stubs in altp2m.h.

v3: Cosmetic fixes.

    Added domain lock in "do_altp2m_op" to avoid concurrent execution of
    altp2m-related HVMOPs.

    Added check making sure that HVM_PARAM_ALTP2M is set before
    execution of altp2m-related HVMOPs.
 xen/arch/arm/hvm.c           | 89
 xen/include/asm-arm/altp2m.h |  4 +-
 xen/include/asm-arm/domain.h |  3 ++
 3 files changed, 94 insertions(+), 2 deletions(-)

diff --git a/xen/arch/arm/hvm.c b/xen/arch/arm/hvm.c
index d999bde..45d51c6 100644
--- a/xen/arch/arm/hvm.c
+++ b/xen/arch/arm/hvm.c
@@ -32,6 +32,91 @@

 #include <asm/hypercall.h>

+#include <asm/altp2m.h>
+static int do_altp2m_op(XEN_GUEST_HANDLE_PARAM(void) arg)
+    struct xen_hvm_altp2m_op a;
+    struct domain *d = NULL;
+    int rc = 0;
+    if ( copy_from_guest(&a, arg, 1) )
+        return -EFAULT;
+    if ( a.pad1 || a.pad2 ||
+         (a.version != HVMOP_ALTP2M_INTERFACE_VERSION) ||
+         (a.cmd < HVMOP_altp2m_get_domain_state) ||
+         (a.cmd > HVMOP_altp2m_change_gfn) )
+        return -EINVAL;
+    d = (a.cmd != HVMOP_altp2m_vcpu_enable_notify) ?
+        rcu_lock_domain_by_any_id(a.domain) : rcu_lock_current_domain();
+    if ( d == NULL )
+        return -ESRCH;
+    /* Prevent concurrent execution of the following HVMOPs. */
+    domain_lock(d);

So you are not allowing concurrent call of set_mem_access on different
altp2m. Is it something that you plan to fix in the future?

Concurrent access of the altp2m interface, including the set_mem_access
on different altp2m views, is not performance relevant. However, we will
definitely think about which HVMOPs can be executed concurrently without
causing troubles.

It might be worth to add a TODO here.


Julien Grall

Xen-devel mailing list



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