Page Comparison

...

• Argo is now in upstream Xen and correspondingly the Linux driver needs to be prepared for upstreaming to the Linux kernel
  
  • vsock is upstream in Linux, there are transports for virtio and VMware, https://vmsplice.net/~stefan/stefanha-kvm-forum-2015.pdf
  • vsock can provide the socket behavior, which should minimize resistance in getting the driver suite upstreamed
• The driver should expose two separate interfaces: a vsock interface and a character device
  • The driver should be built as a common argo-core – along the lines of uXen's uxenv4vlib –  with both char and vsock drivers then leveraging argo-core
  • Using the existing socket-like interface on the character device does not depend on availability of a network stack
    • Potentially useful for minimal services VMs
    • Change requested: "The char driver behavior should be reduced back to that of a conventional Linux char driver"
  • "We want Xen’s argo Argo interface to will change to support message labeling, so that should be finalized before the Linux driver is submitted upstream."
    • This will enable the kernel to access the XSM/Flask SID label with the arriving data that it is associated with
    • OXT-1503: Argo peer labelling for access control
    • Test coverage for this will be required, so a method of enabling test cases to access and validate it needs to be determined
    • Kernel use of the label: guidance in Smalley presentation on OpenXT's access control at OpenXT Summit 2016
    • Should the label be surfaced to userspace?
      
  • To be determined: how to add support on How should either the vsock or chardev interfaces for support Argo-specific functionality?
    • ie. Is the chardev interface the correct interface between userspace and the kernel to provide support for Argo-specific, non-traditional character device, functionality?
      • eg. Configuring ring size
• The Argo firewall is currently not in upstream Xen, pending implementation of bi-directional connection tracking in OpenXT before upstreaming. The Linux driver is used to access and configure the firewall.
  • Should the firewall functions be moved out to a separate Linux device driver?

...

• For the current chardev driver: PR#4 on the OpenXT bats-suite repository contains basic initial BATS test cases for Argo that use the interposer library and ssh.
• For the vsock-argo driver: has a test utility "hatch" to exercise datagram transfers over vsock through Argo.
  • "Simple test tool to send/recv things over vsock through Argo and ease testing. It tries to mimic netcat usage to not look too unfamiliar. socat should be able to achieve the same, with a steeper learning curve. This will be made easier once STREAM communication are implemented I would think."
• For the uXen v4v driver: a very simple C program is provided that runs two threads, with a bind, a connect and sending data from one to the other.