2007
DOI: 10.1007/978-3-540-76778-7_10
|View full text |Cite
|
Sign up to set email alerts
|

XenSocket: A High-Throughput Interdomain Transport for Virtual Machines

Abstract: Abstract. This paper presents the design and implementation of XenSocket, a UNIX-domain-socket-like construct for high-throughput interdomain (VM-to-VM) communication on the same system. The design of XenSocket replaces the Xen page-flipping mechanism with a static circular memory buffer shared between two domains, wherein information is written by one domain and read asynchronously by the other domain. XenSocket draws on best-practice work in this field and avoids incurring the overhead of multiple hypercalls… Show more

Help me understand this report

Search citation statements

Order By: Relevance

Paper Sections

Select...
2
2
1

Citation Types

1
68
0
3

Year Published

2011
2011
2020
2020

Publication Types

Select...
3
3
3

Relationship

0
9

Authors

Journals

citations
Cited by 90 publications
(72 citation statements)
references
References 9 publications
1
68
0
3
Order By: Relevance
“…XWay [7] modifies the AF NET network protocol stack to switch dynamically between TCP/IP (using the original kernel) and their XWay channel (using shared memory). XenSocket [8] instead maintains another new AF XEN network protocol stack to support IDC. XenLoop [9] utilizes the existing Linux netfilter mechanism to add a XenLoop module between the IP layer and the netfront driver: if the packet is for IDC, the XenLoop module directly communicates with another XenLoop module in the corresponding domain.…”
Section: Related Workmentioning
confidence: 99%
See 1 more Smart Citation
“…XWay [7] modifies the AF NET network protocol stack to switch dynamically between TCP/IP (using the original kernel) and their XWay channel (using shared memory). XenSocket [8] instead maintains another new AF XEN network protocol stack to support IDC. XenLoop [9] utilizes the existing Linux netfilter mechanism to add a XenLoop module between the IP layer and the netfront driver: if the packet is for IDC, the XenLoop module directly communicates with another XenLoop module in the corresponding domain.…”
Section: Related Workmentioning
confidence: 99%
“…A discover kernel module in the manager domain is also needed to establish the data channel. These approaches [6]- [9] all require modification to the guest domain (beyond the wellsupported default Xen patch) and/or the applications running atop it [6], [8]. In sharp contrast, RTCA does not require any modification to the guest domain or the application or the Xen hypervisor, and can be seamlessly integrated with the rate control mechanism within Xen.…”
Section: Related Workmentioning
confidence: 99%
“…Using the socalled libxmc library, which we also developed from scratch, the daemon maintains sensor-to-vehicle mappings to keep track of which virtual vehicle is interested in receiving data from which sensors, and distributes sensor data to the possibly changing set of virtual vehicles. Control data and actual sensor data is communicated through so-called XenStore storage [14] and so-called XenSocket connections [15], respectively.…”
Section: A Sensor Virtualizationmentioning
confidence: 99%
“…This is because the abstraction of VMs supported by VMM technology does not differentiate whether the data request is coming from co-resident VMs or not. Several research projects [2][3][4][5][6][7][8][9][10][11] have demonstrated that. Linux guest domain shows lower network performance than native Linux [12], when an application running on a VM communicates with another VM.…”
Section: Introductionmentioning
confidence: 99%