All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/2] vm_event: sync domctl
@ 2015-12-23 14:53 Tamas K Lengyel
  2015-12-23 14:53 ` [PATCH 2/2] vm_event: Add altp2m info to HVM events as well Tamas K Lengyel
                   ` (2 more replies)
  0 siblings, 3 replies; 21+ messages in thread
From: Tamas K Lengyel @ 2015-12-23 14:53 UTC (permalink / raw)
  To: xen-devel
  Cc: Tamas K Lengyel, Wei Liu, Ian Campbell, Razvan Cojocaru,
	Stefano Stabellini, Ian Jackson

Introduce new vm_event domctl option which allows an event subscriber
to request all vCPUs not currently pending a vm_event request to be paused,
thus allowing the subscriber to sync up on the state of the domain. This
is especially useful when the subscribed wants to disable certain events
from being delivered and wants to ensure no more requests are pending on the
ring before doing so.

Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Razvan Cojocaru <rcojocaru@bitdefender.com>
Signed-off-by: Tamas K Lengyel <tamas@tklengyel.com>
---
 tools/libxc/include/xenctrl.h | 11 +++++++++++
 tools/libxc/xc_vm_event.c     | 16 ++++++++++++++++
 xen/common/vm_event.c         | 23 +++++++++++++++++++++++
 xen/include/public/domctl.h   | 14 +++++++++++++-
 4 files changed, 63 insertions(+), 1 deletion(-)

diff --git a/tools/libxc/include/xenctrl.h b/tools/libxc/include/xenctrl.h
index 01a6dda..27bb907 100644
--- a/tools/libxc/include/xenctrl.h
+++ b/tools/libxc/include/xenctrl.h
@@ -2433,6 +2433,17 @@ int xc_monitor_emulate_each_rep(xc_interface *xch, domid_t domain_id,
                                 bool enable);
 
 /***
+ * xc_vm_event_sync_on can be used by a vm_event subscriber to pause all vCPUs
+ * that do not currently have a pending vm_event request. This allows the
+ * subscriber to sync up on the domain's status and process all outstanding
+ * vm_event requests without any new ones being placed on the ring. A caller
+ * of xc_vm_event_sync_on can resume these vCPUs by calling
+ * xc_vm_event_sync_off.
+ */
+int xc_vm_event_sync_on(xc_interface *xch, domid_t domain_id);
+int xc_vm_event_sync_off(xc_interface *xch, domid_t domain_id);
+
+/***
  * Memory sharing operations.
  *
  * Unles otherwise noted, these calls return 0 on succes, -1 and errno on
diff --git a/tools/libxc/xc_vm_event.c b/tools/libxc/xc_vm_event.c
index 2fef96a..6b39908 100644
--- a/tools/libxc/xc_vm_event.c
+++ b/tools/libxc/xc_vm_event.c
@@ -156,3 +156,19 @@ void *xc_vm_event_enable(xc_interface *xch, domid_t domain_id, int param,
 
     return ring_page;
 }
+
+int xc_vm_event_sync_on(xc_interface *xch, domid_t domain_id)
+{
+    return xc_vm_event_control(xch, domain_id,
+                               XEN_VM_EVENT_ENABLE,
+                               XEN_DOMCTL_VM_EVENT_OP_SYNC,
+                               NULL);
+}
+
+int xc_vm_event_sync_off(xc_interface *xch, domid_t domain_id)
+{
+    return xc_vm_event_control(xch, domain_id,
+                               XEN_VM_EVENT_DISABLE,
+                               XEN_DOMCTL_VM_EVENT_OP_SYNC,
+                               NULL);
+}
diff --git a/xen/common/vm_event.c b/xen/common/vm_event.c
index 28a7add..b8298bd 100644
--- a/xen/common/vm_event.c
+++ b/xen/common/vm_event.c
@@ -726,6 +726,29 @@ int vm_event_domctl(struct domain *d, xen_domctl_vm_event_op_t *vec,
     break;
 #endif
 
+    case XEN_DOMCTL_VM_EVENT_OP_SYNC:
+    {
+        struct vcpu *v;
+        rc = 0;
+
+        switch( vec->op )
+        {
+        case XEN_VM_EVENT_ENABLE:
+            for_each_vcpu( d, v )
+                if ( !atomic_read(&v->vm_event_pause_count) )
+                    vcpu_pause(v);
+            break;
+
+        default:
+            for_each_vcpu( d, v )
+                if ( !atomic_read(&v->vm_event_pause_count) )
+                    vcpu_unpause(v);
+            break;
+        };
+    }
+    break;
+
+
     default:
         rc = -ENOSYS;
     }
diff --git a/xen/include/public/domctl.h b/xen/include/public/domctl.h
index 7a56b3f..486c667 100644
--- a/xen/include/public/domctl.h
+++ b/xen/include/public/domctl.h
@@ -749,7 +749,8 @@ struct xen_domctl_gdbsx_domstatus {
  * sharing, monitor and paging. This hypercall allows one to
  * control these rings (enable/disable), as well as to signal
  * to the hypervisor to pull responses (resume) from the given
- * ring.
+ * ring. Sync will pause/unpause all vCPUs which don't have
+ * a pending vm_event.
  */
 #define XEN_VM_EVENT_ENABLE               0
 #define XEN_VM_EVENT_DISABLE              1
