All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Julien Grall <julien.grall.oss@gmail.com>
Cc: xen-devel <xen-devel@lists.xenproject.org>,
	Ian Jackson <iwj@xenproject.org>, Wei Liu <wl@xen.org>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Jan Beulich <jbeulich@suse.com>,
	Stefano Stabellini <sstabellini@kernel.org>,
	Anthony PERARD <anthony.perard@citrix.com>,
	Juergen Gross <jgross@suse.com>,
	Christian Lindig <christian.lindig@citrix.com>,
	David Scott <dave@recoil.org>,
	Volodymyr Babchuk <Volodymyr_Babchuk@epam.com>
Subject: Re: [PATCH v2 0/6] gnttab: add per-domain controls
Date: Fri, 24 Sep 2021 09:46:44 +0200	[thread overview]
Message-ID: <YU2CZMvlyGJvqJ3z@MacBook-Air-de-Roger.local> (raw)
In-Reply-To: <CAJ=z9a1MxDKg3pB0Qq2JvAfDJ6LHsSoYmg-m2Xotxi_EB1jb1g@mail.gmail.com>

On Fri, Sep 24, 2021 at 07:30:51AM +0500, Julien Grall wrote:
> Hi Roger,
> 
> On Thu, 23 Sep 2021, 16:20 Roger Pau Monné, <roger.pau@citrix.com> 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/20210917154625.89315-6-roger.pau@citrix.com/
> > > >
> > > > 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.

HVM params has always been a bit weird IMO, as some are known and used
by Xen (like the identity page tables) while others (like the xenstore
or console ones) are merely used as a way to pass information from
the toolstack into the domain.

> We only miss (?) the PV part.

Right - ideally we should use the same mechanism for PV and HVM, which
would rule out he piggyback on HVM params.

> 
> > The grant table slot used by the xenstore shared page is just an
> > agreement at the toolstack level, but not known to the hypervisor so
> > far.
> >
> 
> Right, we need to find a different way to provide/map the shared page if
> the grant table is not present.
> 
> To me the acquire hypercall is the best way to resolve it as Xen knows
> whether the domain will run Xenstored (at least we used to have a flag) and
> we can do the permission control easily.
> 
> Do you have another alternative?

As said before, I didn't give much through about a practical use case
for this. My main focus where patches 1 and 2 (which sadly seem to be
shadowed by this no grant-table option) in order to have more fine
grained control over the grant table support on a per-domain basis.
The no grant-table mode was mostly the cherry on the cake.

I could see people using no grant-table also likely wanting
no-xenstore and no-console as to prevent mappings from other domains
into it's private memory altogether. Then using Argo or a similar no
memory sharing mechanism in order to interact with other entities. So
I think we shouldn't over engineer this xenstore usage without grant
tables, as it might not even be relevant as a use-case itself.

Using the acquire hypercall could be a solution, but I think we would
also need to introduce a new hypercall then in order for user space to
be able to tell Xen about resource areas, so that the xenstore address
can be provided to Xen without (ab)using HVM params.

Thanks, Roger.


  parent reply	other threads:[~2021-09-24  7:47 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-22  8:21 [PATCH v2 0/6] gnttab: add per-domain controls Roger Pau Monne
2021-09-22  8:21 ` [PATCH v2 1/6] tools/console: use xenforeigmemory to map console ring Roger Pau Monne
2021-09-22  8:21 ` [PATCH v2 2/6] gnttab: allow setting max version per-domain Roger Pau Monne
2021-10-15  9:39   ` Jan Beulich
2021-10-15  9:48     ` Jan Beulich
2021-10-20  8:04       ` Roger Pau Monné
2021-10-20 10:57         ` Jan Beulich
2021-10-20 11:45           ` Juergen Gross
2021-10-20 13:00           ` Roger Pau Monné
2021-10-15 11:47   ` Jan Beulich
2021-10-20 11:58   ` Jan Beulich
2021-09-22  8:21 ` [PATCH v2 3/6] gnttab: allow per-domain control over transitive grants Roger Pau Monne
2021-09-22  9:28   ` Christian Lindig
2021-10-15 10:05   ` Jan Beulich
2021-10-20 10:14     ` Roger Pau Monné
2021-10-20 11:51       ` Jan Beulich
2021-10-15 11:46   ` Jan Beulich
2021-09-22  8:21 ` [PATCH v2 4/6] tools/xenstored: use atexit to close interfaces Roger Pau Monne
2021-09-22  8:21 ` [PATCH v2 5/6] tools/xenstored: partially handle domains without a shared ring Roger Pau Monne
2021-09-22  9:07   ` Julien Grall
2021-09-22  9:58     ` Roger Pau Monné
2021-09-22 10:23       ` Julien Grall
2021-09-22 12:34         ` Juergen Gross
2021-09-22 13:46           ` Julien Grall
2021-09-23  7:23             ` Roger Pau Monné
2021-09-23  7:56               ` Julien Grall
2021-10-20 14:48                 ` Julien Grall
2021-09-22  8:21 ` [PATCH v2 6/6] gnttab: allow disabling grant table per-domain Roger Pau Monne
2021-09-22  9:19   ` Julien Grall
2021-09-22  9:38     ` Juergen Gross
2021-09-23  8:41       ` Julien Grall
2021-10-15 11:51     ` Jan Beulich
2021-10-15 12:09   ` Jan Beulich
2021-09-22  8:57 ` [PATCH v2 0/6] gnttab: add per-domain controls Julien Grall
2021-09-22  9:39   ` Roger Pau Monné
2021-09-23  8:47     ` Julien Grall
2021-09-23 11:19       ` Roger Pau Monné
2021-09-24  2:30         ` Julien Grall
2021-09-24  6:21           ` Jan Beulich
2021-09-24  7:30             ` Julien Grall
2021-09-24  7:49               ` Jan Beulich
2021-09-24  7:46           ` Roger Pau Monné [this message]
2021-10-11  9:36 ` Roger Pau Monné
2021-10-11  9:52   ` Christian Lindig

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YU2CZMvlyGJvqJ3z@MacBook-Air-de-Roger.local \
    --to=roger.pau@citrix.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=anthony.perard@citrix.com \
    --cc=christian.lindig@citrix.com \
    --cc=dave@recoil.org \
    --cc=george.dunlap@citrix.com \
    --cc=iwj@xenproject.org \
    --cc=jbeulich@suse.com \
    --cc=jgross@suse.com \
    --cc=julien.grall.oss@gmail.com \
    --cc=sstabellini@kernel.org \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.