From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:50045) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rx1Jo-0007I2-CU for qemu-devel@nongnu.org; Mon, 13 Feb 2012 14:12:12 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rx1Jf-0007p9-R0 for qemu-devel@nongnu.org; Mon, 13 Feb 2012 14:12:08 -0500 Received: from mx1.redhat.com ([209.132.183.28]:8073) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rx1Jf-0007o8-K8 for qemu-devel@nongnu.org; Mon, 13 Feb 2012 14:11:59 -0500 Date: Mon, 13 Feb 2012 21:11:56 +0200 From: Gleb Natapov Message-ID: <20120213191156.GC7532@redhat.com> References: <4F38E315.4040107@siemens.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: Subject: Re: [Qemu-devel] [PATCH v2 5/8] kvmvapic: Introduce TPR access optimization for Windows guests List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Anthony Liguori , "kvm@vger.kernel.org" , Jan Kiszka , Marcelo Tosatti , qemu-devel , Avi Kivity On Mon, Feb 13, 2012 at 06:50:08PM +0000, Blue Swirl wrote: > On Mon, Feb 13, 2012 at 10:16, Jan Kiszka wrote: > > On 2012-02-11 16:25, Blue Swirl wrote: > >> On Fri, Feb 10, 2012 at 18:31, Jan Kiszka wro= te: > >>> This enables acceleration for MMIO-based TPR registers accesses of > >>> 32-bit Windows guest systems. It is mostly useful with KVM enabled, > >>> either on older Intel CPUs (without flexpriority feature, can also be > >>> manually disabled for testing) or any current AMD processor. > >>> > >>> The approach introduced here is derived from the original version of > >>> qemu-kvm. It was refactored, documented, and extended by support for > >>> user space APIC emulation, both with and without KVM acceleration. The > >>> VMState format was kept compatible, so was the ABI to the option ROM > >>> that implements the guest-side para-virtualized driver service. This > >>> enables seamless migration from qemu-kvm to upstream or, one day, > >>> between KVM and TCG mode. > >>> > >>> The basic concept goes like this: > >>> =9A- VAPIC PV interface consisting of I/O port 0x7e and (for KVM in-k= ernel > >>> =9A irqchip) a vmcall hypercall is registered > >>> =9A- VAPIC option ROM is loaded into guest > >>> =9A- option ROM activates TPR MMIO access reporting via port 0x7e > >>> =9A- TPR accesses are trapped and patched in the guest to call into o= ption > >>> =9A ROM instead, VAPIC support is enabled > >>> =9A- option ROM TPR helpers track state in memory and invoke hypercal= l to > >>> =9A poll for pending IRQs if required > >>> > >>> Signed-off-by: Jan Kiszka > >> > >> I must say that I find the approach horrible, patching guests and ROMs > >> and looking up Windows internals. Taking the same approach to extreme, > >> we could for example patch Xen guest to become a KVM guest. Not that I > >> object merging. > > > > Yes, this is horrible. But there is no real better way in the absence of > > hardware assisted virtualization of the TPR. I think MS is recommending > > this patching approach as well. >=20 > Maybe instead of routing via ROM and the hypercall, the TPR accesses > could be handled directly with guest invisible breakpoints (like GDB > breakpoints, but for QEMU internal use), much like other > instrumentation could be handled. >=20 Hypercall is rarely called. The idea behind patching is to not have exit on each TPR update. Breakpoint will cause exit making the whole exercise pointless. -- Gleb.