From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: BUG with Win7 and user-return-notifier Date: Thu, 29 Oct 2009 09:32:12 +0100 Message-ID: <4AE9530C.6080701@web.de> References: <4AE6ED18.9040901@siemens.com> <4AE6F17C.1070403@redhat.com> <4AE6F1EE.5090207@siemens.com> <4AE6F4A3.3050903@redhat.com> <4AE6F4C4.3000802@redhat.com> <4AE7FE3B.2070802@redhat.com> <4AE84EB4.1010603@siemens.com> <4AE86AA0.1060802@redhat.com> <4AE8AC20.50506@web.de> <4AE9462E.5050409@redhat.com> <4AE94C63.2070300@web.de> <4AE94D29.8030600@redhat.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig7B74A8AA1ADA6A264B5BE945" Cc: kvm-devel To: Avi Kivity Return-path: Received: from fmmailgate01.web.de ([217.72.192.221]:48139 "EHLO fmmailgate01.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753533AbZJ2IcN (ORCPT ); Thu, 29 Oct 2009 04:32:13 -0400 In-Reply-To: <4AE94D29.8030600@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig7B74A8AA1ADA6A264B5BE945 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Avi Kivity wrote: > On 10/29/2009 10:03 AM, Jan Kiszka wrote: >> Avi Kivity wrote: >> =20 >>> On 10/28/2009 10:40 PM, Jan Kiszka wrote: >>> =20 >>>> =20 >>>>> [you can get longer, more detailed traces by using >>>>> /sys/kernel/debug/tracing/trace instead of dmesg] >>>>> >>>>> Oct 28 14:29:56 mchn012c kernel: qemu-sys-7200 0...1. 676996395u= s : >>>>> kvm_msr: msr_read c0000080 =3D 0x500 >>>>> Oct 28 14:29:56 mchn012c kernel: qemu-sys-7200 0...1. 676996403u= s : >>>>> kvm_msr: msr_write c0000080 =3D 0xd01 >>>>> >>>>> So Windows is setting EFER.SCE and EFER.NX while in long mode - >>>>> perfectly reasonable. Can you rerun with the attached debug patch?= >>>>> >>>>> >>>>> =20 >>>> Log attached. >>>> >>>> =20 >>> So the last bits are: >>> >>> Oct 28 21:26:41 mchn012c kernel: update_transition_efer: efer_offset = 4 >>> efer d01 >>> Oct 28 21:26:41 mchn012c kernel: update_transition_efer: ignoring all= >>> bits >>> Oct 28 21:26:41 mchn012c kernel: setup_msrs: marking efer for no relo= ad >>> >>> We're not reloading efer (correctly, as guest efer =3D=3D host efer),= yet >>> vmx_save_host_state() fails while loading efer. I've looked at >>> move_msr_up() (which is used by setup_msrs() to partition the msr spa= ce >>> into reloaded and non-reloaded msrs), and it seems correct. >>> >>> Can you see any way where update_transition_efer() returns false, yet= >>> efer turns up in the first save_nmsrs entries of vmx->guest_msrs? >>> >>> =20 >> Without understanding the code completely yet: When you push the slot >> containing EFER around, do you also update msr_offset_efer? >> >> =20 >=20 > We don't, but msr_offset_efer is only used from > update_transition_efer(), which is only ever called from setup_msrs() > immediately after updating msr_offset_efer. Indeed. >=20 > Of course, it should be an argument to update_transition_efer(), I'll > clean up this leftover. >=20 OK, will see that I can debug this later today. Jan --------------enig7B74A8AA1ADA6A264B5BE945 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 iEYEARECAAYFAkrpUxAACgkQitSsb3rl5xQ1OQCghEm4DmTsrKyiqKAiQvousDWF dbYAn1J1ucVCmdV36XRRCIR/uv9y569h =21yI -----END PGP SIGNATURE----- --------------enig7B74A8AA1ADA6A264B5BE945--