From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L5gug-00047p-QM for qemu-devel@nongnu.org; Thu, 27 Nov 2008 08:28:10 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L5guf-000461-CM for qemu-devel@nongnu.org; Thu, 27 Nov 2008 08:28:09 -0500 Received: from [199.232.76.173] (port=44228 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L5guf-00045c-0A for qemu-devel@nongnu.org; Thu, 27 Nov 2008 08:28:09 -0500 Received: from mx2.redhat.com ([66.187.237.31]:39117) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L5gue-0007z8-D0 for qemu-devel@nongnu.org; Thu, 27 Nov 2008 08:28:08 -0500 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id mARDS6S5024945 for ; Thu, 27 Nov 2008 08:28:06 -0500 Message-ID: <492EA062.1030809@redhat.com> Date: Thu, 27 Nov 2008 15:28:02 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Modeling x86 early initialization accurately References: <492C80BF.4010103@gmx.net> <492CAEC8.4010306@codemonkey.ws> <492CC1F9.5050408@gmx.net> <492D7B2A.3060404@redhat.com> <492E0066.7040206@gmx.net> In-Reply-To: <492E0066.7040206@gmx.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Carl-Daniel Hailfinger wrote: > Grepping the source code didn't find any code signaling a #GP. I'd be > thankful for any hints so I can create a patch for this. > See helper_wrmsr(), the default: case (which is even commented). > (And give a warning to the ReactOS developers because their latest code > will #GP with that change. They read and write MSR 0x0000008b which is > unimplemented in QEMU). > > This may be an architectural msr (oxymoron, yes) which is guaranteed to exist. In that case qemu should implement it. >> If we can detect this, we can handle it with kvm by allocating a >> memory slot to back the cache. But I don't see how we can detect it >> reliably (mtrrs are handled completely within the kernel, and I >> wouldn't want this hack in the kernel). >> > > AFAICS MTRRs of x86 targets are ignored completely by QEMU. But not kvm. > They are > handled as unknown MSR reads/writes and do not fault. See > target-i386/op_helper.c:helper_rdmsr() and helper_wrmsr(). I'm not > familiar with how KVM handles the MTRRs and the KVM code in the QEMU > doesn't provide that many clues. Your statement about MTRR handling in > the kernel is not entirely clear to me. Are all MSR writes handled in > the kernel by KVM? > > Detection of the CAR mode activation can be performed in two ways, > depending on how close to hardware we want to get: > 1. Coreboot specific, triggering on the exact sequence of MSR writes > performed by coreboot. > Definitely not. > 2. BIOS/firmware agnostic, triggering anytime the cache control bits and > any of the MTRR MSRs are in the right state. > What is the right state? Total writeback memory spanned by MTRRs <= cache size? -- error compiling committee.c: too many arguments to function