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

[Zhongze Liu <blackskygg@xxxxxxxxx>]

2017-05-17 2:16 GMT+08:00 Stefano Stabellini <sstabellini@xxxxxxxxxx>:
> On Tue, 16 May 2017, Jan Beulich wrote:
>> >>> 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)?
>
> They would have to come up with a protocol. However, they already have
> code to deal with shared rings in their baremetal apps. It's not hard
> for them to do so, it is not hypervisor specific, and it is similar to
> the way they are used to work already. On the other end, they lack the
> code to deal with hypercalls, event channels and grant tables. In fact,
> they don't have Xen support.
>
>
>> >> > 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.
>
> Makes sense.
>

I agree with this, I'll take this into consideration in the next version of
this proposal.

Cheers,

Zhongze Liu

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