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

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

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