On Mon, Sep 20, 2021 at 10:24:45AM +0200, Juergen Gross wrote: > On 17.09.21 17:46, Roger Pau Monne wrote: > > Restore the previous way of mapping the xenstore ring using foreign > > memory. Use xenforeignmemory instead of libxc in order to avoid adding > > another dependency on a unstable interface. > > Mapping a guest page via xenforeignmemory is no good move IMO. A guest > not supporting a grant table for security reasons is a rather strange > idea, as it needs to trade that for a general memory access by any > backend without a way to restrict such accesses. This contradicts one > of the main concepts of the Xen security architecture.
I've done this in order to be able to assert that the switch to disable grant tables was working correctly, I don't intended this specific mode to be something that is desirable or that should be used in production, but I do think it's useful to be able to create such guests in order to assert that the option is taking effect. The main problem of xenstore not being correctly initialized on a domain is that the "@introduceDomain" watch doesn't fire, and thus other components don't get notified of the newly created domain. This seems to be a limitation of the current design, where the only way to get notifications of new domain creation is using "@introduceDomain", even when the caller doesn't care of whether the created domain as a working xenstore connection. Maybe I can workaround this differently in xenstore, so that the watch fires even when the shared xenstore ring cannot be initialized. Thanks, Roger.
