Re: [PATCH] xen/include/public: add macro for invalid grant reference

[Juergen Gross <jgross@xxxxxxxx>]

On 21.02.22 15:31, Jan Beulich wrote:
> On 21.02.2022 15:27, Juergen Gross wrote:
> > On 21.02.22 15:18, Jan Beulich wrote:
> > > On 21.02.2022 13:42, Juergen Gross wrote:
> > > > Providing a macro for an invalid grant reference would be beneficial
> > > > for users, especially as some are using the wrong value "0" for that
> > > > purpose.
> > > >
> > > > Signed-off-by: Juergen Gross <jgross@xxxxxxxx>
> > > Over the years I've been considering to add such to the public
> > > interface, perhaps even more than once. But I'm afraid it's not that
> > > easy. In principle 0xffffffff (which btw isn't necessarily ~0u) could
> > I can change that to use 0xffffffff explicitly.
> >
> > > be a valid ref. It is really internal agreement by users of the
> > > interface to set for themselves that they're not ever going to make
> > > a valid grant behind that reference.
> > As the grant reference is an index into the grant table this would
> > limit the size of the grant table to "only" UINT_MAX - 1. I don't
> > think this will be ever a concern (other than an academical one).
> That wasn't my point. Limiting the table to one less entry is not a
> big deal indeed. But we have no reason to mandate which gref(s) to
> consider invalid. A guest could consider gref 0 the invalid one.
With the gref being an index starting with 0 (gref 0 is valid, as it is
used for the console ring page), the natural choice for an invalid
value is the highest one being representable. A gref is of type uint32_t
resulting in this value being 0xffffffff.

While in theory a grant table could be that large, in practice this
will never happen.

> The hypervisor doesn't care. Imo this simply is an aspect which is
This isn't true. The hypervisor needs to allocate resources for being
able to handle the highest possible gref value for a guest. For a v1
grant table this would mean 32GB of grant table size. Are you really
concerned we will ever hit this limit? This isn't at the guest's
choice, after all, as the max grant table size is limited by Xen.

> not in need of pinning down in the ABI. Yet if it was pinned down
> like you do, then the hypervisor would need to make sure it refuses
> to act on this mandated invalid gref.
This is an easy one. We could just refuse to have a grant table of
that size. I can add this to the patch if you really think it is
necessary.

TBH, I think such completely theoretical concerns should not stand
in the way of additions to the ABI making life easier for consumers.


Juergen

Attachment: OpenPGP_0xB0DE9DD628BF132F.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature
Description: OpenPGP digital signature