On Fri, 18 Mar 2022, Penny Zheng wrote: > > On Fri, 11 Mar 2022, Penny Zheng wrote: > > > From: Penny Zheng <penzh...@a011292.shanghai.arm.com> > > > > > > In case to own statically shared pages when owner domain is not > > > explicitly defined, this commits propose a special domain > > > DOMID_SHARED, and we assign it 0x7FF5, as one of the system domains. > > > > > > Statically shared memory reuses the same way of initialization with > > > static memory, hence this commits proposes a new Kconfig > > > CONFIG_STATIC_SHM to wrap related codes, and this option depends on > > static memory(CONFIG_STATIC_MEMORY). > > > > Why does it depend on CONFIG_STATIC_MEMORY? This is a genuine question, > > I am not trying to scope-creep the series. Is there an actual technical > > dependency on CONFIG_STATIC_MEMORY? If not, it would be super useful to > > be able to share memory statically even between normal dom0less guests (of > > course it would be responsibility of the user to provide the right > > addresses and > > avoid mapping clashes.) I know that some of our users have requested this > > feature in the past. > > > > I may find a proper way to rephrase here. My poor English writing skill... > When I implemented domain on static allocation, statically configured guest > RAM is > treated as static memory in Xen and I introduced a few helpers to > initialize/allocate/free > static memory, like acquire_staticmem_pages, etc, and all these helpers are > guarded with > CONFIG_STATIC_MEMORY. > I want to reuse these helpers on static shared memory, so CONFIG_STATIC_SHM > depends > on CONFIG_STATIC_MEMORY. > > So I'm not restricting sharing static memory between domain on static > allocation, current > Implementation is also useful to normal dom0less guests.
Ah, excellent! That makes sense.