@@ -810,6 +811,17 @@ struct xen_domctl_gdbsx_domstatus {
  */
 #define XEN_DOMCTL_VM_EVENT_OP_SHARING           3
 
+/*
+ * SYNC is a special vm_event operation where all vCPUs get paused
+ * to allow the toolstack to sync up with the state of the domain,
+ * without any new vm_event requests being produced by the domain
+ * on any of the rings.
+ * When issued with ENABLE all the vCPUs get paused that aren't
+ * already paused for a vm_event request. When issued with DISABLE
+ * or RESUME the vCPUs without a pending vm_event request get unpaused.
+ */
+#define XEN_DOMCTL_VM_EVENT_OP_SYNC           4
+
 /* Use for teardown/setup of helper<->hypervisor interface for paging, 
  * access and sharing.*/
 struct xen_domctl_vm_event_op {
-- 
2.1.4

^ permalink raw reply related	[flat|nested] 21+ messages in thread

* [PATCH 2/2] vm_event: Add altp2m info to HVM events as well
  2015-12-23 14:53 [PATCH 1/2] vm_event: sync domctl Tamas K Lengyel
@ 2015-12-23 14:53 ` Tamas K Lengyel
  2015-12-23 15:42   ` Razvan Cojocaru
  2016-01-06 11:32   ` Jan Beulich
  2015-12-23 15:41 ` [PATCH 1/2] vm_event: sync domctl Razvan Cojocaru
  2016-01-06 15:48 ` Ian Campbell
  2 siblings, 2 replies; 21+ messages in thread
From: Tamas K Lengyel @ 2015-12-23 14:53 UTC (permalink / raw)
  To: xen-devel
  Cc: Andrew Cooper, Tamas K Lengyel, Keir Fraser, Jan Beulich,
	Razvan Cojocaru

Add altp2m information to HVM events as well when altp2m is active.

Cc: Razvan Cojocaru <rcojocaru@bitdefender.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Tamas K Lengyel <tamas@tklengyel.com>
---
 xen/arch/x86/hvm/event.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/xen/arch/x86/hvm/event.c b/xen/arch/x86/hvm/event.c
index 73c8f14..a3d4892 100644
--- a/xen/arch/x86/hvm/event.c
+++ b/xen/arch/x86/hvm/event.c
@@ -22,6 +22,7 @@
 #include <xen/paging.h>
 #include <asm/hvm/event.h>
 #include <asm/monitor.h>
+#include <asm/altp2m.h>
 #include <public/vm_event.h>
 
 static void hvm_event_fill_regs(vm_event_request_t *req)
@@ -83,6 +84,12 @@ static int hvm_event_traps(uint8_t sync, vm_event_request_t *req)
         vm_event_vcpu_pause(curr);
     }
 
+    if ( altp2m_active(currd) )
+    {
+        req->flags |= VM_EVENT_FLAG_ALTERNATE_P2M;
+        req->altp2m_idx = vcpu_altp2m(curr).p2midx;
+    }
+
     hvm_event_fill_regs(req);
     vm_event_put_request(currd, &currd->vm_event->monitor, req);
 
-- 
2.1.4

^ permalink raw reply related	[flat|nested] 21+ messages in thread

* Re: [PATCH 1/2] vm_event: sync domctl
  2015-12-23 14:53 [PATCH 1/2] vm_event: sync domctl Tamas K Lengyel
  2015-12-23 14:53 ` [PATCH 2/2] vm_event: Add altp2m info to HVM events as well Tamas K Lengyel
@ 2015-12-23 15:41 ` Razvan Cojocaru
  2015-12-23 17:17   ` Andrew Cooper
  2016-01-06 15:48 ` Ian Campbell
  2 siblings, 1 reply; 21+ messages in thread
From: Razvan Cojocaru @ 2015-12-23 15:41 UTC (permalink / raw)
  To: Tamas K Lengyel, xen-devel
  Cc: Wei Liu, Ian Jackson, Ian Campbell, Stefano Stabellini

On 12/23/2015 04:53 PM, Tamas K Lengyel wrote:
> Introduce new vm_event domctl option which allows an event subscriber
> to request all vCPUs not currently pending a vm_event request to be paused,
> thus allowing the subscriber to sync up on the state of the domain. This
> is especially useful when the subscribed wants to disable certain events
> from being delivered and wants to ensure no more requests are pending on the
> ring before doing so.
> 
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Cc: Razvan Cojocaru <rcojocaru@bitdefender.com>
> Signed-off-by: Tamas K Lengyel <tamas@tklengyel.com>

This certainly looks very interesting. Would xc_domain_pause() not be
enough for your use case then?


Thanks,
Razvan

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 2/2] vm_event: Add altp2m info to HVM events as well
  2015-12-23 14:53 ` [PATCH 2/2] vm_event: Add altp2m info to HVM events as well Tamas K Lengyel
@ 2015-12-23 15:42   ` Razvan Cojocaru
  2015-12-23 17:18     ` Andrew Cooper
  2016-01-06 11:32   ` Jan Beulich
  1 sibling, 1 reply; 21+ messages in thread
From: Razvan Cojocaru @ 2015-12-23 15:42 UTC (permalink / raw)
  To: Tamas K Lengyel, xen-devel; +Cc: Andrew Cooper, Keir Fraser, Jan Beulich

On 12/23/2015 04:53 PM, Tamas K Lengyel wrote:
> Add altp2m information to HVM events as well when altp2m is active.
> 
> Cc: Razvan Cojocaru <rcojocaru@bitdefender.com>
> Cc: Keir Fraser <keir@xen.org>
> Cc: Jan Beulich <jbeulich@suse.com>
> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
> Signed-off-by: Tamas K Lengyel <tamas@tklengyel.com>
> ---
>  xen/arch/x86/hvm/event.c | 7 +++++++
>  1 file changed, 7 insertions(+)

Acked-by: Razvan Cojocaru <rcojocaru@bitdefender.com>


Thanks,
Razvan

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 1/2] vm_event: sync domctl
  2015-12-23 15:41 ` [PATCH 1/2] vm_event: sync domctl Razvan Cojocaru
@ 2015-12-23 17:17   ` Andrew Cooper
  2015-12-23 18:11     ` Tamas K Lengyel
  0 siblings, 1 reply; 21+ messages in thread
From: Andrew Cooper @ 2015-12-23 17:17 UTC (permalink / raw)
  To: Razvan Cojocaru, Tamas K Lengyel, xen-devel
  Cc: Ian Jackson, Wei Liu, Ian Campbell, Stefano Stabellini

On 23/12/2015 15:41, Razvan Cojocaru wrote:
> On 12/23/2015 04:53 PM, Tamas K Lengyel wrote:
>> Introduce new vm_event domctl option which allows an event subscriber
>> to request all vCPUs not currently pending a vm_event request to be paused,
>> thus allowing the subscriber to sync up on the state of the domain. This
>> is especially useful when the subscribed wants to disable certain events
>> from being delivered and wants to ensure no more requests are pending on the
>> ring before doing so.
>>
>> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
>> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>> Cc: Ian Campbell <ian.campbell@citrix.com>
>> Cc: Wei Liu <wei.liu2@citrix.com>
>> Cc: Razvan Cojocaru <rcojocaru@bitdefender.com>
>> Signed-off-by: Tamas K Lengyel <tamas@tklengyel.com>
> This certainly looks very interesting. Would xc_domain_pause() not be
> enough for your use case then?

I second this query.  I would have thought xc_domain_pause() does
exactly what you want in this case.

The code provided is racy, as it is liable to alter which pause
references it takes/releases depending on what other pause/unpause
actions are being made.

~Andrew

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 2/2] vm_event: Add altp2m info to HVM events as well
  2015-12-23 15:42   ` Razvan Cojocaru
@ 2015-12-23 17:18     ` Andrew Cooper
  0 siblings, 0 replies; 21+ messages in thread
From: Andrew Cooper @ 2015-12-23 17:18 UTC (permalink / raw)
  To: Razvan Cojocaru, Tamas K Lengyel, xen-devel; +Cc: Keir Fraser, Jan Beulich

On 23/12/2015 15:42, Razvan Cojocaru wrote:
> On 12/23/2015 04:53 PM, Tamas K Lengyel wrote:
>> Add altp2m information to HVM events as well when altp2m is active.
>>
>> Cc: Razvan Cojocaru <rcojocaru@bitdefender.com>
>> Cc: Keir Fraser <keir@xen.org>
>> Cc: Jan Beulich <jbeulich@suse.com>
>> Cc: Andrew Cooper <andrew.cooper3@citrix.com>
>> Signed-off-by: Tamas K Lengyel <tamas@tklengyel.com>
>> ---
>>  xen/arch/x86/hvm/event.c | 7 +++++++
>>  1 file changed, 7 insertions(+)
> Acked-by: Razvan Cojocaru <rcojocaru@bitdefender.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 1/2] vm_event: sync domctl
  2015-12-23 17:17   ` Andrew Cooper
@ 2015-12-23 18:11     ` Tamas K Lengyel
  2015-12-23 19:11       ` Razvan Cojocaru
  2015-12-23 19:14       ` Andrew Cooper
  0 siblings, 2 replies; 21+ messages in thread
From: Tamas K Lengyel @ 2015-12-23 18:11 UTC (permalink / raw)
  To: Andrew Cooper
  Cc: Wei Liu, Ian Campbell, Razvan Cojocaru, Stefano Stabellini,
	Ian Jackson, Xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 2275 bytes --]

On Wed, Dec 23, 2015 at 6:17 PM, Andrew Cooper <andrew.cooper3@citrix.com>
wrote:

