[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Proposal to allow setting up shared memory areas between VMs from xl config file

Hi Jan,

On 05/15/2017 09:52 AM, Jan Beulich wrote:
On 15.05.17 at 10:20, <julien.grall@xxxxxxx> wrote:
On 15/05/2017 09:08, Jan Beulich wrote:
On 12.05.17 at 19:01, <blackskygg@xxxxxxxxx> wrote:
1. Motivation and Description
Virtual machines use grant table hypercalls to setup a share page for
inter-VMs communications. These hypercalls are used by all PV
protocols today. However, very simple guests, such as baremetal
applications, might not have the infrastructure to handle the grant table.
This project is about setting up several shared memory areas for inter-VMs
communications directly from the VM config file.
So that the guest kernel doesn't have to have grant table support to be
able to communicate with other guests.

I think it would help to compare your proposal with the alternative of
adding grant table infrastructure to such environments (which I
wouldn't expect to be all that difficult). After all introduction of a
(seemingly) redundant mechanism comes at the price of extra /
duplicate code in the tool stack and maybe even in the hypervisor.
Hence there needs to be a meaningfully higher gain than price here.

This is a key feature for embedded because they want to be able to share
buffer very easily at domain creation time between two guests.

Adding the grant table driver in the guest OS as a high a cost when the
goal is to run unmodified OS in a VM. This is achievable on ARM if you
use passthrough.

"high cost" is pretty abstract and vague. And I admit I have difficulty
seeing how an entirely unmodified OS could leverage this newly
proposed sharing model.

Let's step back for a moment, I will come back on Zhongze proposal afterwards.

Using grant table in the guest will obviously require the grant-table driver. It is not that bad. However, how do you pass the grant ref number to the other guest? The only way I can see is xenstore, so yet another driver to port.

On Zhongze proposal, the share page will be mapped at the a specific address in the guest memory. I agree this will require some work in the toolstack, on the hypervisor side we could re-use the foreign mapping API. But on the guest side there are nothing to do Xen specific.

What's the benefit? Baremetal guest are usually tiny, you could use the device-tree (and hence generic way) to present the share page for communicating. This means no Xen PV drivers, and therefore easier to move an OS in Xen VM.


Julien Grall

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.