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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 15.05.17 at 19:40, <sstabellini@xxxxxxxxxx> wrote:
> On Mon, 15 May 2017, Jan Beulich wrote:
>> >>> On 15.05.17 at 12:21, <julien.grall@xxxxxxx> wrote:
>> > 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.
>> 
>> So what is the equivalent of the shared page on bare hardware?
> 
> Bare-metal apps already have the concept of a shared page to communicate
> with hardware devices, co-processors and other hardware/firmare
> intercommunication frameworks.

So with that, is one side of the communication here then intended to
emulate such a hardware device, co-processor or other hardware /
firmware intercommunication framework? If so, aren't we talking
about device emulation then? If not, how can such a bare metal app
know the protocol (after all, if the protocol is Xen-specific, the app
wouldn't be Xen-unaware anymore)?

>> > 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.
>> 
>> Is this intended to be an ARM-specific extension, or a generic one?
>> There's no DT on x86 to pass such information, and I can't easily
>> see alternatives there. Also the consumer of the shared page info
>> is still a PV component of the guest. You simply can't have an
>> entirely unmodified guest which at the same time is Xen (or
>> whatever other component sits at the other end of the shared
>> page) aware.
> 
> I was going to propose for this work to be arch-neutral. However, it is
> true that with the existing x86 software and hardware ecosystem, it
> wouldn't be much use there. Given that the work is technically common
> though, I don't see any downsides on enabling it on x86 on the off
> chance that somebody will find it useful. However, if you prefer to
> keep it ARM only, that's fine by me too.

I don't have a preference either way, but if you do it in an arch-neutral
way, then the manifestation of the frame numbers also needs to be
arch-neutral, in which case DT is not a suitable vehicle.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel