On 23.11.2012, at 16:02, Peter Maydell wrote:
> On 23 November 2012 10:18, Jens Freimann <jf...@linux.vnet.ibm.com> wrote:
>> + /* The initial reset call is needed here to reset in-kernel
>> + * vcpu data that we can't access directly from QEMU.
>
> If there's in-kernel vcpu data we can't access from QEMU,
> doesn't this cause problems for migration?
This one is for older kernels. For newer kernels, we have sync regs and ONE_REG
interfaces to everything we need FWIW :).
>
>> Before
>> + * this ioctl cpu_synchronize_state() is called in common kvm
>> + * code (kvm-all). What remains is clearing registers and psw
>> + * in QEMU cpu state */
>> + if (kvm_vcpu_ioctl(env, KVM_S390_INITIAL_RESET, NULL)) {
>> + perror("Can't reset vcpu\n");
>> + }
>
> Doesn't this mean we're now out-of-sync again, since the
> kernel state will be whatever INITIAL_RESET says it should
> be but the QEMU state won't have been changed?
>
> Generally, I think an arch-independent 'reset vcpu' ioctl
> would be useful. At the moment for ARM you have to pull
> everything out and back in again via the GET/SET_REG interface,
> which works [you can keep all the state around to write back
> on vcpu reset] but is ugly.
Actually it's the way it's supposed to work. The reset call is just a hack,
because it means we need to duplicate the reset logic for KVM & TCG. But it
dates back to when KVM on s390 wasn't using QEMU.
Alex
