From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38667) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TUkmQ-000487-U8 for qemu-devel@nongnu.org; Sat, 03 Nov 2012 16:57:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TUkmP-0006YA-5P for qemu-devel@nongnu.org; Sat, 03 Nov 2012 16:57:22 -0400 Received: from mout.web.de ([212.227.17.12]:51573) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TUkmO-0006Y6-RY for qemu-devel@nongnu.org; Sat, 03 Nov 2012 16:57:21 -0400 Message-ID: <50958529.1090402@web.de> Date: Sat, 03 Nov 2012 21:57:13 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <509567BE.9000306@web.de> <50956A73.1070605@web.de> <50956C35.1080002@web.de> <5095728F.2010900@web.de> In-Reply-To: <5095728F.2010900@web.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig20277232E0484BE690BE76C1" Subject: Re: [Qemu-devel] [PATCH] kvm: fix Win2k boot without KVM List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-devel This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig20277232E0484BE690BE76C1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 2012-11-03 20:37, Jan Kiszka wrote: > On 2012-11-03 20:26, Blue Swirl wrote: >> On Sat, Nov 3, 2012 at 7:10 PM, Jan Kiszka wrote: >>> On 2012-11-03 20:03, Jan Kiszka wrote: >>>> On 2012-11-03 19:56, Blue Swirl wrote: >>>>> On Sat, Nov 3, 2012 at 6:51 PM, Jan Kiszka wrot= e: >>>>>> On 2012-11-03 19:49, Blue Swirl wrote: >>>>>>> Ignore accesses to VAPIC when kvmvapic is not enabled. >>>>>>> >>>>>>> Cc: Jan Kiszka >>>>>>> Signed-off-by: Blue Swirl >>>>>>> --- >>>>>>> hw/kvmvapic.c | 7 ++++--- >>>>>>> 1 files changed, 4 insertions(+), 3 deletions(-) >>>>>>> >>>>>>> diff --git a/hw/kvmvapic.c b/hw/kvmvapic.c >>>>>>> index dc111ee..a97d532 100644 >>>>>>> --- a/hw/kvmvapic.c >>>>>>> +++ b/hw/kvmvapic.c >>>>>>> @@ -612,6 +612,9 @@ static void vapic_write(void *opaque, hwaddr = addr, uint64_t data, >>>>>>> hwaddr rom_paddr; >>>>>>> VAPICROMState *s =3D opaque; >>>>>>> >>>>>>> + if (!kvm_irqchip_in_kernel()) { >>>>>>> + return; >>>>>>> + } >>>>>>> cpu_synchronize_state(env); >>>>>>> >>>>>>> /* >>>>>>> @@ -665,9 +668,7 @@ static void vapic_write(void *opaque, hwaddr = addr, uint64_t data, >>>>>>> break; >>>>>>> default: >>>>>>> case 4: >>>>>>> - if (!kvm_irqchip_in_kernel()) { >>>>>>> - apic_poll_irq(env->apic_state); >>>>>>> - } >>>>>>> + apic_poll_irq(env->apic_state); >>>>>>> break; >>>>>>> } >>>>>>> } >>>>>>> >>>>>> >>>>>> NACK, I'm already debugging the true reason (related to code patch= ing). >>>>> >>>>> This is a minimal fix that lets Win2k boot, now it does not work at= >>>>> all. I think it should be applied for 1.3, it can be reverted when >>>>> (if) you find a better fix. There's no hurry though. >>>> >>>> If you want to disable it, flip apic.vapic for !kvm_enabled. Your pa= tch >>>> affects user space APIC with KVM as well, though that is perfectly f= ine. >>>> >>>> But first of all give this some days as I just started. >>> >>> ...even more as this regression may not be related to the introductio= n >>> of the kvmvapic: My original test case for the kvmvapic under TCG, >>> WinXP, is now also broken, causing a segfault too. >>> >>> What I'm seeing is that tb_invalidate_phys_page_range in >>> patch_instruction no longer seems to detect that the currently execut= ed >>> tb was just changed. Any ideas what may cause this are welcome. >> >> My theory is that the kvmvapic ROM tries to make the PIO hypercalls, >> but the PIO devices in QEMU are not ready, maybe not initialized at >> all. >=20 > You are on the wrong track: All is set up, the first TPR accesses are > happening, and the kvmvapic is trying to patch them away. In TCG mode, > this requires a flush of the current TB afterward. And this somehow > fails, causing various issues as executing resumes at invalid addresses= =2E >=20 > Jan >=20 > PS: A good hash is e.g. b34bd5e5c8f356ec206e5a306ee3a9b6f42c4315, long > after the kvmvapic merge. >=20 > PPS: Bisecting in QEMU is no fun - too many transient build breakages. >=20 Bisection ended here: 0b57e287138728f72d88b06e69b970c5d745c44a (cpu_physical_memory_write_rom() needs to do TB invalidates). The problem is that this invalidation happens with is_cpu_write_access=3D0, "consuming" the current TB for the final invalidation in patch_instruction with is_cpu_write_access=3D1. So, instead of generating a new TB and resuming execution there, the guest jumps back to an invalidated TB. I have a patch, but it moves half of tb_invalidate_phys_page_range to patch_instruction. Need to check if that can be solved cleaner. Jan --------------enig20277232E0484BE690BE76C1 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.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCVhS0ACgkQitSsb3rl5xSouQCgyfpXEMth3n+Zs3JuEqFvHCqj ymAAoOidj+noblY47u0GhMxV/6Np54nb =oQp6 -----END PGP SIGNATURE----- --------------enig20277232E0484BE690BE76C1--