On Tue, Sep 20, 2022 at 07:19:57PM +0100, Marc Zyngier wrote: > Mark Brown <broonie@xxxxxxxxxx> wrote: > > Now that we are recording the type of floating point register state we > > are saving when we save it we can use that information when we load to > > decide which register state is required and bring the TIF_SVE state into > > sync with the loaded register state. > Really, this sentence makes zero sense to me. Please at least add some > punctuation, because the only words that spring to mind here are "DOES > NOT COMPUTE". I'll try to come up with something... > > + default: > > + /* > > + * This should never happen, we should always > > + * record what we saved when we save. We > > + * always at least have the memory allocated > > + * for FPSMID registers so try that and hope > > + * for the best. > > + */ > > + WARN_ON_ONCE(1); > > + clear_thread_flag(TIF_SVE); > > + break; > What makes it impossible for FP_STATE_TASK to reach this point? If > that's indeed an impossible case, please document it. That's what the "we should always record what we saved when we saved" is doing, and the comment in the header about it not being valid to record _TASK as a saved state. When we write the register state to memory we must always write either FPSIMD or SVE register values depending on which registers we saved state for. _TASK is not a meaningful state for stored register values.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
