From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L5hlJ-0001TZ-FU for qemu-devel@nongnu.org; Thu, 27 Nov 2008 09:22:33 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L5hlH-0001PP-Pj for qemu-devel@nongnu.org; Thu, 27 Nov 2008 09:22:32 -0500 Received: from [199.232.76.173] (port=60877 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L5hlH-0001Ok-H9 for qemu-devel@nongnu.org; Thu, 27 Nov 2008 09:22:31 -0500 Received: from mail.gmx.net ([213.165.64.20]:46094) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1L5hlG-0000i1-Lq for qemu-devel@nongnu.org; Thu, 27 Nov 2008 09:22:31 -0500 Message-ID: <492EAD23.8080403@gmx.net> Date: Thu, 27 Nov 2008 15:22:27 +0100 From: Carl-Daniel Hailfinger 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> <492EA062.1030809@redhat.com> In-Reply-To: <492EA062.1030809@redhat.com> Content-Type: text/plain; charset=UTF-8 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 On 27.11.2008 14:28, Avi Kivity wrote: > 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). Both current QEMU SVN and KVM GIT http://git.kernel.org/?p=linux/kernel/git/avi/kvm-userspace.git;a=blob_plain;f=qemu/target-i386/op_helper.c have this code for the default wrmsr: default: /* XXX: exception ? */ break; } My question was probably phrased the wrong way. I did know where to put the #GP, but not how to cause it to be delivered inside the machine. >> (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. The "Intel 64 and IA-32 Architectures Software Developer's Manual Volume 3B: System Programming Guide, Part 2" says this about MSR 0x8b: MSR 0x8b: IA32_BIOS_SIGN_ID MSR/Bit Description: BIOS Update Signature (RO) Returns the microcode update signature following the execution of CPUID.01H. A processor may prevent writing to this MSR when loading guest states on VM entries or saving guest states on VM exits. Bit 31:0 Reserved Bit 63:32 It is recommended that this field be pre-loaded with 0 prior to executing CPUID. If the field remains 0 following the execution of CPUID; this indicates that no microcode update is loaded. Any non-zero value is the microcode update signature. Unless we want to simulate microcode updates, this can be implemented easily. I'll send a patch. There are also a few MSRs we don't implement although they are part of the common subset of x86/x86-64 MSRs. Then again, if nothing uses them, no harm is done. >>> 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. Where can I look? The QEMU tree in KVM userspace GIT seems to ignore them as well. Am I looking at the wrong tree? >> 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. Good. >> 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? That would work, yes. It will support some cases which are not working on real hardware, but on the plus side, that approach is a catch-all for CAR implementations across various CPU generations from Intel and AMD. I'd recommend to make sure MTRRdefType has default memory type set to UC (uncacheable) when activating CAR. Otherwise you'd have to use MTRRs to declare anything except the CAR area as uncached and that may fail due to alignment requirements. Regards, Carl-Daniel -- http://www.hailfinger.org/