NOTE: When migrating a software thread between two harts with different microarchitectures, the `vstart` value might not be supported by the new hart microarchitecture. The runtime on the receiving hart might then have to emulate instruction execution to a supported vstart element position.
I appreciate you not punting this to "profiles"
Alternatively, migration events can be constrained to only occur at mutually supported `vstart` locations.
However, isn't this "mutually supported" effectively a profile constraint or consideration?
Should we therefore include in the note that the specifics need to be defined by any profile that requires thread migration?
When migration is triggered by an epoch expiry, the interrupt can be designed set to only occur between instructions, with vstart=0. But in general, a software thread could be migrated between harts when it has been descheduled for another reason, and when vstart might be whatever the microarch decided (e.g., a device interrupt during a long-running vector instruction).
thumbs up.
I can't see a different solution than that given in the note, which might limit freedom of designers to not support some vstart values
specifically vector instructions that are not rerunable in a imprecise exception machine.
if they are to be compatible with a profile that supports migration.
