On 2020-07-02 8:20 p.m., Krste Asanovic wrote:

I added a note on this issue to spec:

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.

Krste