From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47947) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvXjL-0007Mw-QP for qemu-devel@nongnu.org; Thu, 09 Feb 2012 12:24:28 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RvXjE-0006qn-FU for qemu-devel@nongnu.org; Thu, 09 Feb 2012 12:24:23 -0500 Received: from fmmailgate02.web.de ([217.72.192.227]:43817) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RvXjE-0006qd-40 for qemu-devel@nongnu.org; Thu, 09 Feb 2012 12:24:16 -0500 Received: from moweb002.kundenserver.de (moweb002.kundenserver.de [172.19.20.108]) by fmmailgate02.web.de (Postfix) with ESMTP id DEA001C0C1931 for ; Thu, 9 Feb 2012 18:24:14 +0100 (CET) Message-ID: <4F34013C.80609@web.de> Date: Thu, 09 Feb 2012 18:24:12 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <5c058df627b83bf0c35c2e1dcd92b0a3fd301181.1328445531.git.jan.kiszka@web.de> <4F33E3B3.8000205@redhat.com> <4F33E8C1.3070906@web.de> <4F33EDAD.9020000@redhat.com> <4F33F50C.2050104@web.de> <4F33F8B5.5070109@redhat.com> In-Reply-To: <4F33F8B5.5070109@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE36C022E28E29B3C8B40B441" Subject: Re: [Qemu-devel] [PATCH 3/6] kvmvapic: Introduce TPR access optimization for Windows guests List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Anthony Liguori , Marcelo Tosatti , qemu-devel , kvm@vger.kernel.org, Gleb Natapov This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE36C022E28E29B3C8B40B441 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2012-02-09 17:47, Avi Kivity wrote: > On 02/09/2012 06:32 PM, Jan Kiszka wrote: >>>> >>>> We need to patch the causing instruction, so we have to know where i= t >>>> starts. Or what do you mean? >>> >>> Just don't deal with this at all, no one runs on kernels without kern= el >>> irqchip. >> >> Not true for upstream,=20 >=20 > It was introduced in 2.6.24? Is anyone running anything earlier? >=20 > I hope that qemu-1.1 will default to kvm irqchip. I don't expect the MSI thing cleaned up and upstreamed by then. So the question is if we want to disable MSI by default - I guess not... > In fact we should > start thinking about deprecating apic-less kvm (in the kernel). Not a good idea as it allows to stress user space code in KVM mode that is not going to be deprecated (as it is used without KVM as well). >=20 >> and not a design goal of this approach, >> specifically when considering that it also works with TCG. Would be a >> pity to lose this generality. >=20 > It doesn't really speed up tcg, does it? Nope, but it removes yet another blocking point for TCG<->KVM migration. >=20 >> >>> >>>>> >>>>> I'm not sure if the ABI guarantees anything about %rip. >>>> >>>> That's indeed a point. It's likely coupled to the emulator's interna= ls >>>> and when it calls out to user space for MMIO write. How to deal with= it? >>> >>> One way is to verify that it worked this way at least N versions back= , >>> and then retro-doc it. The downside is that it reduces our flexibili= ty >>> in the future, but I think that's a small downside. >> >> It need not reduce our flexibility, we just need to signal to user spa= ce >> when our behaviour changes again. >=20 > This means that if this code detects that rip is no longer accurate > using this signal, it has to disable itself. That's not something we > want, I think. =2E..or it could check in the other direction, i.e. forward. I think ther= e are only two reasonable options for the emulator. We could encode them in a KVM_CAP return code. >=20 >>>> >>>> I'm not sure if Windows has this properly set up for the UP HAL. I >>>> rather think this was a bug in the original implementation. The ROM = uses >>>> 0 as CPU index in UP mode unconditionally, so should we in QEMU. >>> >>> I mean just check kpcr.self. >> >> Yes, clear, but that means that Windows must have initialized FS.base = to >> point to the KPCR also in UP mode. Is that really the case? E.g. when >> ACPI is off?!=20 >=20 > No idea. >=20 >> I wonder if that explains the reported bug of qemu-kvm >> with -no-acpi and in-kernel irqchip... >=20 > acpi-less smp? it exists but rarely used. It could explain the > problem, yes. Testing right now... >=20 >>>> >>>> I know, and it caused some pain to write it (not only to find out ho= w to >>>> solve it technically). We would need to pass the RAM memory region d= own >>>> to this freaky device, like we do to the i440fx for PAM purposes. Bu= t, >>>> well, that is not straightforward right now. Better ideas welcome. >>> >>> Could we make it a child<> of i440FX, and have i440FX pass it the >>> MemoryRegion directly? >>> >>> It means we'll need to redo the glue for new chipsets, but it should = be >>> just a few lines. >> >> Hmm... not really nice. It is rather a child of the APIC than of the >> chipset IMHO. Moving it over would also mean establishing logical link= >> to the APIC from there.=20 >=20 > Clearly it's involved with the 440fx as well, as it has the magical > ability to turn ROM into RAM. I think all our ROM is in shadow RAM, only protected by the PAM settings. We could also reconfigure PAM in the guest, but the granularity does not match, and it would not be compatible with older VAPIC ROMs. We could establish a side channel to the chipset and linking the kvmvapic to it at board level. That link could point to any chipset supporting the interface. Jan --------------enigE36C022E28E29B3C8B40B441 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://enigmail.mozdev.org/ iEYEARECAAYFAk80ATwACgkQitSsb3rl5xThvgCfXIyXs8LoA3UD1up/Qox9UkNV OoYAn3Tzku1p9+XyvDX8X013BiNg7JVd =AHIo -----END PGP SIGNATURE----- --------------enigE36C022E28E29B3C8B40B441--