[v2,00/10] Per vcpu vm_event channels

Message

Petre Ovidiu PIRCALABU July 16, 2019, 5:06 p.m. UTC

This patchset adds a new mechanism of sending synchronous vm_event
requests and handling vm_event responses without using a ring.
As each synchronous request pauses the vcpu until the corresponding
response is handled, it can be stored in a slotted memory buffer
(one per vcpu) shared between the hypervisor and the controlling domain.

The main advantages of this approach are:
* the ability to dynamicaly allocate the necessary memory used to hold
the requests/responses (the size of vm_event_request_t/vm_event_response_t
can grow unrestricted by the ring's one page limitation)
* the ring's waitqueue logic is unnecessary in this case because the
vcpu sending the request is blocked until a response is received.

---
Changes from v1:

* Dropped the "tools/libxc: Consistent usage of xc_vm_event_* interface"
because it was not a hard requirement for this patchset.
* Removed sched.h from vm_event.h and replaced it fw declarations of
"struct domain" and "struct vm"event_domain"
* Reworked the vm_event_ng memory allocation mechanism to use
vzalloc/share_xen_page_with_guest. 
* Replaced the new domctl with a flag in the existing one. When the client
(libxc) wants to use the new interface the XEN_VM_EVENT_FLAGS_NG_OP bit
should be set. Also, the file xen/common/vm_event_ng.c was removed because
the domctl is shared between interfaces, and having 2 separated files would
unnecessary expose non-interface functions.
* The xen-access related patch was split in 3 new ones:
  * getopt_long for cmdline parsing
  * code-cleanup according to the XEN style guide
  * the vm_event_ng interface support

---
Petre Pircalabu (10):
  vm_event: Define VM_EVENT type
  vm_event: Remove "ring" suffix from vm_event_check_ring
  vm_event: Add 'struct domain' backpointer to vm_event_domain.
  vm_event: Simplify vm_event interface
  vm_event: Move struct vm_event_domain to vm_event.c
  vm_event: Decouple implementation details from interface.
  vm_event: Add vm_event_ng interface
  xen-access: Use getopt_long for cmdline parsing
  xen-access: Code cleanup
  xen-access: Add support for vm_event_ng interface

 tools/libxc/include/xenctrl.h        |  10 +
 tools/libxc/xc_mem_paging.c          |  13 +-
 tools/libxc/xc_memshr.c              |  13 +-
 tools/libxc/xc_monitor.c             |  27 +-
 tools/libxc/xc_private.h             |  18 +-
 tools/libxc/xc_vm_event.c            | 154 ++++--
 tools/tests/xen-access/Makefile      |   7 +-
 tools/tests/xen-access/vm-event-ng.c | 183 +++++++
 tools/tests/xen-access/vm-event.c    | 194 ++++++++
 tools/tests/xen-access/xen-access.c  | 435 +++++++----------
 tools/tests/xen-access/xen-access.h  |  91 ++++
 xen/arch/arm/mem_access.c            |   2 +-
 xen/arch/x86/mm.c                    |   7 +
 xen/arch/x86/mm/mem_access.c         |   4 +-
 xen/arch/x86/mm/mem_paging.c         |   2 +-
 xen/arch/x86/mm/mem_sharing.c        |   5 +-
 xen/arch/x86/mm/p2m.c                |  10 +-
 xen/common/mem_access.c              |   2 +-
 xen/common/monitor.c                 |   4 +-
 xen/common/vm_event.c                | 912 +++++++++++++++++++++++++----------
 xen/drivers/passthrough/pci.c        |   2 +-
 xen/include/public/domctl.h          |  82 +---
 xen/include/public/memory.h          |   2 +
 xen/include/public/vm_event.h        |  47 ++
 xen/include/xen/sched.h              |  24 +-
 xen/include/xen/vm_event.h           |  80 ++-
 26 files changed, 1631 insertions(+), 699 deletions(-)
 create mode 100644 tools/tests/xen-access/vm-event-ng.c
 create mode 100644 tools/tests/xen-access/vm-event.c
 create mode 100644 tools/tests/xen-access/xen-access.h

Comments

Tamas K Lengyel July 16, 2019, 8:45 p.m. UTC | #1

On Tue, Jul 16, 2019 at 11:06 AM Petre Pircalabu
<[e-mail]> wrote:
>
> This patchset adds a new mechanism of sending synchronous vm_event
> requests and handling vm_event responses without using a ring.
> As each synchronous request pauses the vcpu until the corresponding
> response is handled, it can be stored in a slotted memory buffer
> (one per vcpu) shared between the hypervisor and the controlling domain.
>
> The main advantages of this approach are:
> * the ability to dynamicaly allocate the necessary memory used to hold
> the requests/responses (the size of vm_event_request_t/vm_event_response_t
> can grow unrestricted by the ring's one page limitation)
> * the ring's waitqueue logic is unnecessary in this case because the
> vcpu sending the request is blocked until a response is received.

Could you please push a git branch for this somewhere?

Thanks,
Tamas

Petre Ovidiu PIRCALABU July 17, 2019, 9:14 a.m. UTC | #2

On Tue, 2019-07-16 at 14:45 -0600, Tamas K Lengyel wrote:
> On Tue, Jul 16, 2019 at 11:06 AM Petre Pircalabu
> <[e-mail]> wrote:
> > 
> > This patchset adds a new mechanism of sending synchronous vm_event
> > requests and handling vm_event responses without using a ring.
> > As each synchronous request pauses the vcpu until the corresponding
> > response is handled, it can be stored in a slotted memory buffer
> > (one per vcpu) shared between the hypervisor and the controlling
> > domain.
> > 
> > The main advantages of this approach are:
> > * the ability to dynamicaly allocate the necessary memory used to
> > hold
> > the requests/responses (the size of
> > vm_event_request_t/vm_event_response_t
> > can grow unrestricted by the ring's one page limitation)
> > * the ring's waitqueue logic is unnecessary in this case because
> > the
> > vcpu sending the request is blocked until a response is received.
> 
> Could you please push a git branch for this somewhere?
> 
> Thanks,
> Tamas

I've pushed this changes to my github xen fork:
https://github.com/petrepircalabu/xen/tree/vm_event_ng/devel
The tag for patchset is per_cpu_vm_event_channels_v2.

Many thanks for your support,
Petre