From mboxrd@z Thu Jan 1 00:00:00 1970 From: Paolo Bonzini Subject: Re: [PATCH 3/6] kvmvapic: Introduce TPR access optimization for Windows guests Date: Thu, 09 Feb 2012 18:20:38 +0100 Message-ID: <4F340066.9070108@redhat.com> References: <5c058df627b83bf0c35c2e1dcd92b0a3fd301181.1328445531.git.jan.kiszka@web.de> <4F33E3B3.8000205@redhat.com> <4F33E8C1.3070906@web.de> <4F33EDAD.9020000@redhat.com> <4F33F50C.2050104@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Anthony Liguori , kvm@vger.kernel.org, Gleb Natapov , Marcelo Tosatti , qemu-devel , Avi Kivity To: Jan Kiszka Return-path: In-Reply-To: <4F33F50C.2050104@web.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org On 02/09/2012 05:32 PM, Jan Kiszka wrote: > > 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?! I wonder if that explains the reported bug of qemu-kvm > with -no-acpi and in-kernel irqchip... Yes, it does. It's used by some fast-path kernel APIs, and indeed the canonical way to find the KPCR base from ring 0 is to look at FS:[1Ch]. Similarly in userspace you can find the thread information block at FS:[sizeof(void*)*6], and FS:[1Ch] is something else. But your code cannot be reached from userspace, so that's always fine. Paolo