s390x doesn't have _any_ SIE state in the hardware. All g2 state is in
g1 memory and therefore migrated. So there is nothing needed at that
point for migration. It just works :)
shadowed SCBs (SIE control blocks) are simply recreated on the target
(after every VSIE execution, we write the data back into g1, so
whenever we leave the interception handler, we act according to the SIE
architecture).
If you get a userspace vmexit during vSIE, do you always exit the vSIE?
If not, the SIE operand is a hidden piece of processor state that you
need in order to restart execution of the vCPU. This would be more or
less the same as what's needed for x86 AMD.
For s390x, there are no instructions emulated for the vSIE, not even in
kernel space. So every time we leave our interception handler, the vSIE
has been fully handled and the next step would be to execute our g1 again.
Please note that (v)SIE and SIE don't share any code paths. vSIE is
really just an interception handler, emulating the SIE instruction (by
calling SIE in return).
So if we drop to user space (e.g. due to a signal), the vSIE has been
fully processed and the g2 SCB block has already been copied back to
g1. When re-entering kernel space, g1 is executed (continuing after the
SIE instruction), which will in return do a handful of checks and
execute g2 again (using SIE - intercept - vSIE).
So there is no hidden piece of processor state. Everytime we drop to
user space, everything is properly stored in g1 memory and therefore
migrated. As these user space exits are really rare, we don't have to
optimize for that. And I think if that should ever be needed, this
interface should be sufficient to extract/set hidden state.
--
David
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