> On 23/12/2015 15:41, Razvan Cojocaru wrote:
> > On 12/23/2015 04:53 PM, Tamas K Lengyel wrote:
> >> Introduce new vm_event domctl option which allows an event subscriber
> >> to request all vCPUs not currently pending a vm_event request to be
> paused,
> >> thus allowing the subscriber to sync up on the state of the domain. This
> >> is especially useful when the subscribed wants to disable certain events
> >> from being delivered and wants to ensure no more requests are pending
> on the
> >> ring before doing so.
> >>
> >> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> >> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >> Cc: Ian Campbell <ian.campbell@citrix.com>
> >> Cc: Wei Liu <wei.liu2@citrix.com>
> >> Cc: Razvan Cojocaru <rcojocaru@bitdefender.com>
> >> Signed-off-by: Tamas K Lengyel <tamas@tklengyel.com>
> > This certainly looks very interesting. Would xc_domain_pause() not be
> > enough for your use case then?
>
> I second this query.  I would have thought xc_domain_pause() does
> exactly what you want in this case.
>

The problem is in what order the responses are processed. I may not be
correct about the logic but here is what my impression was:
xc_domain_unpause resumes all vCPUs even if there is still a vm_event
response that has not been processed. Now, if the subscriber set response
flags (altp2m switch, singlestep toggle, etc) those actions would not be
properly performed on the vCPU before it's resumed. If the subscriber
processes all requests and signals via the event channel that the responses
are on the ring, then calls xc_domain_unpause, we can still have a race
between processing the responses from the ring and unpausing the vCPU.


> The code provided is racy, as it is liable to alter which pause
> references it takes/releases depending on what other pause/unpause
> actions are being made.
>

It's understood that the user would not use xc_domain_pause/unpause while
using vm_event responses with response flags specified. Even then, it was
already racy IMHO if the user called xc_domain_unpause before processing
requests from the vm_event ring that originally paused the vCPU, so this
doesn't change that situation.

Tamas

[-- Attachment #1.2: Type: text/html, Size: 3311 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 1/2] vm_event: sync domctl
  2015-12-23 18:11     ` Tamas K Lengyel
@ 2015-12-23 19:11       ` Razvan Cojocaru
  2015-12-23 19:14       ` Andrew Cooper
  1 sibling, 0 replies; 21+ messages in thread
From: Razvan Cojocaru @ 2015-12-23 19:11 UTC (permalink / raw)
  To: Tamas K Lengyel, Andrew Cooper
  Cc: Xen-devel, Stefano Stabellini, Wei Liu, Ian Jackson, Ian Campbell

On 12/23/2015 08:11 PM, Tamas K Lengyel wrote:
> 
> 
> On Wed, Dec 23, 2015 at 6:17 PM, Andrew Cooper
> <andrew.cooper3@citrix.com <mailto:andrew.cooper3@citrix.com>> wrote:
> 
>     On 23/12/2015 15:41, Razvan Cojocaru wrote:
>     > On 12/23/2015 04:53 PM, Tamas K Lengyel wrote:
>     >> Introduce new vm_event domctl option which allows an event subscriber
>     >> to request all vCPUs not currently pending a vm_event request to be paused,
>     >> thus allowing the subscriber to sync up on the state of the domain. This
>     >> is especially useful when the subscribed wants to disable certain events
>     >> from being delivered and wants to ensure no more requests are pending on the
>     >> ring before doing so.
>     >>
>     >> Cc: Ian Jackson <ian.jackson@eu.citrix.com <mailto:ian.jackson@eu.citrix.com>>
>     >> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com
>     <mailto:stefano.stabellini@eu.citrix.com>>
>     >> Cc: Ian Campbell <ian.campbell@citrix.com <mailto:ian.campbell@citrix.com>>
>     >> Cc: Wei Liu <wei.liu2@citrix.com <mailto:wei.liu2@citrix.com>>
>     >> Cc: Razvan Cojocaru <rcojocaru@bitdefender.com <mailto:rcojocaru@bitdefender.com>>
>     >> Signed-off-by: Tamas K Lengyel <tamas@tklengyel.com <mailto:tamas@tklengyel.com>>
>     > This certainly looks very interesting. Would xc_domain_pause() not be
>     > enough for your use case then?
> 
>     I second this query.  I would have thought xc_domain_pause() does
>     exactly what you want in this case.
> 
> 
> The problem is in what order the responses are processed. I may not be
> correct about the logic but here is what my impression was:
> xc_domain_unpause resumes all vCPUs even if there is still a vm_event
> response that has not been processed. Now, if the subscriber set
> response flags (altp2m switch, singlestep toggle, etc) those actions
> would not be properly performed on the vCPU before it's resumed. If the
> subscriber processes all requests and signals via the event channel that
> the responses are on the ring, then calls xc_domain_unpause, we can
> still have a race between processing the responses from the ring and
> unpausing the vCPU.
>  
> 
>     The code provided is racy, as it is liable to alter which pause
>     references it takes/releases depending on what other pause/unpause
>     actions are being made.
> 
> 
> It's understood that the user would not use xc_domain_pause/unpause
> while using vm_event responses with response flags specified. Even then,
> it was already racy IMHO if the user called xc_domain_unpause before
> processing requests from the vm_event ring that originally paused the
> vCPU, so this doesn't change that situation.

There are a bunch of checks in vcpu_wake() (xen/common/schedule.c) that
I've always assumed guard against the problem you're describing. I may
be wrong (I don't have any experience with the scheduling code), but
even if I am, I still think having xc_domain_pause() /
xc_domain_unpause() behave correctly is better than adding a new libxc
function. Is that an unreasonable goal?


Thanks,
Razvan

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 1/2] vm_event: sync domctl
  2015-12-23 18:11     ` Tamas K Lengyel
  2015-12-23 19:11       ` Razvan Cojocaru
@ 2015-12-23 19:14       ` Andrew Cooper
  2015-12-23 20:55         ` Tamas K Lengyel
  1 sibling, 1 reply; 21+ messages in thread
From: Andrew Cooper @ 2015-12-23 19:14 UTC (permalink / raw)
  To: Tamas K Lengyel
  Cc: Wei Liu, Ian Campbell, Razvan Cojocaru, Stefano Stabellini,
	Ian Jackson, Xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 4040 bytes --]

On 23/12/2015 18:11, Tamas K Lengyel wrote:
>
>
> On Wed, Dec 23, 2015 at 6:17 PM, Andrew Cooper
> <andrew.cooper3@citrix.com <mailto:andrew.cooper3@citrix.com>> wrote:
>
>     On 23/12/2015 15:41, Razvan Cojocaru wrote:
>     > On 12/23/2015 04:53 PM, Tamas K Lengyel wrote:
>     >> Introduce new vm_event domctl option which allows an event
>     subscriber
>     >> to request all vCPUs not currently pending a vm_event request
>     to be paused,
>     >> thus allowing the subscriber to sync up on the state of the
>     domain. This
>     >> is especially useful when the subscribed wants to disable
>     certain events
>     >> from being delivered and wants to ensure no more requests are
>     pending on the
>     >> ring before doing so.
>     >>
>     >> Cc: Ian Jackson <ian.jackson@eu.citrix.com
>     <mailto:ian.jackson@eu.citrix.com>>
>     >> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com
>     <mailto:stefano.stabellini@eu.citrix.com>>
>     >> Cc: Ian Campbell <ian.campbell@citrix.com
>     <mailto:ian.campbell@citrix.com>>
>     >> Cc: Wei Liu <wei.liu2@citrix.com <mailto:wei.liu2@citrix.com>>
>     >> Cc: Razvan Cojocaru <rcojocaru@bitdefender.com
>     <mailto:rcojocaru@bitdefender.com>>
>     >> Signed-off-by: Tamas K Lengyel <tamas@tklengyel.com
>     <mailto:tamas@tklengyel.com>>
>     > This certainly looks very interesting. Would xc_domain_pause()
>     not be
>     > enough for your use case then?
>
>     I second this query.  I would have thought xc_domain_pause() does
>     exactly what you want in this case.
>
>
> The problem is in what order the responses are processed. I may not be
> correct about the logic but here is what my impression was:
> xc_domain_unpause resumes all vCPUs even if there is still a vm_event
> response that has not been processed. Now, if the subscriber set
> response flags (altp2m switch, singlestep toggle, etc) those actions
> would not be properly performed on the vCPU before it's resumed. If
> the subscriber processes all requests and signals via the event
> channel that the responses are on the ring, then calls
> xc_domain_unpause, we can still have a race between processing the
> responses from the ring and unpausing the vCPU.
>  
>
>     The code provided is racy, as it is liable to alter which pause
>     references it takes/releases depending on what other pause/unpause
>     actions are being made.
>
>
> It's understood that the user would not use xc_domain_pause/unpause
> while using vm_event responses with response flags specified. Even
> then, it was already racy IMHO if the user called xc_domain_unpause
> before processing requests from the vm_event ring that originally
> paused the vCPU, so this doesn't change that situation.

Pausing is strictly reference counted. (or rather, it is since c/s
3eb1c70 "properly reference count DOMCTL_{,un}pausedomain hypercalls". 
Before then, it definitely was buggy.)

There is the domain pause count, and pause counts per vcpu.  All domain
pause operations take both a domain pause reference, and a vcpu pause
reference on each vcpu.  A vcpu is only eligible to be scheduled if its
pause reference count is zero.  If two independent tasks call
vcpu_pause() on the same vcpu, it will remain paused until both
independent tasks have called vcpu_unpause().

Having said this, I can well believe that there might be issues with the
current uses of pausing.

The vital factor is that the entity which pauses a vcpu is also
responsible for unpausing it, and it must be resistant to accidentally
leaking its reference.

In this case, I believe that what you want to do is:

1) Identify condition requiring a sync
2) xc_domain_pause()
3) Process all of the pending vm_events
4) Synchronise the state
5) xc_domain_unpause()

All vcpus of the domain should stay descheduled between points 2 and 5. 
If this doesn't have the intended effect, then I suspect there is a bug
in the pause reference handing of the vm_event subsystem.

Is this clearer, or have I misunderstood the problem?

~Andrew

[-- Attachment #1.2: Type: text/html, Size: 6949 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 1/2] vm_event: sync domctl
  2015-12-23 19:14       ` Andrew Cooper
@ 2015-12-23 20:55         ` Tamas K Lengyel
  2015-12-23 21:06           ` Tamas K Lengyel
  0 siblings, 1 reply; 21+ messages in thread
From: Tamas K Lengyel @ 2015-12-23 20:55 UTC (permalink / raw)
  To: Andrew Cooper
  Cc: Wei Liu, Ian Campbell, Razvan Cojocaru, Stefano Stabellini,
	Ian Jackson, Xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 4758 bytes --]

