[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

>>> 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.


Xen-devel mailing list



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