From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NkR18-0002rp-2f for qemu-devel@nongnu.org; Wed, 24 Feb 2010 18:51:46 -0500 Received: from [199.232.76.173] (port=33758 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NkR17-0002rf-Pm for qemu-devel@nongnu.org; Wed, 24 Feb 2010 18:51:45 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NkR15-0002mW-SU for qemu-devel@nongnu.org; Wed, 24 Feb 2010 18:51:45 -0500 Received: from fmmailgate01.web.de ([217.72.192.221]:58392) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NkR15-0002mS-CB for qemu-devel@nongnu.org; Wed, 24 Feb 2010 18:51:43 -0500 Message-ID: <4B85BB8F.1000400@web.de> Date: Thu, 25 Feb 2010 00:51:43 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <09d3dc5c4cc2a36e61d2584b1b706143b9ce7765.1267021065.git.jan.kiszka@siemens.com> <20100224225913.GA16246@amt.cnet> In-Reply-To: <20100224225913.GA16246@amt.cnet> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE9EDD0734678ECD6CE569AE3" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: [PATCH v3 05/10] KVM: x86: Restrict writeback of VCPU state List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcelo Tosatti Cc: Gleb Natapov , Avi Kivity , kvm@vger.kernel.org, qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE9EDD0734678ECD6CE569AE3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Marcelo Tosatti wrote: > On Wed, Feb 24, 2010 at 03:17:53PM +0100, Jan Kiszka wrote: >> Do not write nmi_pending, sipi_vector, and mpstate unless we at least = go >> through a reset. And TSC as well as KVM wallclocks should only be >> written on full sync, otherwise we risk to drop some time on during >> state read-modify-write. >> >> Signed-off-by: Jan Kiszka >> --- >> kvm.h | 2 +- >> qemu-kvm-x86.c | 2 +- >> target-i386/kvm.c | 32 ++++++++++++++++++++------------ >> target-i386/machine.c | 2 +- >> 4 files changed, 23 insertions(+), 15 deletions(-) >> >> diff --git a/kvm.h b/kvm.h >> index 3ec5b59..3ee307d 100644 >> --- a/kvm.h >> +++ b/kvm.h >> @@ -44,7 +44,7 @@ int kvm_log_stop(target_phys_addr_t phys_addr, ram_a= ddr_t size); >> int kvm_has_sync_mmu(void); >> int kvm_has_vcpu_events(void); >> int kvm_has_robust_singlestep(void); >> -int kvm_put_vcpu_events(CPUState *env); >> +int kvm_put_vcpu_events(CPUState *env, int level); >> int kvm_get_vcpu_events(CPUState *env); >> =20 >> void kvm_cpu_register_phys_memory_client(void); >> diff --git a/qemu-kvm-x86.c b/qemu-kvm-x86.c >> index 4e6ae70..b0f9670 100644 >> --- a/qemu-kvm-x86.c >> +++ b/qemu-kvm-x86.c >> @@ -1391,7 +1391,7 @@ void kvm_arch_push_nmi(void *opaque) >> void kvm_arch_cpu_reset(CPUState *env) >> { >> kvm_arch_reset_vcpu(env); >> - kvm_put_vcpu_events(env); >> + kvm_put_vcpu_events(env, KVM_PUT_RESET_STATE); >> kvm_reset_mpstate(env); >> if (!cpu_is_bsp(env) && !kvm_irqchip_in_kernel()) { >> env->interrupt_request &=3D ~CPU_INTERRUPT_HARD; >> diff --git a/target-i386/kvm.c b/target-i386/kvm.c >> index 5f0829b..f1f44d3 100644 >> --- a/target-i386/kvm.c >> +++ b/target-i386/kvm.c >> @@ -541,7 +541,7 @@ static void kvm_msr_entry_set(struct kvm_msr_entry= *entry, >> entry->data =3D value; >> } >> =20 >> -static int kvm_put_msrs(CPUState *env) >> +static int kvm_put_msrs(CPUState *env, int level) >> { >> struct { >> struct kvm_msrs info; >> @@ -555,7 +555,6 @@ static int kvm_put_msrs(CPUState *env) >> kvm_msr_entry_set(&msrs[n++], MSR_IA32_SYSENTER_EIP, env->sysente= r_eip); >> if (kvm_has_msr_star(env)) >> kvm_msr_entry_set(&msrs[n++], MSR_STAR, env->star); >> - kvm_msr_entry_set(&msrs[n++], MSR_IA32_TSC, env->tsc); >> kvm_msr_entry_set(&msrs[n++], MSR_VM_HSAVE_PA, env->vm_hsave); >> #ifdef TARGET_X86_64 >> /* FIXME if lm capable */ >> @@ -564,8 +563,12 @@ static int kvm_put_msrs(CPUState *env) >> kvm_msr_entry_set(&msrs[n++], MSR_FMASK, env->fmask); >> kvm_msr_entry_set(&msrs[n++], MSR_LSTAR, env->lstar); >> #endif >> - kvm_msr_entry_set(&msrs[n++], MSR_KVM_SYSTEM_TIME, env->system_t= ime_msr); >> - kvm_msr_entry_set(&msrs[n++], MSR_KVM_WALL_CLOCK, env->wall_cloc= k_msr); >> + if (level =3D=3D KVM_PUT_FULL_STATE) { >> + kvm_msr_entry_set(&msrs[n++], MSR_IA32_TSC, env->tsc); >> + kvm_msr_entry_set(&msrs[n++], MSR_KVM_SYSTEM_TIME, >> + env->system_time_msr); >> + kvm_msr_entry_set(&msrs[n++], MSR_KVM_WALL_CLOCK, env->wall_c= lock_msr); >> + } >> =20 >> msr_data.info.nmsrs =3D n; >> =20 >> @@ -783,7 +786,7 @@ static int kvm_get_mp_state(CPUState *env) >> } >> #endif >> =20 >> -int kvm_put_vcpu_events(CPUState *env) >> +int kvm_put_vcpu_events(CPUState *env, int level) >> { >> #ifdef KVM_CAP_VCPU_EVENTS >> struct kvm_vcpu_events events; >> @@ -807,8 +810,11 @@ int kvm_put_vcpu_events(CPUState *env) >> =20 >> events.sipi_vector =3D env->sipi_vector; >> =20 >> - events.flags =3D >> - KVM_VCPUEVENT_VALID_NMI_PENDING | KVM_VCPUEVENT_VALID_SIPI_VE= CTOR; >> + events.flags =3D 0; >> + if (level >=3D KVM_PUT_RESET_STATE) { >> + events.flags |=3D >> + KVM_VCPUEVENT_VALID_NMI_PENDING | KVM_VCPUEVENT_VALID_SIP= I_VECTOR; >> + } >> =20 >> return kvm_vcpu_ioctl(env, KVM_SET_VCPU_EVENTS, &events); >=20 > What is the reason for write-back of any vcpu-event state for RUNTIME=20 > case again? >=20 > The debug workaround? Consistency and maximum flexibility. I don't want to start fiddling with this again when we start to manipulate some VCPU runtime state that may not require writeback yet (workarounds like the guest debugging stuff can be a reason for that). Instead, we should now establish a clean concept that only knows those three types and their well-defined writeback points. Jan --------------enigE9EDD0734678ECD6CE569AE3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkuFu48ACgkQitSsb3rl5xRydwCeMKChRySRAD5bmF7J3fjXJW2u EoIAnAv+4kl+R7/TOWM7UZFdZDZGx3rf =82du -----END PGP SIGNATURE----- --------------enigE9EDD0734678ECD6CE569AE3--