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. Alternatively, migration events
can be constrained to only occur at mutually supported `vstart`
locations.

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).

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 if
they are to be compatible with a profile that supports migration.

Krste

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

On Thu, 2 Jul 2020 20:52:04 -0400, "David Horner" <ds2horner@...> said:

| 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?

The note implies that but also includes the case where there is no
explicit profile, where two or more disparate harts are being created
by one designer between which migration will occur.

Krste

|| 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
||
||
||


|