[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v8 0/8] Allow setting up shared memory areas between VMs from xl config files
Hi, Stefano On Sat, Oct 20, 2018 at 12:07 AM Stefano Stabellini <sstabellini@xxxxxxxxxx> wrote: > > Hi Wei, > > Any chances you can review this series soon? I would love for it to be > merged before the 4.12 code freeze. > > FYI I am making progress upstreaming the device tree binding, they asked > for a very minor change, which I am happy to include in the next version > of the series: > > https://marc.info/?l=devicetree&m=153989826510707&w=2 > > > On Mon, 8 Oct 2018, Stefano Stabellini wrote: > > Hi, > > > > This series implements a new xl config entry. Users can use the new > > config entry to statically setup shared memory areas among VMs that > > don't have grant table support so that they could communicate with each > > other through the static shared memory areas. > > > > It was originally developed by Zhongze, I am just updating the last few > > issued that were address during the last round of reviews in January. I > > tested the feature on ARM and works fine. > > > > Cheers, > > > > Stefano > > > > > > Main changes in v8: > > - remove "add xen,dmabuf nodes" patch > > - add "map reserved-memory regions as normal memory in dom0" patch > > - send new device tree binding request to devicetree.org > > > > > > > > The following changes since commit 85b00385827e4e061b2ff38b549c03d0f1e66b6a: > > > > xen/sched: Drop set_current_state() (2018-10-08 18:34:55 +0100) > > > > are available in the git repository at: > > > > > > http://xenbits.xenproject.org/git-http/people/sstabellini/xen-unstable.git > > share_mem-v8 > > > > for you to fetch changes up to fc00e34ce9924b5915deacd881ae7cd6888510ba: > > > > xen/arm: map reserved-memory regions as normal memory in dom0 (2018-10-08 > > 16:34:09 -0700) > > > > ---------------------------------------------------------------- > > Stefano Stabellini (2): > > xen/arm: export shared memory regions as reserved-memory on device > > tree > > xen/arm: map reserved-memory regions as normal memory in dom0 > > > > Zhongze Liu (6): > > xen: xsm: flask: introduce XENMAPSPACE_gmfn_share for memory sharing > > libxl: introduce a new structure to represent static shared memory > > regions > > libxl: support mapping static shared memory areas during domain > > creation > > libxl: support unmapping static shared memory areas during domain > > destruction > > libxl:xl: add parsing code to parse "libxl_static_sshm" from xl > > config files > > docs: documentation about static shared memory regions > > > > docs/man/xl-static-shm-configuration.pod.5 | 264 +++++++++++++++ > > docs/man/xl.cfg.pod.5.in | 8 + > > docs/misc/xenstore-paths.markdown | 47 +++ > > tools/flask/policy/modules/xen.if | 2 + > > tools/libxl/Makefile | 5 +- > > tools/libxl/libxl.h | 8 + > > tools/libxl/libxl_arch.h | 8 +- > > tools/libxl/libxl_arm.c | 76 ++++- > > tools/libxl/libxl_create.c | 27 ++ > > tools/libxl/libxl_dom.c | 2 +- > > tools/libxl/libxl_domain.c | 5 + > > tools/libxl/libxl_internal.h | 16 + > > tools/libxl/libxl_sshm.c | 512 > > +++++++++++++++++++++++++++++ > > tools/libxl/libxl_types.idl | 32 +- > > tools/libxl/libxl_x86.c | 21 +- > > tools/libxl/libxlu_sshm.c | 206 ++++++++++++ > > tools/libxl/libxlutil.h | 6 + > > tools/xl/xl_parse.c | 25 +- > > xen/arch/arm/domain_build.c | 7 + > > xen/arch/arm/mm.c | 7 +- > > xen/include/public/memory.h | 8 + > > xen/include/xsm/dummy.h | 14 + > > xen/include/xsm/xsm.h | 6 + > > xen/xsm/dummy.c | 1 + > > xen/xsm/flask/hooks.c | 9 + > > xen/xsm/flask/policy/access_vectors | 5 + > > 26 files changed, 1315 insertions(+), 12 deletions(-) > > create mode 100644 docs/man/xl-static-shm-configuration.pod.5 > > create mode 100644 tools/libxl/libxl_sshm.c > > create mode 100644 tools/libxl/libxlu_sshm.c > > > > _______________________________________________ > Xen-devel mailing list > Xen-devel@xxxxxxxxxxxxxxxxxxxx > https://lists.xenproject.org/mailman/listinfo/xen-devel I have question regarding format of "begin", "size" and "offset" properties. Wouldn't be better to operate with page numbers rather than addresses like it is done for "iomem"? I see that in many functions (libxl_sshm.c) these addresses are being transformed into page numbers the first. Moreover if the Xen shared memory feature can deal with 4K page aligned addresses only, why we provide possibility for user to set any addresses and then check them for alignment rules? The only one place where we need addresses is the device tree code where we insert memory regions (here we could transform page numbers into addresses on the fly). Or I missed something? -- Regards, Oleksandr Tyshchenko _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxxx https://lists.xenproject.org/mailman/listinfo/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |