On Fri, 24 Sep 2021, 11:21 Jan Beulich, <[email protected]> wrote: > On 24.09.2021 04:30, Julien Grall wrote: > > Hi Roger, > > > > On Thu, 23 Sep 2021, 16:20 Roger Pau Monné, <[email protected]> > wrote: > > > >> On Thu, Sep 23, 2021 at 01:47:37PM +0500, Julien Grall wrote: > >>> Hi Roger, > >>> > >>> On 22/09/2021 14:39, Roger Pau Monné wrote: > >>>> On Wed, Sep 22, 2021 at 01:57:02PM +0500, Julien Grall wrote: > >>>>> > >>>>> > >>>>> On 22/09/2021 13:21, Roger Pau Monne wrote: > >>>>>> Hello, > >>>>> > >>>>> Hi Roger, > >>>>> > >>>>>> First patch on the series is a trivial change to xenconsoled in > >> order to > >>>>>> use xenforeignmemory stable library in order to map the shared > >> console > >>>>>> ring instead of the unstable libxc interface. It's reviewed and > >> ready to > >>>>>> go in. > >>>>>> > >>>>>> Patches 2 and 3 allow setting the host wide command line `gnttab` > >> option > >>>>>> on a per domain basis. That means selecting the max allowed grant > >> table > >>>>>> version and whether transitive grants are allowed. > >>>>>> > >>>>>> The last 3 patches attempt to implement support for creating guests > >>>>>> without a grant table. This requires some changes to xenstored in > >> order > >>>>>> to partially support guests without a valid ring interface, as the > >> lack > >>>>>> of grant table will prevent C xenstored from mapping the shared > >> ring. > >>>>>> Note this is not an issue for Ocaml xenstored, as it still uses the > >>>>>> foreign memory interface to map the shared ring, and thus won't > >> notice > >>>>>> the lack of grant table support on the domain. > >>>>> > >>>>> I find a bit odd that the Xenstore support is conditional to whether > >> grant > >>>>> table is available. Are you expecting domains with no grant table to > >> have no > >>>>> PV drivers (including PV shutdown)? > >>>> > >>>> I don't really expect much, as having guests without grant table is a > >>>> developer option right now, if someone wants to make use of them for > >>>> any reason it would need some thought. > >>>> > >>>> The other option would be my first proposal to restore foreign mapping > >>>> of the xenstore ring on that case: > >>>> > >>>> > >> > https://lore.kernel.org/xen-devel/[email protected]/ > >>>> > >>>> But it's also arguable that a guest not having a grant table should > >>>> also likely prevent foreign mapping attempts. Plus such foreign > >>>> mapping won't work from stubdomains. > >>> > >>> There is another option: extend the acquire hypercall to allow > xenstored > >>> domain to map the xenstore interface. This would require more work, but > >> at > >>> least it would avoid the interesting dependency on the grant table. > >> > >> Xen isn't aware of the shared xenstore ring page currently, so that > >> would mean introducing more knowledge to the hypervisor that what's > >> strictly required IMO, as Xen has no business in knowing such details. > >> > > > > Well Xen already knows the page for HVM/PVH because the guest retrieve it > > through an HMV param. > > To be honest using this in such a way would feel like an abuse / layering > violation to me. >
I can see how it can be seen like this. Do you have a better suggestion to be able to map mapping without the foreign mapping interface and the grant table? Jan > >