On Wed, Dec 23, 2015 at 8:14 PM, Andrew Cooper <andrew.cooper3@citrix.com>
wrote:

> On 23/12/2015 18:11, Tamas K Lengyel wrote:
>
>
>
> On Wed, Dec 23, 2015 at 6:17 PM, Andrew Cooper <andrew.cooper3@citrix.com>
> wrote:
>
>> On 23/12/2015 15:41, Razvan Cojocaru wrote:
>> > On 12/23/2015 04:53 PM, Tamas K Lengyel wrote:
>> >> Introduce new vm_event domctl option which allows an event subscriber
>> >> to request all vCPUs not currently pending a vm_event request to be
>> paused,
>> >> thus allowing the subscriber to sync up on the state of the domain.
>> This
>> >> is especially useful when the subscribed wants to disable certain
>> events
>> >> from being delivered and wants to ensure no more requests are pending
>> on the
>> >> ring before doing so.
>> >>
>> >> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
>> >> Cc: Stefano Stabellini < <stefano.stabellini@eu.citrix.com>
>> stefano.stabellini@eu.citrix.com>
>> >> Cc: Ian Campbell <ian.campbell@citrix.com>
>> >> Cc: Wei Liu <wei.liu2@citrix.com>
>> >> Cc: Razvan Cojocaru < <rcojocaru@bitdefender.com>
>> rcojocaru@bitdefender.com>
>> >> Signed-off-by: Tamas K Lengyel < <tamas@tklengyel.com>
>> tamas@tklengyel.com>
>> > This certainly looks very interesting. Would xc_domain_pause() not be
>> > enough for your use case then?
>>
>> I second this query.  I would have thought xc_domain_pause() does
>> exactly what you want in this case.
>>
>
> The problem is in what order the responses are processed. I may not be
> correct about the logic but here is what my impression was:
> xc_domain_unpause resumes all vCPUs even if there is still a vm_event
> response that has not been processed. Now, if the subscriber set response
> flags (altp2m switch, singlestep toggle, etc) those actions would not be
> properly performed on the vCPU before it's resumed. If the subscriber
> processes all requests and signals via the event channel that the responses
> are on the ring, then calls xc_domain_unpause, we can still have a race
> between processing the responses from the ring and unpausing the vCPU.
>
>
>> The code provided is racy, as it is liable to alter which pause
>> references it takes/releases depending on what other pause/unpause
>> actions are being made.
>>
>
> It's understood that the user would not use xc_domain_pause/unpause while
> using vm_event responses with response flags specified. Even then, it was
> already racy IMHO if the user called xc_domain_unpause before processing
> requests from the vm_event ring that originally paused the vCPU, so this
> doesn't change that situation.
>
>
> Pausing is strictly reference counted. (or rather, it is since c/s 3eb1c70
> "properly reference count DOMCTL_{,un}pausedomain hypercalls".  Before
> then, it definitely was buggy.)
>
> There is the domain pause count, and pause counts per vcpu.  All domain
> pause operations take both a domain pause reference, and a vcpu pause
> reference on each vcpu.  A vcpu is only eligible to be scheduled if its
> pause reference count is zero.  If two independent tasks call vcpu_pause()
> on the same vcpu, it will remain paused until both independent tasks have
> called vcpu_unpause().
>
> Having said this, I can well believe that there might be issues with the
> current uses of pausing.
>
> The vital factor is that the entity which pauses a vcpu is also
> responsible for unpausing it, and it must be resistant to accidentally
> leaking its reference.
>
> In this case, I believe that what you want to do is:
>
> 1) Identify condition requiring a sync
> 2) xc_domain_pause()
> 3) Process all of the pending vm_events
> 4) Synchronise the state
> 5) xc_domain_unpause()
>
> All vcpus of the domain should stay descheduled between points 2 and 5.
> If this doesn't have the intended effect, then I suspect there is a bug in
> the pause reference handing of the vm_event subsystem.
>
> Is this clearer, or have I misunderstood the problem?
>

The problem is with step 4&5 IMHO. The event channel notification AFAIK is
asynchronous in that it just starts the processing of the pending vm_event
responses and returns, doesn't wait for the responses to be all processed.
Now if we progress to step 5, we might still have some responses on the
ring which have not gotten processed yet, so there is a race-condition.
There is currently no way to get a notification when all responses have
been processed, so the best thing we can do is to make sure we can
pause/unpause vCPUs without pending requests/responses as those are safe to
be resumed, while restricting the other vCPUs to be only unpaused through
the pending vm_event response. I hope this make sense.

