From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: kvm's vapic Date: Sun, 29 Jan 2012 17:51:14 +0200 Message-ID: <4F256AF2.1090106@redhat.com> References: <4F2567AE.8000509@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , Gleb Natapov , kvm To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:14308 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752692Ab2A2PvT (ORCPT ); Sun, 29 Jan 2012 10:51:19 -0500 In-Reply-To: <4F2567AE.8000509@web.de> Sender: kvm-owner@vger.kernel.org List-ID: On 01/29/2012 05:37 PM, Jan Kiszka wrote: > Hi all, > > I'm studying the TPR access optimization in qemu-kvm for quite a while > now. It's one of the, well, let's call it "hardest" parts of qemu-kvm I > dealt with so far. But it's slowly getting clearer. I'll be happy to answer questions here or on IRC. > > One thing I'm wondering now: This is practically targeting only 32-bit > Windows, right? Correct. 64-bit Windows uses cr8, which can be selectively intercepted according to the priority of a pending interrupt, if any, so it doesn't cause any excessive exits. > Already the assumption that we find a CPU index at > fs:0x51 is apparently hard-coding this. Or that kernel code is at > 0x8xxxxxxx or 0xExxxxxxx. > > But what makes sure that we aren't patching some other obscure OS that > doesn't comply with our assumptions but triggers the TPR access reports > nevertheless? Not much, but we've never had an issue. > Is there a way to detect the supported target OSes > reliably before patching anything? Otherwise this feature has to remain > off by default in upstream, I suppose. We could match fields with known values in the PCR, see http://www.reverse-engineering.info/SystemInformation/GetVarXP.pdf. Off-by-default dooms XP users to unusable performance on AMD hardware. -- error compiling committee.c: too many arguments to function