Re: [RFC] Extending MTRRs above 4G

[Avi Kivity <avi@redhat.com>]

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