From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [RFC] Extending MTRRs above 4G Date: Tue, 23 Sep 2008 12:18:36 +0300 Message-ID: <48D8B46C.6030005@redhat.com> References: <1221673872.16470.27.camel@lappy> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm To: Alex Williamson Return-path: Received: from mx2.redhat.com ([66.187.237.31]:40382 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750822AbYIWJSl (ORCPT ); Tue, 23 Sep 2008 05:18:41 -0400 In-Reply-To: <1221673872.16470.27.camel@lappy> Sender: kvm-owner@vger.kernel.org List-ID: Alex Williamson wrote: > When I try to boot guests using a recent Linux kernel (2.6.26+), memory > above 3.5G gets thrown away with an error like this: > > WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 4608MB of RAM. > > And it's true, we're only providing MTRRs for memory below 4G. In fact > rombios32 knows very little, if anything, about memory above 4G, as seen > by memory reporting in the SMBIOS table. > > It looks like the Linux kernel MTRR code does have a bail-out point for > kvm/qemu, but that was only effective before we started reporting MTRRs. > On real hardware, I have two systems that do this two different ways. > The first is an Intel based system, which reports MTRRs to cover the I/O > space, then defaults the rest of memory to WB. The second is an AMD > based system which uses MTRRs to cover memory below 4G, then seems to > have a special AMD MSR to describe the top of memory above 4G. Xen > appears to mimic the first approach. > > Is there any reason that KVM sets the default MTRR type to UC, then only > sets up MTRRs for the memory below 4G? The thinking is that if we hotplug a device, its memory must be set to uncacheable by default. > the patch below is a possible > approach to continue down this path and enlighten rombios32 about the > real top of memory, and setup MTRRs appropriately. It doesn't address > SMBIOS or whatever causes grub to only report upper memory below 4G. > Alternatively we could switch to the Intel/Xen system approach, but it > seems rombios32 needs to understand the extra memory at some point > anyway. Thoughts? BTW, another benefit to the default WB approach is > that MTRRs are a limited resource and there will be memory sizes we > can't fully cover using the approach below. Yes, especially with the pci hole causing any memory size to require many MTRRs. I'd like to switch to default WB + MTRRs covering the pci space, but I'd like to get a clear understanding of how we handle hotplug. Meanwhile, I've applied your patch. -- error compiling committee.c: too many arguments to function