On Tue, 24 Jul 2012 23:39:47 +0200 Norman Feske (NF) wrote:
NF> it seems I slightly misunderstood your proposal. In your solution, the
NF> revoke CRD argument refers to the address space of the the caller, not
NF> the targeted PD, right? If so, your phrasing makes sense.
Correct.
NF> But couldn'
Hello again,
> NF> what do you mean by "full revoke of the range"?
> NF>
> NF> If a PD cap goes away, won't this implicitly revoke everything from
> NF> the PD anyway? (including the not-yet-finished range of the preempted
> NF> revoke operation) If so, this looks like a non-issue to me. Or does
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, 24 Jul 2012 21:44:10 +0200 Norman Feske (NF) wrote:
NF> what do you mean by "full revoke of the range"?
NF>
NF> If a PD cap goes away, won't this implicitly revoke everything from
NF> the PD anyway? (including the not-yet-finished range of th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Udo,
> There are some subtle corner cases possible if revoke gets
> preempted. One is that if you do a revoke (range, PD-cap), the
> range obviously cannot go away, but the PD-cap can. This means if
> you do a directed revoke by specifying a PD-cap
On Mon, 23 Jul 2012 14:19:31 +0200 Norman Feske (NF) wrote:
NF> > So you'd need something like a "directed revoke" feature. We had
NF> > something like that in Fiasco-V2, where you could do an "unmap
NF> > without self" and additionally specify a task number. Only child
NF> > mappings for that tas