That being said, I haven't yet encountered an instance where this
racecondition was lost, so this is just a pre-caution.

Tamas

[-- Attachment #1.2: Type: text/html, Size: 7676 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 1/2] vm_event: sync domctl
  2015-12-23 20:55         ` Tamas K Lengyel
@ 2015-12-23 21:06           ` Tamas K Lengyel
  2015-12-23 21:13             ` Andrew Cooper
  0 siblings, 1 reply; 21+ messages in thread
From: Tamas K Lengyel @ 2015-12-23 21:06 UTC (permalink / raw)
  To: Andrew Cooper
  Cc: Wei Liu, Ian Campbell, Razvan Cojocaru, Stefano Stabellini,
	Ian Jackson, Xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 3605 bytes --]

On Wed, Dec 23, 2015 at 9:55 PM, Tamas K Lengyel <tamas@tklengyel.com>
wrote:

>
>
>
> On Wed, Dec 23, 2015 at 8:14 PM, Andrew Cooper <andrew.cooper3@citrix.com>
> wrote:
>
>> On 23/12/2015 18:11, Tamas K Lengyel wrote:
>>
>>
>>
>> On Wed, Dec 23, 2015 at 6:17 PM, Andrew Cooper <andrew.cooper3@citrix.com
>> > wrote:
>>
>>> On 23/12/2015 15:41, Razvan Cojocaru wrote:
>>> > On 12/23/2015 04:53 PM, Tamas K Lengyel wrote:
>>> >> Introduce new vm_event domctl option which allows an event subscriber
>>> >> to request all vCPUs not currently pending a vm_event request to be
>>> paused,
>>> >> thus allowing the subscriber to sync up on the state of the domain.
>>> This
>>> >> is especially useful when the subscribed wants to disable certain
>>> events
>>> >> from being delivered and wants to ensure no more requests are pending
>>> on the
>>> >> ring before doing so.
>>> >>
>>> >> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
>>> >> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>> >> Cc: Ian Campbell <ian.campbell@citrix.com>
>>> >> Cc: Wei Liu <wei.liu2@citrix.com>
>>> >> Cc: Razvan Cojocaru <rcojocaru@bitdefender.com>
>>> >> Signed-off-by: Tamas K Lengyel <tamas@tklengyel.com>
>>> > This certainly looks very interesting. Would xc_domain_pause() not be
>>> > enough for your use case then?
>>>
>>> I second this query.  I would have thought xc_domain_pause() does
>>> exactly what you want in this case.
>>>
>>
>> The problem is in what order the responses are processed. I may not be
>> correct about the logic but here is what my impression was:
>> xc_domain_unpause resumes all vCPUs even if there is still a vm_event
>> response that has not been processed. Now, if the subscriber set response
>> flags (altp2m switch, singlestep toggle, etc) those actions would not be
>> properly performed on the vCPU before it's resumed. If the subscriber
>> processes all requests and signals via the event channel that the responses
>> are on the ring, then calls xc_domain_unpause, we can still have a race
>> between processing the responses from the ring and unpausing the vCPU.
>>
>>
>>> The code provided is racy, as it is liable to alter which pause
>>> references it takes/releases depending on what other pause/unpause
>>> actions are being made.
>>>
>>
>> It's understood that the user would not use xc_domain_pause/unpause while
>> using vm_event responses with response flags specified. Even then, it was
>> already racy IMHO if the user called xc_domain_unpause before processing
>> requests from the vm_event ring that originally paused the vCPU, so this
>> doesn't change that situation.
>>
>>
>> Pausing is strictly reference counted. (or rather, it is since c/s
>> 3eb1c70 "properly reference count DOMCTL_{,un}pausedomain hypercalls".
>> Before then, it definitely was buggy.)
>>
>> There is the domain pause count, and pause counts per vcpu.  All domain
>> pause operations take both a domain pause reference, and a vcpu pause
>> reference on each vcpu.  A vcpu is only eligible to be scheduled if its
>> pause reference count is zero.  If two independent tasks call vcpu_pause()
>> on the same vcpu, it will remain paused until both independent tasks have
>> called vcpu_unpause().
>>
>
Actually, I've double-checked and v->pause_count and
v->vm_event_pause_count are both increased for a vm_event request. So you
are right, the reference counting will make sure that v->pause_count > 0
until we process the vm_event response and call xc_domain_unpause. I was
under the impression that wasn't the case. We can ignore this patch.

Thanks and sorry for the noise ;)
Tamas

[-- Attachment #1.2: Type: text/html, Size: 6502 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 1/2] vm_event: sync domctl
  2015-12-23 21:06           ` Tamas K Lengyel
@ 2015-12-23 21:13             ` Andrew Cooper
  0 siblings, 0 replies; 21+ messages in thread
From: Andrew Cooper @ 2015-12-23 21:13 UTC (permalink / raw)
  To: Tamas K Lengyel
  Cc: Wei Liu, Ian Campbell, Razvan Cojocaru, Stefano Stabellini,
	Ian Jackson, Xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 4821 bytes --]

On 23/12/2015 21:06, Tamas K Lengyel wrote:
>
>
> On Wed, Dec 23, 2015 at 9:55 PM, Tamas K Lengyel <tamas@tklengyel.com
> <mailto:tamas@tklengyel.com>> wrote:
>
>
>
>
>     On Wed, Dec 23, 2015 at 8:14 PM, Andrew Cooper
>     <andrew.cooper3@citrix.com <mailto:andrew.cooper3@citrix.com>> wrote:
>
>         On 23/12/2015 18:11, Tamas K Lengyel wrote:
>>
>>
>>         On Wed, Dec 23, 2015 at 6:17 PM, Andrew Cooper
>>         <andrew.cooper3@citrix.com
>>         <mailto:andrew.cooper3@citrix.com>> wrote:
>>
>>             On 23/12/2015 15:41, Razvan Cojocaru wrote:
>>             > On 12/23/2015 04:53 PM, Tamas K Lengyel wrote:
>>             >> Introduce new vm_event domctl option which allows an
>>             event subscriber
>>             >> to request all vCPUs not currently pending a vm_event
>>             request to be paused,
>>             >> thus allowing the subscriber to sync up on the state
>>             of the domain. This
>>             >> is especially useful when the subscribed wants to
>>             disable certain events
>>             >> from being delivered and wants to ensure no more
>>             requests are pending on the
>>             >> ring before doing so.
>>             >>
>>             >> Cc: Ian Jackson <ian.jackson@eu.citrix.com
>>             <mailto:ian.jackson@eu.citrix.com>>
>>             >> Cc: Stefano Stabellini
>>             <stefano.stabellini@eu.citrix.com
>>             <mailto:stefano.stabellini@eu.citrix.com>>
>>             >> Cc: Ian Campbell <ian.campbell@citrix.com
>>             <mailto:ian.campbell@citrix.com>>
>>             >> Cc: Wei Liu <wei.liu2@citrix.com
>>             <mailto:wei.liu2@citrix.com>>
>>             >> Cc: Razvan Cojocaru <rcojocaru@bitdefender.com
>>             <mailto:rcojocaru@bitdefender.com>>
>>             >> Signed-off-by: Tamas K Lengyel <tamas@tklengyel.com
>>             <mailto:tamas@tklengyel.com>>
>>             > This certainly looks very interesting. Would
>>             xc_domain_pause() not be
>>             > enough for your use case then?
>>
>>             I second this query.  I would have thought
>>             xc_domain_pause() does
>>             exactly what you want in this case.
>>
>>
>>         The problem is in what order the responses are processed. I
>>         may not be correct about the logic but here is what my
>>         impression was: xc_domain_unpause resumes all vCPUs even if
>>         there is still a vm_event response that has not been
>>         processed. Now, if the subscriber set response flags (altp2m
>>         switch, singlestep toggle, etc) those actions would not be
>>         properly performed on the vCPU before it's resumed. If the
>>         subscriber processes all requests and signals via the event
>>         channel that the responses are on the ring, then calls
>>         xc_domain_unpause, we can still have a race between
>>         processing the responses from the ring and unpausing the vCPU.
>>          
>>
>>             The code provided is racy, as it is liable to alter which
>>             pause
>>             references it takes/releases depending on what other
>>             pause/unpause
>>             actions are being made.
>>
>>
>>         It's understood that the user would not use
>>         xc_domain_pause/unpause while using vm_event responses with
>>         response flags specified. Even then, it was already racy IMHO
>>         if the user called xc_domain_unpause before processing
>>         requests from the vm_event ring that originally paused the
>>         vCPU, so this doesn't change that situation.
>
>         Pausing is strictly reference counted. (or rather, it is since
>         c/s 3eb1c70 "properly reference count DOMCTL_{,un}pausedomain
>         hypercalls".  Before then, it definitely was buggy.)
>
>         There is the domain pause count, and pause counts per vcpu. 
>         All domain pause operations take both a domain pause
>         reference, and a vcpu pause reference on each vcpu.  A vcpu is
>         only eligible to be scheduled if its pause reference count is
>         zero.  If two independent tasks call vcpu_pause() on the same
>         vcpu, it will remain paused until both independent tasks have
>         called vcpu_unpause().
>
>
> Actually, I've double-checked and v->pause_count and
> v->vm_event_pause_count are both increased for a vm_event request. So
> you are right, the reference counting will make sure that
> v->pause_count > 0 until we process the vm_event response and call
> xc_domain_unpause. I was under the impression that wasn't the case. We
> can ignore this patch.
>
> Thanks and sorry for the noise ;)

Not a problem at all.  This is complicated stuff, and IMO it was equally
as likely that there was a real bug lurking.

~Andrew

[-- Attachment #1.2: Type: text/html, Size: 14490 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 2/2] vm_event: Add altp2m info to HVM events as well
  2015-12-23 14:53 ` [PATCH 2/2] vm_event: Add altp2m info to HVM events as well Tamas K Lengyel
  2015-12-23 15:42   ` Razvan Cojocaru
@ 2016-01-06 11:32   ` Jan Beulich
  2016-01-06 11:42     ` Tamas K Lengyel
  1 sibling, 1 reply; 21+ messages in thread
From: Jan Beulich @ 2016-01-06 11:32 UTC (permalink / raw)
  To: Tamas K Lengyel; +Cc: Andrew Cooper, Keir Fraser, Razvan Cojocaru, xen-devel

>>> On 23.12.15 at 15:53, <tamas@tklengyel.com> wrote:
> @@ -83,6 +84,12 @@ static int hvm_event_traps(uint8_t sync, vm_event_request_t *req)
>          vm_event_vcpu_pause(curr);
>      }
>  
> +    if ( altp2m_active(currd) )
> +    {
> +        req->flags |= VM_EVENT_FLAG_ALTERNATE_P2M;
> +        req->altp2m_idx = vcpu_altp2m(curr).p2midx;
> +    }

So far this info was provided just for MEM_ACCESS events. Now
you provide it for a few more ones, but wouldn't this then better
be supplied for all of them, namely also the other two MEM ones?

Jan

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 2/2] vm_event: Add altp2m info to HVM events as well
  2016-01-06 11:32   ` Jan Beulich
@ 2016-01-06 11:42     ` Tamas K Lengyel
  2016-01-06 11:48       ` Andrew Cooper
  0 siblings, 1 reply; 21+ messages in thread
From: Tamas K Lengyel @ 2016-01-06 11:42 UTC (permalink / raw)
  To: Jan Beulich; +Cc: Andrew Cooper, Keir Fraser, Razvan Cojocaru, Xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 778 bytes --]

