I like the new top-level theory. Having to click through all the single theories has always been annoying and a risk for forgetting one interactively.

Thanks for doing this. We now have an AI-enhanced toplevel theory :)

Do you mean with the FIXME that these lemmas might not be necessary or that they should be moved elsewhere?

They could go into AInvs, but if I think about fixing the FIXME, I'm not sure I would actually decide to move them if they are not used there currently.

Whoops, I forgot about these. I think my intent was that these lemmas were so trivial that it felt like they shouldn't exist and that I should come back to them to try and find a different solution. The first one is an alternative version of vcpu_invalid_active_arm_current_vcpu_None but with a postcondition of _ ≠ Some _ instead of _ = None, and the second is basically an instantiation of hoare_pre_cont.

Ok, the first one has been replaced with strengthen None_Some_strg and the second one is now done by using an instantiated hoare_pre_cont directly in the relevant proof. Now that I'm thinking about it again, I'd say that the False precondition was a safe wp lemma but could have caused some serious confusion if that lemma applied unexpectedly elsewhere.

As an aside, while adding that strengthen I thought that it would be nice if it could be added to wpsimp directly instead of needing to do (wpsimp ... | strengthen ...)+. Unfortunately, it looks like strengthen can't be used in Eisbach methods, because it doesn't seem to like the dummy invocation I think it does.

exception CTERM raised (line 149 of "l4v/lib/Monads/Strengthen.thy"):
  gather_to_imp
  TERM _

Huh, interesting. I've also wondered a few times about adding strengthen to wpsimp, you got one step further with that than me :-). Maybe we can make Strengthen.thy more robust by catching the exception and defaulting to no_tac if we get one.

That's interesting, I don't think we've done much precondition False yet for wp, but I think it works here. Kinda nice.

Have you tried the monad_eq tactic for these? Might not be strong enough, but sometimes it is surprisingly good.

This and the following lemmas were actually just moved from a later file. I'll do the easier cleanup from your suggestions but might leave the more involved changes for another time.

No worries

Is that FIXME something we actually want to/should do? I think we looked at it in the past, and it doesn't quite work out without changing lots of things. If that is the case, we should probably remove the FIXME, and turn it into a comment that says that we have looked at it, so we don't repeat the process.

To make things more confusing, I think we looked at the similar active_cur_vcpu_of in ArchVCPU_AI. That one has a comment saying (* This is similar to cur_vcpu_2, but not close enough to reuse. *), presumably for exactly the reason you said. This one though is actually similar enough that I think a generalisation would work, although I'm less sure how much benefit that would have.

Agree with Gerwin here, maybe an issue and fixed in another PR?

I'm not sure these are easy to generalise, they express what type the set_object works on, but anything that describes that and that is not object-level tags has the same kind of quadratic behaviour that we see here. It think the best we can do with these is a proof method (we might already have one for other projections, because it's always the same proof), and potentially some automation for stating the lemmas, given a set of basic functions. Like a crunch for projections.

Stepping away from this for a bit, we do have this pattern a few times: stating the same kind of lemma for a bunch of functions, applying the same proof method to it. Maybe that is something more general that we could actually write. It'd take a term as input that has e.g. an ?f where the function would go, a naming scheme like for crunch, a list of functions, and a proof method. It would then instantiate the pattern with the given functions, and apply the proof method to each. Could of course also be a list of patterns (same generalisation as we did for crunches). I think that might be quite useful and would help with these kinds of patterns.

