On 2020-07-24 6:11 a.m., krste@... wrote:

The vsetvl variant with vtype as register operand is used to restore
vector register state after a context swap. It is not currently
clearly specified, but in the case that the restored vtype value has
vill bit set, the current text implies vl should be cleared.

Section 6.1
"If the vtype setting is not supported by the implementation, then the
vill bit is set in vtype, the remaining bits in vtype are set to zero,
and the vl register is also set to zero."

If we are to allow vl to be set to any value when new vtype.vill=1,
then we have to define rule for how source vl value affects the vl
CSR.

this is in the x0,x0 case? I see this as the only case that needs to be considered.
The EE does not have to both set vill and establish a saved vl value in the same instruction.
A sequence of vsetvl instructions may be necessary to end up with the saved state.
The EE should  verfiy/validate after a "restore sequence" that the save state is established,
 perhaps remigrating to the original hart if unsuccessful.

Or am I missing the point?

This would simply be "truncate to number of supported vl bits",

providing a rs1 with the desired value also allows truncation to "supported vl bits".
I don't know that any special behaviour needs to be defined.
Again I could be missing the point.

though we need to consider the (small) cost of implementing this rule
correctly when the priv architecture supports emulating shorter VLEN
in lower privileged levels.

ditto.