On Wed, Jan 6, 2016 at 12:32 PM, Jan Beulich <JBeulich@suse.com> wrote:

> >>> On 23.12.15 at 15:53, <tamas@tklengyel.com> wrote:
> > @@ -83,6 +84,12 @@ static int hvm_event_traps(uint8_t sync,
> vm_event_request_t *req)
> >          vm_event_vcpu_pause(curr);
> >      }
> >
> > +    if ( altp2m_active(currd) )
> > +    {
> > +        req->flags |= VM_EVENT_FLAG_ALTERNATE_P2M;
> > +        req->altp2m_idx = vcpu_altp2m(curr).p2midx;
> > +    }
>
> So far this info was provided just for MEM_ACCESS events. Now
> you provide it for a few more ones, but wouldn't this then better
> be supplied for all of them, namely also the other two MEM ones?
>

AFAIK altp2m is currently incompatible with sharing. I'm not 100% sure but
I think it's also incompatible with paging.

Tamas

[-- Attachment #1.2: Type: text/html, Size: 1361 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 2/2] vm_event: Add altp2m info to HVM events as well
  2016-01-06 11:42     ` Tamas K Lengyel
@ 2016-01-06 11:48       ` Andrew Cooper
  2016-01-06 11:50         ` Tamas K Lengyel
  0 siblings, 1 reply; 21+ messages in thread
From: Andrew Cooper @ 2016-01-06 11:48 UTC (permalink / raw)
  To: Tamas K Lengyel, Jan Beulich; +Cc: Xen-devel, Keir Fraser, Razvan Cojocaru


[-- Attachment #1.1: Type: text/plain, Size: 1148 bytes --]

On 06/01/16 11:42, Tamas K Lengyel wrote:
>
>
> On Wed, Jan 6, 2016 at 12:32 PM, Jan Beulich <JBeulich@suse.com
> <mailto:JBeulich@suse.com>> wrote:
>
>     >>> On 23.12.15 at 15:53, <tamas@tklengyel.com <mailto:tamas@tklengyel.com>> wrote:
>     > @@ -83,6 +84,12 @@ static int hvm_event_traps(uint8_t sync,
>     vm_event_request_t *req)
>     >          vm_event_vcpu_pause(curr);
>     >      }
>     >
>     > +    if ( altp2m_active(currd) )
>     > +    {
>     > +        req->flags |= VM_EVENT_FLAG_ALTERNATE_P2M;
>     > +        req->altp2m_idx = vcpu_altp2m(curr).p2midx;
>     > +    }
>
>     So far this info was provided just for MEM_ACCESS events. Now
>     you provide it for a few more ones, but wouldn't this then better
>     be supplied for all of them, namely also the other two MEM ones?
>
>
> AFAIK altp2m is currently incompatible with sharing. I'm not 100% sure
> but I think it's also incompatible with paging.

I don't think they are strictly incompatible; I don't see a technical
reason preventing some development work to make them function together.

Whether this happens or not is a very different matter.

~Andrew

[-- Attachment #1.2: Type: text/html, Size: 2787 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 2/2] vm_event: Add altp2m info to HVM events as well
  2016-01-06 11:48       ` Andrew Cooper
@ 2016-01-06 11:50         ` Tamas K Lengyel
  2016-01-12 10:21           ` Jan Beulich
  0 siblings, 1 reply; 21+ messages in thread
From: Tamas K Lengyel @ 2016-01-06 11:50 UTC (permalink / raw)
  To: Andrew Cooper; +Cc: Xen-devel, Keir Fraser, Razvan Cojocaru, Jan Beulich


[-- Attachment #1.1: Type: text/plain, Size: 1321 bytes --]

On Wed, Jan 6, 2016 at 12:48 PM, Andrew Cooper <andrew.cooper3@citrix.com>
wrote:

> On 06/01/16 11:42, Tamas K Lengyel wrote:
>
>
>
> On Wed, Jan 6, 2016 at 12:32 PM, Jan Beulich <JBeulich@suse.com> wrote:
>
>> >>> On 23.12.15 at 15:53, < <tamas@tklengyel.com>tamas@tklengyel.com>
>> wrote:
>> > @@ -83,6 +84,12 @@ static int hvm_event_traps(uint8_t sync,
>> vm_event_request_t *req)
>> >          vm_event_vcpu_pause(curr);
>> >      }
>> >
>> > +    if ( altp2m_active(currd) )
>> > +    {
>> > +        req->flags |= VM_EVENT_FLAG_ALTERNATE_P2M;
>> > +        req->altp2m_idx = vcpu_altp2m(curr).p2midx;
>> > +    }
>>
>> So far this info was provided just for MEM_ACCESS events. Now
>> you provide it for a few more ones, but wouldn't this then better
>> be supplied for all of them, namely also the other two MEM ones?
>>
>
> AFAIK altp2m is currently incompatible with sharing. I'm not 100% sure but
> I think it's also incompatible with paging.
>
>
> I don't think they are strictly incompatible; I don't see a technical
> reason preventing some development work to make them function together.
>
> Whether this happens or not is a very different matter.
>

Sure, the two systems can be made to work in tandem, this work just hasn't
been done yet. I would very much like to get that to work in the future.

Tamas

[-- Attachment #1.2: Type: text/html, Size: 2987 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 1/2] vm_event: sync domctl
  2015-12-23 14:53 [PATCH 1/2] vm_event: sync domctl Tamas K Lengyel
  2015-12-23 14:53 ` [PATCH 2/2] vm_event: Add altp2m info to HVM events as well Tamas K Lengyel
  2015-12-23 15:41 ` [PATCH 1/2] vm_event: sync domctl Razvan Cojocaru
@ 2016-01-06 15:48 ` Ian Campbell
  2016-01-06 18:29   ` Tamas K Lengyel
  2 siblings, 1 reply; 21+ messages in thread
From: Ian Campbell @ 2016-01-06 15:48 UTC (permalink / raw)
  To: Tamas K Lengyel, xen-devel
  Cc: Wei Liu, Ian Jackson, Razvan Cojocaru, Stefano Stabellini

On Wed, 2015-12-23 at 15:53 +0100, Tamas K Lengyel wrote:
> Introduce new vm_event domctl option which allows an event subscriber
> to request all vCPUs not currently pending a vm_event request to be
> paused,
> thus allowing the subscriber to sync up on the state of the domain. This
> is especially useful when the subscribed wants to disable certain events
> from being delivered and wants to ensure no more requests are pending on
> the
> ring before doing so.
> 
> Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Cc: Ian Campbell <ian.campbell@citrix.com>
> Cc: Wei Liu <wei.liu2@citrix.com>
> Cc: Razvan Cojocaru <rcojocaru@bitdefender.com>
> Signed-off-by: Tamas K Lengyel <tamas@tklengyel.com>
> ---
>  tools/libxc/include/xenctrl.h | 11 +++++++++++
>  tools/libxc/xc_vm_event.c     | 16 ++++++++++++++++

Tools side is pretty trivial, assuming there is agreement on the underlying
hypercall interface:

Acked-by: Ian Campbell <ian.campbell@citrix.com>

> +/***
>   * Memory sharing operations.

Do you also maintain this? If so do you fancy sending a patch to fix:

>   *
>   * Unles otherwise noted, these calls return 0 on succes, -1 and errno on

"Unless" and "success" ?

Ian..

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 1/2] vm_event: sync domctl
  2016-01-06 15:48 ` Ian Campbell
@ 2016-01-06 18:29   ` Tamas K Lengyel
  2016-01-07  9:58     ` Ian Campbell
  0 siblings, 1 reply; 21+ messages in thread
From: Tamas K Lengyel @ 2016-01-06 18:29 UTC (permalink / raw)
  To: Ian Campbell
  Cc: Xen-devel, Ian Jackson, Wei Liu, Razvan Cojocaru, Stefano Stabellini


[-- Attachment #1.1: Type: text/plain, Size: 1681 bytes --]

On Wed, Jan 6, 2016 at 4:48 PM, Ian Campbell <ian.campbell@citrix.com>
wrote:

> On Wed, 2015-12-23 at 15:53 +0100, Tamas K Lengyel wrote:
> > Introduce new vm_event domctl option which allows an event subscriber
> > to request all vCPUs not currently pending a vm_event request to be
> > paused,
> > thus allowing the subscriber to sync up on the state of the domain. This
> > is especially useful when the subscribed wants to disable certain events
> > from being delivered and wants to ensure no more requests are pending on
> > the
> > ring before doing so.
> >
> > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Cc: Ian Campbell <ian.campbell@citrix.com>
> > Cc: Wei Liu <wei.liu2@citrix.com>
> > Cc: Razvan Cojocaru <rcojocaru@bitdefender.com>
> > Signed-off-by: Tamas K Lengyel <tamas@tklengyel.com>
> > ---
> >  tools/libxc/include/xenctrl.h | 11 +++++++++++
> >  tools/libxc/xc_vm_event.c     | 16 ++++++++++++++++
>
> Tools side is pretty trivial, assuming there is agreement on the underlying
> hypercall interface:
>
> Acked-by: Ian Campbell <ian.campbell@citrix.com>
>

Thanks, we've decided that this patch is actually not needed as the pause
reference count is already good enough.


>
> > +/***
> >   * Memory sharing operations.
>
> Do you also maintain this? If so do you fancy sending a patch to fix:
>
> >   *
> >   * Unles otherwise noted, these calls return 0 on succes, -1 and errno
> on
>
> "Unless" and "success" ?
>

Sure, that could be done in a separate patch. IMHO the whole sharing
subsystem could use a cleanup series of its own to fix things like this,
style issues and whatnot.

Tamas

[-- Attachment #1.2: Type: text/html, Size: 2870 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 1/2] vm_event: sync domctl
  2016-01-06 18:29   ` Tamas K Lengyel
@ 2016-01-07  9:58     ` Ian Campbell
  0 siblings, 0 replies; 21+ messages in thread
From: Ian Campbell @ 2016-01-07  9:58 UTC (permalink / raw)
  To: Tamas K Lengyel
  Cc: Xen-devel, Ian Jackson, Wei Liu, Razvan Cojocaru, Stefano Stabellini

On Wed, 2016-01-06 at 19:29 +0100, Tamas K Lengyel wrote:
> 
> 
> On Wed, Jan 6, 2016 at 4:48 PM, Ian Campbell <ian.campbell@citrix.com>
> wrote:
> > On Wed, 2015-12-23 at 15:53 +0100, Tamas K Lengyel wrote:
> > > Introduce new vm_event domctl option which allows an event subscriber
> > > to request all vCPUs not currently pending a vm_event request to be
> > > paused,
> > > thus allowing the subscriber to sync up on the state of the domain.
> > This
> > > is especially useful when the subscribed wants to disable certain
> > events
> > > from being delivered and wants to ensure no more requests are pending
> > on
> > > the
> > > ring before doing so.
> > >
> > > Cc: Ian Jackson <ian.jackson@eu.citrix.com>
> > > Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > > Cc: Ian Campbell <ian.campbell@citrix.com>
> > > Cc: Wei Liu <wei.liu2@citrix.com>
> > > Cc: Razvan Cojocaru <rcojocaru@bitdefender.com>
> > > Signed-off-by: Tamas K Lengyel <tamas@tklengyel.com>
> > > ---
> > >  tools/libxc/include/xenctrl.h | 11 +++++++++++
> > >  tools/libxc/xc_vm_event.c     | 16 ++++++++++++++++
> > 
> > Tools side is pretty trivial, assuming there is agreement on the
> > underlying
> > hypercall interface:
> > 
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> Thanks, we've decided that this patch is actually not needed as the pause
> reference count is already good enough.

OK, thanks.

> > > +/***
> > >   * Memory sharing operations.
> > 
> > Do you also maintain this? If so do you fancy sending a patch to fix:
> > 
> > >   *
> > >   * Unles otherwise noted, these calls return 0 on succes, -1 and
> > errno on
> > 
> > "Unless" and "success" ?
> > 
> Sure, that could be done in a separate patch.

Yes, that's what I intended.

>  IMHO the whole sharing subsystem could use a cleanup series of its own
> to fix things like this, style issues and whatnot.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 2/2] vm_event: Add altp2m info to HVM events as well
  2016-01-06 11:50         ` Tamas K Lengyel
@ 2016-01-12 10:21           ` Jan Beulich
  2016-01-12 12:13             ` Tamas K Lengyel
  0 siblings, 1 reply; 21+ messages in thread
From: Jan Beulich @ 2016-01-12 10:21 UTC (permalink / raw)
  To: Tamas K Lengyel; +Cc: Andrew Cooper, Keir Fraser, Razvan Cojocaru, Xen-devel

>>> On 06.01.16 at 12:50, <tamas@tklengyel.com> wrote:
> On Wed, Jan 6, 2016 at 12:48 PM, Andrew Cooper <andrew.cooper3@citrix.com>
> wrote:
> 
>> On 06/01/16 11:42, Tamas K Lengyel wrote:
>>
>>
>>
>> On Wed, Jan 6, 2016 at 12:32 PM, Jan Beulich <JBeulich@suse.com> wrote:
>>
>>> >>> On 23.12.15 at 15:53, < <tamas@tklengyel.com>tamas@tklengyel.com>
>>> wrote:
>>> > @@ -83,6 +84,12 @@ static int hvm_event_traps(uint8_t sync,
>>> vm_event_request_t *req)
>>> >          vm_event_vcpu_pause(curr);
>>> >      }
>>> >
>>> > +    if ( altp2m_active(currd) )
>>> > +    {
>>> > +        req->flags |= VM_EVENT_FLAG_ALTERNATE_P2M;
>>> > +        req->altp2m_idx = vcpu_altp2m(curr).p2midx;
>>> > +    }
>>>
>>> So far this info was provided just for MEM_ACCESS events. Now
>>> you provide it for a few more ones, but wouldn't this then better
>>> be supplied for all of them, namely also the other two MEM ones?
>>>
>>
>> AFAIK altp2m is currently incompatible with sharing. I'm not 100% sure but
>> I think it's also incompatible with paging.
>>
>>
>> I don't think they are strictly incompatible; I don't see a technical
>> reason preventing some development work to make them function together.
>>
>> Whether this happens or not is a very different matter.
> 
> Sure, the two systems can be made to work in tandem, this work just hasn't
> been done yet. I would very much like to get that to work in the future.

Which re-raises the question: Shouldn't the information then be
made available uniformly for all events?

Jan

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH 2/2] vm_event: Add altp2m info to HVM events as well
  2016-01-12 10:21           ` Jan Beulich
@ 2016-01-12 12:13             ` Tamas K Lengyel
  0 siblings, 0 replies; 21+ messages in thread
From: Tamas K Lengyel @ 2016-01-12 12:13 UTC (permalink / raw)
  To: Jan Beulich; +Cc: Andrew Cooper, Keir Fraser, Razvan Cojocaru, Xen-devel


[-- Attachment #1.1: Type: text/plain, Size: 1748 bytes --]

On Jan 12, 2016 3:21 AM, "Jan Beulich" <JBeulich@suse.com> wrote:
>
> >>> On 06.01.16 at 12:50, <tamas@tklengyel.com> wrote:
> > On Wed, Jan 6, 2016 at 12:48 PM, Andrew Cooper <
andrew.cooper3@citrix.com>
> > wrote:
> >
> >> On 06/01/16 11:42, Tamas K Lengyel wrote:
> >>
> >>
> >>
> >> On Wed, Jan 6, 2016 at 12:32 PM, Jan Beulich <JBeulich@suse.com> wrote:
> >>
> >>> >>> On 23.12.15 at 15:53, < <tamas@tklengyel.com>tamas@tklengyel.com>
> >>> wrote:
> >>> > @@ -83,6 +84,12 @@ static int hvm_event_traps(uint8_t sync,
> >>> vm_event_request_t *req)
> >>> >          vm_event_vcpu_pause(curr);
> >>> >      }
> >>> >
> >>> > +    if ( altp2m_active(currd) )
> >>> > +    {
> >>> > +        req->flags |= VM_EVENT_FLAG_ALTERNATE_P2M;
> >>> > +        req->altp2m_idx = vcpu_altp2m(curr).p2midx;
> >>> > +    }
> >>>
> >>> So far this info was provided just for MEM_ACCESS events. Now
> >>> you provide it for a few more ones, but wouldn't this then better
> >>> be supplied for all of them, namely also the other two MEM ones?
> >>>
> >>
> >> AFAIK altp2m is currently incompatible with sharing. I'm not 100% sure
but
> >> I think it's also incompatible with paging.
> >>
> >>
> >> I don't think they are strictly incompatible; I don't see a technical
> >> reason preventing some development work to make them function together.
> >>
> >> Whether this happens or not is a very different matter.
> >
> > Sure, the two systems can be made to work in tandem, this work just
hasn't
> > been done yet. I would very much like to get that to work in the future.
>
> Which re-raises the question: Shouldn't the information then be
> made available uniformly for all events?
>

IMHO there is no point doing so while the systems don't work together.

Tamas

[-- Attachment #1.2: Type: text/html, Size: 2823 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2016-01-12 12:14 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-12-23 14:53 [PATCH 1/2] vm_event: sync domctl Tamas K Lengyel
2015-12-23 14:53 ` [PATCH 2/2] vm_event: Add altp2m info to HVM events as well Tamas K Lengyel
2015-12-23 15:42   ` Razvan Cojocaru
2015-12-23 17:18     ` Andrew Cooper
2016-01-06 11:32   ` Jan Beulich
2016-01-06 11:42     ` Tamas K Lengyel
2016-01-06 11:48       ` Andrew Cooper
2016-01-06 11:50         ` Tamas K Lengyel
2016-01-12 10:21           ` Jan Beulich
2016-01-12 12:13             ` Tamas K Lengyel
2015-12-23 15:41 ` [PATCH 1/2] vm_event: sync domctl Razvan Cojocaru
2015-12-23 17:17   ` Andrew Cooper
2015-12-23 18:11     ` Tamas K Lengyel
2015-12-23 19:11       ` Razvan Cojocaru
2015-12-23 19:14       ` Andrew Cooper
2015-12-23 20:55         ` Tamas K Lengyel
2015-12-23 21:06           ` Tamas K Lengyel
2015-12-23 21:13             ` Andrew Cooper
2016-01-06 15:48 ` Ian Campbell
2016-01-06 18:29   ` Tamas K Lengyel
2016-01-07  9:58     ` Ian Campbell

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.