(not that I'm suggesting this for this PR, but if people like it, I might give that a go after I finish the current platform proofs)

In this case I feel like at least be some sort of generalisation handling set_endpoint and set_notification should be possible, since set_simple_ko asserts that the object previously there was one of those types, but that's small enough that it's probably not worth trying to do.

More generally, your idea does sound pretty good but I think it would be worth doing a rough survey of the proofs first to find examples of these patterns. That would both help us decide a priority for doing this and also guide what it would look like.

I guess that leads to the more immediate question, should I remove this FIXME or leave it as a signpost for if we do try out your idea?

I would remove the FIXME and put it in an issue (maybe with a pointer to these lemmas as an example). MCS also has a few of these where projections are established, and I remember vaguely thinking about something like this when I did RISCV64 back in the day and again in AARCH64. It never got across the threshold, but if we do it right, it might be a nice tool that can do a lot more than what we're thinking of right now.

If the more general versions have more preconditions, there would be value in keeping the old ones around. I.e. I'd turn the FIXME into a comment that the precondition is the reason we are keeping the old ones.

I don't think it is a problem that the function is here in HYP architectures and in ArchTcb_A in non-HYP architectures. I'd put a comment in the non-HYP architectures that it is in ArchTcb_A, because they don't have the VCPUAcc_A file to explain the discrepancy, and maybe leave comment here that it can't go into ArchTCB_A, because that would lead to a circular dependency. Then we know what's going on and can find things from either direction.

sanity check: this is moved, right?

Yes, moved here so that it could be used in vcpuFlush_corres.

what's none_bot again? it looks like a quick_print accident, but maybe I'm not familiar with it

none_bot ≡ case_option bot, with various helpful simp rules and automation.

ah yes, seeing vcpu_flush_if_current and vcpuFlushIfCur side by side, I definitely think the latter should be vcpuFlushIfCurrent

Confusingly, I went with vcpu_flush_if_current in the C as well so I'm not sure why I did the Haskell differently. Will change.

see comment on AARCH64/Schedule_R

I had the same issue with capMasterCap when arch-splitting, it simplified for the "generic" arch object case but then nothing else would work with it in the generic context. I expect this kind of thing is not uncommon.

For proofs that involve things like valid_obj X Y = valid_obj X Y' or something, I'm not sure whether we'd ever want these as simp, otherwise you'd need to simp del them to deal with the generic concept of valid_obj. Hmm. Not sure about this comment in that case.

unusual place for this? doesn't seem to come out of the above crunches, so is this tagging a fact that was proved in another theory?

Ah, converted to interface from a requalify. I approve!

this proof looks a bit old (assumes x, wp+simp vs wpsimp), is it moved?

I think it started as a copy of a old proof, possibly thread_set_no_change_tcb_pred.

Maybe worth a cleanup then?

Nice typo fix. I'm also wondering why you've introduced state_ext here and used it for the stuff you've added, but the other ones use det_state

We probably should have always had a state_ext and been using it where we could, but I think that we were lazy at the time due to most of the DetSched lemmas originally needing to be det_state anyway. This has changed since then and I'm using the ones I've added in other places where them being det_state causes problems.

I think there's a comment on one of the DetSched locales saying something like this and that we could be using state_ext more.

style: I think shows should not be indented this way; it belongs more to lemma than assumes

Does it not make sense to clobber invoke_untyped_etcb_at?

Do you mean get rid of the original lemma? If so, the proofs that were using it are pretty fiddly and expect the implication in the postcondition, while I'm using it in more standard ways that don't.

Right, if it's used that way, sure. It ended up being confusing seeing them as additions in AARCH64 AInvs somewhere, and a change here.

while we're here, indentation?

Still feels weird that it can't be used only in the theories that need it, but leaks out like this instead.

almost tempting to have an abbreviation for (%s. in_cur_domain (cur_thread s) s) so we can keep using and. probably not worth the bother

I know you had a bit of a battle with handle_event... can you say something (here, not as a comment) as to how we can use einvs here, or why, or how you came up with this schema?

This isn't actually the scene of that specific battle, that's in Syscall_AC. I'm using einvs here for the existing ct_in_cur_domain invariant, which says that if the scheduler action is resume_cur_thread then the current thread is either the idle thread or in the current domain. I use that to resolve the various in_cur_domain (cur_thread s) s preconditions once I'm able to.

Ahh, this reminds me of the advice I tried to give, related to handle_event. Makes sense, thank you!

moved? if not, rename_tac and spaces after :

indent on ==>

feels like I commented on this before, but there the invoke_untyped_etcb_at got a ' only, instead of appearing as an addition... bit confused what happened here

nice!