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

[Sergej Proskurin]

Hi Julien,

On 09/02/2016 12:12 PM, Julien Grall wrote:
> 
> 
> 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
>>>
>>> s/moves/copies/
>>>
>>> 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).
> 

I understand your concern and agree on working towards a merged version
between both architectures. Thank you.

 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
 domain.

 Signed-off-by: Sergej Proskurin 
 ---
 Cc: Stefano Stabellini 
 Cc: Julien Grall 
 ---
 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 

 +#include 
 +
 +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(, 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.
> 

I will add a TODO stating the upper idea, thank you.

Cheers,
~Sergej

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Julien Grall]

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


s/moves/copies/

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
domain.

Signed-off-by: Sergej Proskurin 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
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 

+#include 
+
+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(, 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.

Regards,

--
Julien Grall

___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel

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

[Sergej Proskurin]

Hi Julien,

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
> 
> s/moves/copies/
> 
> 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 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
>> domain.
>>
>> Signed-off-by: Sergej Proskurin 
>> ---
>> Cc: Stefano Stabellini 
>> Cc: Julien Grall 
>> ---
>> 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 
>>
>> +#include 
>> +
>> +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(, 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.

>> +
>> +if ( (a.cmd != HVMOP_altp2m_get_domain_state) &&
>> + (a.cmd != HVMOP_altp2m_set_domain_state) &&
>> + !altp2m_active(d) )
>> +{
>> +rc = -EOPNOTSUPP;
>> +goto out;
>> +}
>> +
>> +if ( !(d)->arch.hvm_domain.params[HVM_PARAM_ALTP2M] )
>> +{
>> +rc = -EINVAL;
>> +goto out;
>> +}
>> +
>> +if ( (rc = xsm_hvm_altp2mhvm_op(XSM_TARGET, d)) )
>> +goto out;
>> +
>> +switch ( a.cmd )
>> +{
>> +case HVMOP_altp2m_get_domain_state:
>> +rc = -EOPNOTSUPP;
>> +break;
>> +
>> +case HVMOP_altp2m_set_domain_state:
>> +rc = -EOPNOTSUPP;
>> +break;
>> +
>> +case HVMOP_altp2m_vcpu_enable_notify:
>> +rc = -EOPNOTSUPP;
>> +break;
>> +
>> +case HVMOP_altp2m_create_p2m:
>> +rc = -EOPNOTSUPP;
>> +break;
>> +
>> +case HVMOP_altp2m_destroy_p2m:
>> +rc = -EOPNOTSUPP;
>> +break;
>> +
>> +case HVMOP_altp2m_switch_p2m:
>> +rc = -EOPNOTSUPP;
>> +break;
>> +
>> +case HVMOP_altp2m_set_mem_access:
>> +rc = -EOPNOTSUPP;
>> +break;
>> +
>> +case HVMOP_altp2m_change_gfn:
>> +rc = -EOPNOTSUPP;
>> +break;
>> +}
>> +
>> +out:
>> +domain_unlock(d);
>> +rcu_unlock_domain(d);
>> +
>> +return rc;
>> +}
>> +
>>  long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
>>  {
>>  

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

[Julien Grall]

Hello Sergej,

On 16/08/16 23:16, Sergej Proskurin wrote:

This commit moves the altp2m-related code from x86 to ARM. Functions


s/moves/copies/

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


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.



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
domain.

Signed-off-by: Sergej Proskurin 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
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 

+#include 
+
+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(, 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?



+
+if ( (a.cmd != HVMOP_altp2m_get_domain_state) &&
+ (a.cmd != HVMOP_altp2m_set_domain_state) &&
+ !altp2m_active(d) )
+{
+rc = -EOPNOTSUPP;
+goto out;
+}
+
+if ( !(d)->arch.hvm_domain.params[HVM_PARAM_ALTP2M] )
+{
+rc = -EINVAL;
+goto out;
+}
+
+if ( (rc = xsm_hvm_altp2mhvm_op(XSM_TARGET, d)) )
+goto out;
+
+switch ( a.cmd )
+{
+case HVMOP_altp2m_get_domain_state:
+rc = -EOPNOTSUPP;
+break;
+
+case HVMOP_altp2m_set_domain_state:
+rc = -EOPNOTSUPP;
+break;
+
+case HVMOP_altp2m_vcpu_enable_notify:
+rc = -EOPNOTSUPP;
+break;
+
+case HVMOP_altp2m_create_p2m:
+rc = -EOPNOTSUPP;
+break;
+
+case HVMOP_altp2m_destroy_p2m:
+rc = -EOPNOTSUPP;
+break;
+
+case HVMOP_altp2m_switch_p2m:
+rc = -EOPNOTSUPP;
+break;
+
+case HVMOP_altp2m_set_mem_access:
+rc = -EOPNOTSUPP;
+break;
+
+case HVMOP_altp2m_change_gfn:
+rc = -EOPNOTSUPP;
+break;
+}
+
+out:
+domain_unlock(d);
+rcu_unlock_domain(d);
+
+return rc;
+}
+
 long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
 long rc = 0;
@@ -80,6 +165,10 @@ long do_hvm_op(unsigned long op, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 rc = -EINVAL;
 break;

+case HVMOP_altp2m:
+rc = do_altp2m_op(arg);
+break;
+
 default:
 {
 gdprintk(XENLOG_DEBUG, "HVMOP op=%lu: not implemented\n", op);
diff --git a/xen/include/asm-arm/altp2m.h b/xen/include/asm-arm/altp2m.h
index a87747a..0711796 100644
--- a/xen/include/asm-arm/altp2m.h
+++ b/xen/include/asm-arm/altp2m.h
@@ -2,6 +2,7 @@
  * Alternate p2m
  *
  * Copyright (c) 2014, Intel Corporation.
+ * Copyright (c) 2016, Sergej Proskurin .
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms and conditions of the GNU General Public License,
@@ -24,8 +25,7 @@
 /* Alternate p2m on/off per domain */
 static inline bool_t altp2m_active(const struct domain *d)
 {
-/* Not implemented on ARM. */
-return 0;
+return d->arch.altp2m_active;
 }

 /* Alternate p2m VCPU */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 9452fcd..cc4bda0 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -126,6 +126,9 @@ struct arch_domain
 paddr_t 

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

[Sergej Proskurin]

This commit moves the altp2m-related code from x86 to ARM. Functions
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
domain.

Signed-off-by: Sergej Proskurin 
---
Cc: Stefano Stabellini 
Cc: Julien Grall 
---
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 
 
+#include 
+
+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(, 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);
+
+if ( (a.cmd != HVMOP_altp2m_get_domain_state) &&
+ (a.cmd != HVMOP_altp2m_set_domain_state) &&
+ !altp2m_active(d) )
+{
+rc = -EOPNOTSUPP;
+goto out;
+}
+
+if ( !(d)->arch.hvm_domain.params[HVM_PARAM_ALTP2M] )
+{
+rc = -EINVAL;
+goto out;
+}
+
+if ( (rc = xsm_hvm_altp2mhvm_op(XSM_TARGET, d)) )
+goto out;
+
+switch ( a.cmd )
+{
+case HVMOP_altp2m_get_domain_state:
+rc = -EOPNOTSUPP;
+break;
+
+case HVMOP_altp2m_set_domain_state:
+rc = -EOPNOTSUPP;
+break;
+
+case HVMOP_altp2m_vcpu_enable_notify:
+rc = -EOPNOTSUPP;
+break;
+
+case HVMOP_altp2m_create_p2m:
+rc = -EOPNOTSUPP;
+break;
+
+case HVMOP_altp2m_destroy_p2m:
+rc = -EOPNOTSUPP;
+break;
+
+case HVMOP_altp2m_switch_p2m:
+rc = -EOPNOTSUPP;
+break;
+
+case HVMOP_altp2m_set_mem_access:
+rc = -EOPNOTSUPP;
+break;
+
+case HVMOP_altp2m_change_gfn:
+rc = -EOPNOTSUPP;
+break;
+}
+
+out:
+domain_unlock(d);
+rcu_unlock_domain(d);
+
+return rc;
+}
+
 long do_hvm_op(unsigned long op, XEN_GUEST_HANDLE_PARAM(void) arg)
 {
 long rc = 0;
@@ -80,6 +165,10 @@ long do_hvm_op(unsigned long op, 
XEN_GUEST_HANDLE_PARAM(void) arg)
 rc = -EINVAL;
 break;
 
+case HVMOP_altp2m:
+rc = do_altp2m_op(arg);
+break;
+
 default:
 {
 gdprintk(XENLOG_DEBUG, "HVMOP op=%lu: not implemented\n", op);
diff --git a/xen/include/asm-arm/altp2m.h b/xen/include/asm-arm/altp2m.h
index a87747a..0711796 100644
--- a/xen/include/asm-arm/altp2m.h
+++ b/xen/include/asm-arm/altp2m.h
@@ -2,6 +2,7 @@
  * Alternate p2m
  *
  * Copyright (c) 2014, Intel Corporation.
+ * Copyright (c) 2016, Sergej Proskurin .
  *
  * This program is free software; you can redistribute it and/or modify it
  * under the terms and conditions of the GNU General Public License,
@@ -24,8 +25,7 @@
 /* Alternate p2m on/off per domain */
 static inline bool_t altp2m_active(const struct domain *d)
 {
-/* Not implemented on ARM. */
-return 0;
+return d->arch.altp2m_active;
 }
 
 /* Alternate p2m VCPU */
diff --git a/xen/include/asm-arm/domain.h b/xen/include/asm-arm/domain.h
index 9452fcd..cc4bda0 100644
--- a/xen/include/asm-arm/domain.h
+++ b/xen/include/asm-arm/domain.h
@@ -126,6 +126,9 @@ struct arch_domain
 paddr_t efi_acpi_gpa;
 paddr_t efi_acpi_len;
 #endif
+
+/* altp2m: allow multiple copies of host p2m */
+bool_t altp2m_active;
 }  __cacheline_aligned;
 
 struct arch_vcpu
-- 
2.9.0


___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel