[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Revokable Grants Design (draft B)

>>> On 25.01.16 at 18:20, <david.vrabel@xxxxxxxxxx> wrote:
> High Level Design
> =================
> A revokable grant is indicated by an additional flag in the grant
> table entry.  A domain may only map such a grant using a new sub-op
> (`GNTABOP_map_revokable`) and must supply a local GFN.
> When the granting domain wishes to revoke a grant it:
> 1. Removes access from the grant, but does not make the grant
>    available for other uses.  The prevents any new grant map or copies
>    from starting.
> 2. Makes a `GNTTABOP_revoke` hypercall if the grant is in use (e.g.,
>    mapped).  The hypervisor atomically switches any mappings of the
>    grant to the local GFN supplied when it was mapped.  The hypervisor
>    will also wait for any in-progress grant copies to complete.

What about transfers? Presumably no-one uses them these days,
but they're part of the interface and hence need to be considered.
(But I guess accounting for them here is as simple as naming them
alongside copies. Or wait, "Low Level Design" seems to suggest you
simply disallow transfers for them.)

> Low Level Design
> ================
> Grant Table Entry
> -----------------
> A new `GTF_revokable` flag is added.  A grant reference with this bit
> set may only be mapped with `GNTTABOP_map_revokable` or copied with
> `GNTTABOP_grant_copy` (subject to the usual permission checks).
> Attempts to use `GNTTABOP_map_grant_ref` with such a reference must
> fail with -EACCESS.  Without a replacement page, revoking such a
> mapping would require clearing the mapping which would allow the
> granter to trigger faults in the mapper.

What about the inverse (GNTTABOP_map_revokable on non-
revokable grant)? Failure, or some kind of indication to the caller that
the GFN is not going to be used?

> ### `GNTTABOP_revoke`
>     struct gnttab_revoke {
>         grant_ref_t ref;
>     };
> --------------------------------------------------------------------
> Field         Purpose
> -----         ------------------------------------------------------
> `ref`         The grant reference whose access is being revoked.
> --------------------------------------------------------------------
> The caller must first remove access from the grant reference to
> prevent any new grant maps or copies from starting.

Is the hypervisor expected to check this, and fail if it's not the

Nice work, I don't think there's much in the way of moving on to
the implementation.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.