From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [Qemu-devel] [PATCH v2 5/8] kvmvapic: Introduce TPR access optimization for Windows guests Date: Mon, 13 Feb 2012 21:11:56 +0200 Message-ID: <20120213191156.GC7532@redhat.com> References: <4F38E315.4040107@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Jan Kiszka , Avi Kivity , Marcelo Tosatti , Anthony Liguori , qemu-devel , "kvm@vger.kernel.org" To: Blue Swirl Return-path: Received: from mx1.redhat.com ([209.132.183.28]:58982 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757611Ab2BMTMC convert rfc822-to-8bit (ORCPT ); Mon, 13 Feb 2012 14:12:02 -0500 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Mon, Feb 13, 2012 at 06:50:08PM +0000, Blue Swirl wrote: > On Mon, Feb 13, 2012 at 10:16, Jan Kiszka wr= ote: > > On 2012-02-11 16:25, Blue Swirl wrote: > >> On Fri, Feb 10, 2012 at 18:31, Jan Kiszka = wrote: > >>> This enables acceleration for MMIO-based TPR registers accesses o= f > >>> 32-bit Windows guest systems. It is mostly useful with KVM enable= d, > >>> either on older Intel CPUs (without flexpriority feature, can als= o 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= =2E The > >>> VMState format was kept compatible, so was the ABI to the option = ROM > >>> that implements the guest-side para-virtualized driver service. T= his > >>> 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-kernel > >>> =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 in= to option > >>> =9A ROM instead, VAPIC support is enabled > >>> =9A- option ROM TPR helpers track state in memory and invoke hype= rcall 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 extr= eme, > >> we could for example patch Xen guest to become a KVM guest. Not th= at I > >> object merging. > > > > Yes, this is horrible. But there is no real better way in the absen= ce of > > hardware assisted virtualization of the TPR. I think MS is recommen= ding > > 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.